Start from the risk assessment and risk treatment plan, then list each Annex A control, whether it applies, why it was selected or excluded, who owns it, and when it was implemented and last reviewed. The strongest SoA is a living control register, not a static compliance artifact, because it connects risk decisions to operational evidence and helps auditors verify that controls are intentional and current.
Why This Matters for Security Teams
An iso 27001 statement of applicability (SoA) is often the document auditors use to test whether an information security management system is real, current, and risk-led. It should explain why controls were selected or excluded, not simply list Annex A items. A weak SoA creates audit friction, hides gaps between policy and practice, and makes internal review harder because no one can trace decisions back to the risk assessment or treatment plan.
For teams aligning governance with operational reality, the SoA should read like a control decision log that is easy to evidence. That means clear ownership, implementation status, review cadence, and a direct link to the risks the control addresses. The structure is similar in spirit to the NIST Cybersecurity Framework 2.0 and its emphasis on outcomes tied to governance and risk management, even though ISO 27001 has its own certification model. The best SoAs help both auditors and security leaders see whether the control set is intentional, complete, and maintained.
In practice, many security teams discover SoA weaknesses only after an auditor asks for evidence that the stated control decisions were reviewed and approved, rather than through routine governance.
How It Works in Practice
A defensible SoA starts with the risk assessment and the risk treatment plan, then maps each relevant Annex A control to a documented decision. For every control, the organisation should state whether it applies, why it was included or excluded, who owns it, and what evidence proves it is implemented. That evidence can point to policies, procedures, technical settings, tickets, metrics, or review records, but the SoA itself should remain a summary register rather than a document warehouse.
The practical test is whether a reviewer can follow the logic from risk to control to evidence without guesswork. Security teams often improve audit readiness by standardising the wording used for control rationales. For example, exclusions should not say a control is “not relevant” without context; they should explain the environment, the risk analysis, and any compensating control. Where a control is applicable but only partly implemented, the SoA should reflect the current state honestly and link to a remediation plan.
- Use a single owner for each control decision, even if multiple teams contribute evidence.
- Review the SoA after material risk changes, not just before certification audits.
- Keep control names and references aligned with the current Annex A version.
- Link SoA entries to evidence repositories, not to vague narrative descriptions.
Mapping controls to a recognised control baseline can improve consistency, and many teams use NIST SP 800-53 Rev 5 Security and Privacy Controls as an internal design reference, even when ISO remains the certification target. That is especially useful when a control needs stronger operational detail for engineering, cloud, or identity teams. These controls tend to break down when the SoA is maintained as a yearly document exercise in fast-changing cloud environments because ownership and implementation drift faster than the review cycle.
Common Variations and Edge Cases
Tighter control documentation often increases maintenance overhead, requiring organisations to balance audit clarity against change-management effort. That tradeoff becomes visible when the SoA must cover hybrid infrastructure, outsourced services, or rapid platform change without turning into a frozen spreadsheet.
There is no universal standard for how much evidence detail belongs inside the SoA itself versus in linked records. Current guidance suggests keeping the SoA concise and using references to source artefacts for depth, but some certification bodies expect more narrative around exclusions and shared responsibility. Teams should treat that as a review expectation to confirm early, not as a reason to overstuff the document.
This is also where identity and privilege controls can matter indirectly. If an Annex A control depends on privileged access, supplier access, or administrative separation, the SoA should make the dependency explicit so internal reviewers can test whether the control owner understands the real operating model. That approach aligns naturally with ISO/IEC 27001:2022 Information Security Management and its companion ISO/IEC 27002:2022 Information Security Controls, which together frame selection and implementation of controls rather than mere checklist compliance.
Where organisations fail is usually not in choosing controls, but in allowing the SoA to drift away from the risk register, ownership model, and evidence base as systems, vendors, and threats change.
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, NIST SP 800-53 Rev 5, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | SoA decisions should trace back to governance and risk management outcomes. |
| NIST SP 800-53 Rev 5 | Useful as an internal control design reference for richer implementation detail. | |
| NIST SP 800-63 | Identity and access dependencies often sit behind Annex A control effectiveness. | |
| NIST Zero Trust (SP 800-207) | 5.1 | Zero Trust principles help explain control dependency and ownership in modern environments. |
| NIST AI RMF | GOVERN | Risk-led governance is central to making the SoA audit-defensible and current. |
Use 800-53 as a benchmark to define clear control ownership, evidence, and implementation depth.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for ISO 27001?
- How should security teams prepare for ISO 27001 certification without creating audit churn?
- How should teams speed up ISO 27001 compliance without losing audit quality?
- How should organisations implement ISO/IEC 27001 when they are building a formal information security management system?
