Your auditor reads your policy. Now your scanners do too.
Every scan result now says what your policy expects, what we saw and the gap. Every fix closes only when an independent rescan confirms it held. If it didn't, it rolls back and tells you why.
What changed
A failing check used to mean a generic baseline wasn’t met. Now it means your own policy wasn’t, at the clause and revision in force when we looked. Technical Controls is rebuilt around that: four tabs, one evidence pool, and fixes that have to prove themselves.
Results & Evidence
Results are grouped by policy clause. Each shows your policy, what we observed and the gap, with one of four outcomes: pass, fail, not evidenced or scope blocked. When a platform refuses us, that never becomes a pass. Switch to the Controls view to see the same evidence by framework control.
Why it fails
Failures break down per user or resource, so you can tell a real gap from an exception that lapsed or a known exception you already declared. Exceptions come from the register on each policy clause and are shown to your auditor as declared, never as passing.
Fixes
Every fix shows its blast radius and how it rolls back before you approve it. It's applied as an API change, a pull request against your infrastructure code, guided steps, or a ticket for a code change. You can create the Jira or Linear issue from the fix, and the ticket key goes on the pull request.
Verification
No change verifies itself. A rescan does, run by an independent scanner, not by whatever applied the fix. If the change didn't hold, it's rolled back, the finding reopens, and a follow-up explains what went wrong.
Security testing
Red Claw findings land in the same results, mapped to the clause they break and labelled as point in time. Code-level findings become a fix with a ticket, and close only when a retest shows the exploit no longer works.
Evidence records
Every result opens its own record: what it proves, how we got it, where it's used and its place on the audit trail. The coherence view checks the record against the grant that allowed the read, the policy revision, the record it replaced and the collector's history.
Overview
A coverage grid shows each framework by control family, using the same numbers as the framework chips. Pick a framework and every tab filters to it.
Earned autonomy
A category of fix earns the right to act on its own once its fixes have held on rescan: 98% of at least 30 by default. Your org can set its own bar, never below 90% of 10. Business plans build that record now; Enterprise lets it act.
FIG. 1Results grouped by the clause they test. The MFA row breaks down by admin: one real gap, one exception that lapsed on 30 Sep, and one known exception that’s declared, not passed.
Why it matters
An auditor doesn’t ask whether you passed a benchmark. They ask whether you did what your policy says. Measuring against the clause answers that question directly. Tighten the clause and the results change with it.
A fix marked done isn’t a fix that worked. Making a rescan decide, and keeping the change and its rollback on the audit trail, turns every remediation into evidence instead of a claim.
FIG. 2Sealed is not the same as sound. The coherence view checks a record against its four neighbours. A reading taken with a revoked token seals perfectly, and this view still catches it. More on the evidence graph.
Availability
Shipping today to every platform tier. Open it in your tenant at Technical Controls. Autonomous fixes act on Enterprise only.
Nothing you already had is lost. Existing results are grouped under the clauses they test, or under the framework default where no clause is linked yet. We suggest links between checks and clauses. They never count until a clause owner confirms them.
Known limitations
The Controls view's 90-day trend starts today. Earlier days aren't backfilled.
Files attached to policy clauses don't join the evidence pool yet, so a record's “Where it's used” doesn't list them.
