Appearance
Statement of Applicability
Where to find it: Regulatory Compliance, then Scope & Applicability (/scope-applicability), then open an adoption and select its Statement of Applicability.
A Statement of Applicability (SoA) is the document that tells an assessor, for every requirement in an adopted framework: does this apply to you, if not why not, and if so what addresses it.
In most organisations the SoA is a spreadsheet that is accurate on the day it is produced and wrong within a fortnight. In OrviQ it is derived live from the underlying governed records.
Live derivation
The SoA is not a document you author and maintain. It is computed at the moment you ask for it, from:
| Source | Contribution |
|---|---|
| The framework adoption | Which requirements are in the statement, the scope and the purpose |
| Applicability records | The applicability decision, its justification and its governance state |
| Approved crosswalk mappings | Which controls address each applicable requirement |
| Control records | Whether those controls are active or implemented |
| Requirement links | Which risks are connected to each requirement |
| Scope membership | The population the scope contained |
Because it is derived, the SoA cannot drift from the underlying records. If someone approves a new exclusion this morning, this afternoon's SoA reflects it — and so does the audit trail behind it.
What the SoA shows
Header
| Element | Meaning |
|---|---|
| Framework, title and version | What is being stated |
| Adoption reference | FAD-YYYY-NNNN |
| Scope reference and name | The declared boundary |
| Scope member count | How many subjects the scope contained |
| Purpose | Why the framework is governed here |
| Owner | Who is accountable |
| As-of timestamp | The instant the statement describes |
| Historical flag | Whether this is a reconstruction of a past position |
Summary
| Metric | Meaning |
|---|---|
| Total requirements | All requirements in the adoption |
| Applicable | Determined as applying |
| Not applicable | Determined as excluded |
| Under review | Not yet determined — unresolved, neither included nor excluded |
Under review is not a rounding error
A statement showing 81 applicable, 12 not applicable and 14 under review is telling you that 14 obligations have no determination at all. Those are not quietly excluded, and they are not quietly counted. Resolve them before treating the statement as complete.
Per-requirement rows
| Column | Meaning |
|---|---|
| Source reference | The clause reference in the framework |
| Title and description | The requirement as published |
| Domain | Its category within the framework |
| Applicability | Applicable, Not Applicable or Under Review |
| Justification | The recorded rationale, mandatory for exclusions |
| Governance state | draft, pending_review, approved or rejected |
| Implementation context | A derived summary of how the requirement is addressed |
| Mapped controls | Approved crosswalk mappings, with control reference, name, relationship and control status |
| Linked risks | Risks connected to the requirement |
| Owner and reviewer | Who decided and who reviewed |
| Decision date and last review | When |
Implementation context values
This column is derived, not entered:
| Value | Derived when |
|---|---|
| Not Applicable | The requirement is excluded |
| Planned / Unmapped | Applicable, but no approved mapping exists |
| Implemented via Controls | At least one mapped control is active or implemented |
| In Progress | Mappings exist but no mapped control is yet active |
Implementation context is not a compliance verdict
"Implemented via Controls" means a control exists and is active. It says nothing about whether the control is effective or the obligation satisfied. Those live in Compliance Determination, deliberately in a different place.
Historical reconstruction
Request the SoA with an as-of date and OrviQ reconstructs the statement as it stood then:
- Applicability decisions rewind through the applicability history to the state approved at that instant.
- Mappings are filtered by their validity window, so a mapping retired since is included if it was valid then, and a mapping created since is excluded.
- Scope membership is resolved from effective-dated members.
The result carries a historical flag and the as-of timestamp so it can never be mistaken for the current position.
This matters in a specific, common situation: an assessor visiting in November asks what your SoA said at the time of the March assessment. Reconstructing it from a live spreadsheet is impossible; reconstructing it from the governed record is a date field.
See Historical Reconstruction.
Export
The SoA exports to CSV for inclusion in certification packs, audit files and regulatory submissions. The export honours the as-of parameter, so you can export a historical statement as readily as a current one.
Requires compliance.read or export.data.
How to produce an SoA for an assessment
- Resolve every Under Review row. A statement with undetermined obligations is not ready.
- Confirm every exclusion is approved. Filter by governance state; anything in
draftis not authoritative and will not be treated as an exclusion. - Review the justifications. Read them as an assessor would. Weak wording is the most common source of assessment findings on the SoA itself.
- Check Planned / Unmapped rows. An applicable requirement with no mapped control is a gap you should be able to explain.
- Export with the as-of date set to the assessment reference date.
Permissions
| Action | Permission |
|---|---|
| View the SoA | compliance.read |
| Export the SoA | compliance.read or export.data |
| Change applicability decisions | compliance.manage or obligations.update |
| Approve decisions | compliance.validate or workflow.approve |
Example
The example below uses an ISO 27001-style structure for illustration.
A bank's payments platform certification SoA, adoption FAD-2026-0004, exported for a stage 1 assessment:
Header: Information security management standard, scope SCP-2026-0007 — Payments Platform Production (63 members), purpose certification, owner the Head of Information Security, as-of the assessment reference date.
Summary: 93 total, 81 applicable, 12 not applicable, 0 under review.
Sample rows:
| Reference | Applicability | Implementation context | Mapped controls |
|---|---|---|---|
| A.5.1 | Applicable | Implemented via Controls | CTL-2026-0003 Information Security Policy (equivalent) |
| A.8.5 | Applicable | Implemented via Controls | CTL-2026-0041 Multi-Factor Authentication (equivalent), CTL-2026-0044 Privileged Access Management (supporting) |
| A.8.9 | Applicable | Planned / Unmapped | — |
| Teleworking | Not Applicable | Not Applicable | — |
Row A.8.9 is the one the assessor will ask about, and the honest answer is available: the requirement applies, no control is yet mapped, and there is a finding and an action plan against it with a named owner and a due date.
That is a far better position at stage 1 than a statement claiming full implementation that fieldwork then contradicts.
Troubleshooting
"The SoA shows fewer controls than I expect." Only approved mappings appear. Proposed mappings are not part of the statement. Check the Control Crosswalk for mappings still awaiting review.
"An exclusion is not shown as excluded." Its governance state is not approved.
"The historical SoA differs from my saved copy." The historical view reconstructs from records. If a saved spreadsheet disagrees, the spreadsheet has drifted — that is the problem the derived SoA solves.
"Implementation context says Planned / Unmapped but we have a control." The control exists but the mapping is not approved, or the mapping is outside its validity window for the requested date.
"Coverage percentage seems misleading." The summary coverage figure is the proportion of requirements determined as applicable — it is a scoping measure, not a compliance measure. For compliance, use Requirement Assurance.