Controls
A project's Controls screen reads your scan results back through the lens of a compliance framework's requirements (ISMS-P, DORA, NIS2, CIS, and others). Instead of collapsing everything into a single "percent compliant" number, it separates what an automated check actually verified from what only a person can attest to with evidence — the two are different kinds of fact, and merging them into one number leaves nobody able to say what that number means.
1. Choosing a framework
Pick a framework at the top of the screen. The list shows each framework's total requirement count, together with how many requirements have at least one scanner check attached (automated) and how many can only be answered with evidence a person supplies (manual).
Of ISMS-P's 101 requirements, only 26 have at least one scanner check attached; the remaining 75 have no check at all and can only be judged from evidence a person submits. This split is different for every framework — DORA, NIS2 and CIS each have their own numbers. It would be wrong to say "ISMS-P is automated": a scan can only speak to 26 of the 101 requirements, and even those 26 are just one indicator on this screen, not the whole picture.
2. Three indicators
Once you choose a framework, its requirements split into automated, manual, and unassessed. The screen never adds or averages these into a single compliance rate.
- Automated pass rate — among requirements with an attached check that actually ran in this assessment, the share that passed. The denominator is "requirements whose attached check ran in this assessment," and a requirement counts as failed if any of its attached checks failed (exceptions that were accepted or suppressed are excluded from this count — see below).
- Manual evidence completion rate — among requirements with no attached check, the share that has evidence which is approved and not yet expired.
- Unassessed — requirements nothing can yet be said about: either a check is attached but never ran in this assessment, or a manual requirement has no evidence at all.
Every card carries its denominator explanation alongside the number — how many connections it covers, how many of those assessments are stale (old enough to be shown for reference only), how many mappings are unreviewed or excluded, and what point in time the number reflects, all spelled out in a sentence next to the figures. A rate without its denominator can't be checked, so this screen never shows one alone.
If there is nothing to compute, the screen shows that fact (and why) instead of "0%." A 0% figure reads as "everything failed," when the real situation may be "nothing has been assessed yet."
Exceptions (findings that were accepted or suppressed) are excluded from the failure count and listed separately in an exceptions card on the same screen — not silently dropped, but kept visible with why each one was excepted.
3. Mapping confidence and "unreviewed"
Each row in the requirement table shows the checks attached to it along with a confidence level.
| Level | Meaning |
|---|---|
direct | Reviewed and confirmed: this check directly verifies the requirement |
partial | Reviewed and confirmed: this check verifies only part of the requirement |
reference | Kept for reference only (excluded from the automated indicator) |
excluded | Deliberately excluded from this requirement's judgement (excluded from the automated indicator) |
unreviewed | A scanner vendor's own mapping that nobody has confirmed |
unreviewed is not a grade a person assigns — it is what an unconfirmed vendor mapping looks like. You cannot set it by hand: doing so would let a mapping nobody actually checked show up in a report as if it had been reviewed.
Open Review mapping on any requirement row to record a confidence level and a note; that judgement is saved and feeds into the indicators and reports from then on. Deleting a saved judgement on a vendor-defined mapping returns it to unreviewed — the mapping itself is not removed, only the "confirmed" marker. You can also add a mapping the scanner's own definitions don't include, for a (requirement, check) pair of your choosing.
The framework detail view also shows a review-status summary: how many mappings are vendor-defined, how many you added, how many you excluded, how many are reference-only, how many are unreviewed, and how many have been reviewed.
4. Manual evidence
Requirements with no attached check are evidenced by a file a person uploads.
- Open Upload evidence on the requirement row. Set an owner and an evidence period (365 days by default), then choose a file.
- The file never passes through this product's servers — it goes directly into your own storage (the S3 bucket on the connected AWS account). Once the upload finishes, the screen asks the server to confirm it: the server reads the object back and checks that its size and hash match what you declared before uploading. A mismatch means the submission is not accepted.
- Once confirmed, the evidence status becomes submitted, and someone with approval rights can approve or reject it. A rejection always needs a reason.
- If you don't set an expiry when approving, it's calculated as the submission time plus the evidence period. Once that date passes, the stored value is left unchanged but the screen shows expired — this is evaluated at read time, so it takes effect from the very next time anyone looks at it.
- A requirement that genuinely doesn't apply to your product or environment can be closed as not applicable, no file required — but a reason is still required, because deciding something doesn't apply is itself a judgement worth reviewing later.
Evidence status shows as one of not_started, submitted, approved, rejected, expired, or not_applicable.
The evidence file itself always stays in your own bucket. This product's database only keeps the file name, size, hash, status, owner, and approval history — never the file body. Downloads are also served as a time-limited link pointing at that bucket, not a copy held here.
Evidence uploaded at connection-group scope (for a multi-account organization project) applies to every connection in the group.
5. Document profiles
Generate control report produces a PDF laid out for the framework you chose. The profile is picked automatically from the framework, and you can re-render with a different one if you need to.
- ISMS-P audit checklist — a section per requirement with its checklist item, evidence list, and non-compliance cases, with the automated/manual split stated up front — for example, "26 of 101 requirements are automatically checkable."
- DORA test report — a front matter of scope, cadence, tools and versions, and the run ledger, followed by requirements grouped by pillar and article.
- NIS2 annex — requirements grouped by section and subsection, with the three indicators, exceptions and recommendations laid out as an annex.
- Generic — a plain requirement table, used for anything the three profiles above don't cover.
Every profile carries the same three indicators and their denominators, the exceptions list, mapping review status, the formula and criteria versions, and the document's own hash. The report body itself — every requirement, check, piece of evidence and cross-reference — is written to your own storage; this product's database keeps only a summary plus the hash and version pointers. If the body can't be read back, the report is not produced at all, so a document is never exported with a section silently missing.
6. Cross-framework matrix
The same check often applies to requirements in more than one framework. Open Cross-reference on a requirement's detail to see what this requirement is called in other frameworks — every requirement that shares a check with it. It's the place to check whether one control can be reused to answer more than one regulation.
7. Connection-group scope
For an organization project spanning multiple AWS accounts, the group page's Controls tab shows the three indicators, exceptions and reports for the whole group. The per-requirement table is deliberately left off the group screen — accounts in the group can run different checks and get different results, so merging them into one table would state a false, single verdict. To see requirement-level detail, open the Controls screen on an individual connection inside the group.
8. Related pages
The automated pass rate reads directly from the project's risk assessment (scan) results. For how a finding's own score and severity are derived, see Risk Score Explained. For access reviews, see Access Reviews. To bundle this screen's output with data location and audit history into a single signed package, see Evidence Package.