Two mandatory documents, one consistent story
If you're pursuing ISO 27001 certification, you will need both a risk assessment (clause 6.1.2) and a Statement of Applicability (clause 6.1.3(d)). These are separate documents with different formats and different audiences — but they must tell a consistent story. The risk assessment identifies what your risks are; the SoA documents which controls you've selected to address them. Auditors review both, cross-reference them, and will issue a nonconformity if they don't align.
Understanding how these two documents relate is essential before you start drafting either of them.
Quick comparison: risk assessment vs SoA
| Aspect | Risk Assessment (Clause 6.1.2) | Statement of Applicability (Clause 6.1.3(d)) |
|---|---|---|
| What it is | Analysis of threats, vulnerabilities, likelihood, and impact | List of all 93 Annex A controls with applicability decisions |
| ISO 27001:2022 clause | 6.1.2 | 6.1.3(d) |
| Mandatory? | Yes — documented information required (clause 6.1.2(e)) | Yes — explicitly required by 6.1.3(d) |
| What it lists | Assets, threats, vulnerabilities, risk scores, owners, treatments | All 93 Annex A controls, applicable/N/A, justification, implementation status |
| Who creates it | Risk owner / CISO / security team | CISO / SoA owner (separate role) |
| Who reviews it | Management; risk owners | Management; auditor at Stage 1 + Stage 2 |
| Level of detail | Detailed per-risk analysis | Per-control applicability and status summary |
| Review frequency | At least annually or on significant change | At least annually or when risk assessment changes |
| Auditor use | Validates risk identification quality and methodology | Verifies control selections are justified; checks implementation status |
The critical link: traceability
The ISO 27001:2022 standard requires that the risk treatment plan (clause 6.1.3(c)) and the SoA are derived from the risk assessment. Specifically:
- Clause 6.1.3(a): The organisation must determine all controls necessary to implement the risk treatment option(s) selected
- Clause 6.1.3(b): The selected controls must be compared to Annex A to verify no necessary controls have been overlooked
- Clause 6.1.3(c): A Risk Treatment Plan must be produced
- Clause 6.1.3(d): The SoA must include the selected controls, justification for inclusion, whether controls are implemented, and justification for any exclusion of Annex A controls
In practice, this means: every Annex A control selected in the SoA should be traceable to one or more risks in the risk assessment register. And every significant risk in the register should have corresponding Annex A controls in the SoA.
What auditors check in Stage 1 and Stage 2
ISO 27001 certification has two audit stages. Both examine the relationship between your risk assessment and SoA:
Stage 1 (document review): The auditor reviews your ISMS documentation to determine if it meets the standard's requirements. For the risk assessment and SoA, they will check: Does the risk assessment methodology exist and is it documented? Are risk owners assigned? Is the SoA complete (all 93 controls listed)? Are exclusion justifications plausible? Is there a version control trail?
Stage 2 (implementation audit): The auditor tests whether the controls in your SoA are actually implemented. They will sample risks from the register and trace them to the SoA, then verify the corresponding controls are operational. A control marked as "Implemented" in the SoA with no evidence will be a finding.
Common inconsistencies that cause audit findings
| Inconsistency | Why it's a problem | How to fix it |
|---|---|---|
| SoA marks A.7.x physical controls as applicable, but risk assessment has no physical security risks | No risk basis for the control selection — auditor will question the rationale | Either add physical security risks to the register, or mark A.7.x as N/A if cloud-native |
| Risk register has high-impact credential risks, but A.5.17 (authentication information) is marked N/A in SoA | Risk treatment is incomplete — a significant risk has no corresponding control | Mark A.5.17 as applicable and document the controls addressing it |
| SoA version date is older than risk assessment version date | Suggests SoA wasn't updated when risks changed | Always update SoA when risk assessment changes; keep version dates in sync |
| Risk assessment shows Critical risks but SoA implementation status is all "Planned" | No controls implemented for highest risks — auditor will question readiness | Either implement critical controls before applying for audit or show a credible treatment plan with dates |
| All 93 controls marked as "Applicable" with no exclusions | Unlikely for any organisation, especially cloud-native SaaS; signals the SoA wasn't genuinely completed | Exclude controls that genuinely don't apply (e.g., physical controls for cloud-native, fax for modern SaaS) |
The correct order of operations
Many organisations get the sequencing wrong. The correct order is:
- Define ISMS scope (clause 4.3) — what systems, processes, and assets are in scope
- Conduct risk assessment (clause 6.1.2) — identify assets, threats, vulnerabilities; score risks; assign owners
- Select risk treatments (clause 6.1.3) — decide Mitigate / Transfer / Avoid / Accept for each risk
- Select Annex A controls (clause 6.1.3(a)) — determine which controls implement the Mitigate treatments
- Compare to Annex A (clause 6.1.3(b)) — verify no controls were overlooked
- Write the SoA (clause 6.1.3(d)) — document all 93 controls with applicability decisions and justifications
- Write the Risk Treatment Plan (clause 6.1.3(c)) — document owners, timelines, and resources for implementing selected controls
- Implement controls — update SoA implementation status as controls go live
Starting with the SoA before completing the risk assessment produces an SoA with no risk basis. Starting with the controls before the risk assessment produces controls with no prioritisation rationale. Both are common mistakes.
When to update both documents
Both documents must be reviewed at least annually. But specific triggers should cause an update to both, because they must remain consistent with each other:
- A new significant threat is identified (update risk assessment → update SoA if new controls needed)
- A control is implemented or decommissioned (update SoA → verify risk treatment remains adequate)
- A new service or product feature is launched that's in scope (update risk assessment → potentially update SoA)
- A security incident occurs (update risk assessment → SoA may need to add or strengthen controls)
- A new sub-processor with significant data access is added (supply chain risk → update risk assessment → A.5.19 controls)
Related generators: ISO 27001 Risk Assessment Template, ISO 27001 Statement of Applicability, ISO 27001 Gap Assessment, Information Security Policy.
Related reading: ISO 27001 Clause 6.1.2 Risk Assessment Guide, ISO 27001 Statement of Applicability Guide, ISO 27001 Gap Assessment Guide.
⚠️ This guide is for informational purposes only and does not constitute legal advice. ISO 27001 certification requires engagement with an accredited certification body and qualified auditors.