A common mistake is treating the SoA like a checklist instead of a justification document. Teams often omit clear reasons for exclusions, fail to record implementation status, or let the version drift from the certificate. Another gap is not updating it after control changes, which weakens both audit readiness and the document’s value as a current map of the ISMS.
Why This Matters for Security Teams
The statement of applicability is one of the few iso 27001 artefacts that has to satisfy both governance and operational reality. It is not just evidence for an auditor; it is the bridge between risk treatment decisions, selected controls, exclusions, and the actual state of the ISMS. When organisations treat it as a static compliance worksheet, the document quickly stops reflecting how security is being managed. The standard itself makes clear that control selection and justification belong inside the management system, not as a one-time exercise in paperwork, as described in ISO/IEC 27001:2022 Information Security Management.
The practical risk is that a weak SoA can hide gaps in ownership, implementation, and review discipline. Security teams may think they are audit-ready because every control has a yes or no beside it, but that does not prove the decision was justified, current, or linked to risk. The more mature the ISMS, the more the SoA functions as a decision record that explains why a control is included, excluded, or only partly implemented. In practice, many security teams discover SoA weaknesses only after an audit finding or a major control change, rather than through intentional review.
How It Works in Practice
A good SoA should answer four questions for each Annex A control: is it applicable, why was it selected or excluded, how is it implemented, and where is the evidence of that implementation. That makes the document useful to auditors, but more importantly, it makes it useful to the organisation itself. The content should align to risk assessment outputs, Statement of Applicability decisions, control ownership, and current implementation status. It should also remain consistent with the control set defined in ISO/IEC 27002:2022 Information Security Controls.
- Record a clear justification for each exclusion, tied to risk and scope.
- Show whether the control is fully implemented, partially implemented, or planned.
- Link each applicable control to an owner, evidence source, or operational process.
- Review the SoA after material changes to scope, risk, incidents, or control design.
- Keep version control aligned with the live ISMS so the document does not drift from reality.
Another common failure is over-automation: teams copy control text into the SoA without tailoring it to their environment. That creates a document that looks complete but says very little. The strongest SoAs are concise, specific, and traceable. They show that the organisation has made deliberate decisions, not merely inherited a template. These controls tend to break down when the ISMS spans multiple business units with different risk owners, because the SoA becomes inconsistent as local teams update parts of it without a central review path.
Common Variations and Edge Cases
Tighter SoA governance often increases maintenance effort, requiring organisations to balance audit clarity against change-management overhead. That tradeoff matters because the right level of detail depends on how complex the ISMS is and how frequently controls change. Current guidance suggests that the SoA should be detailed enough to justify decisions, but not so verbose that it becomes unusable in day-to-day governance.
There are also edge cases where organisations get tripped up:
- Inherited controls from a group ISMS may be listed even when the local entity does not actually operate them.
- Shared services can blur ownership, making it unclear whether a control is managed centrally or by the business unit.
- Partial implementation is often recorded poorly, even though it is a legitimate state if clearly explained.
- Tooling changes can make a previously accurate control statement obsolete without anyone updating the SoA.
The biggest misconception is that the SoA is only for certification. In reality, it is a living management document that should help security leaders explain coverage, exceptions, and progress. Where organisations have mature control testing and frequent change, the SoA works best when it is reviewed alongside risk treatment plans and internal audit cycles. Where governance is fragmented or control ownership is ambiguous, the document becomes stale quickly because no single function feels responsible for keeping it aligned with the ISMS.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | SoA decisions should reflect risk management governance and documented control choices. |
Tie each SoA control decision to risk management records and keep governance approvals current.
Related resources from NHI Mgmt Group
- What do organisations get wrong about ISO 27001 and identity governance?
- What do teams get wrong when they treat ISO 27001 as a compliance checklist?
- What do organisations get wrong when they secure AI only at the model layer?
- What do organisations get wrong when they let AI assistants handle privacy lookups?
