What must a Statement of Applicability contain?
For every Annex A control, the SoA records whether it is included, why, and whether it is implemented. For any control you exclude, it records the justification for excluding it.
Justifications must point somewhere real: a risk in your assessment, a legal obligation, a contractual requirement. A ticked list of the 93 control titles satisfies none of this.
You may also include controls from outside Annex A, for example cloud-specific controls, and they belong in the same document. The Statement of Applicability is itself one of the mandatory documents ISO 27001 requires.
What does a Statement of Applicability extract look like?
The rows below are paraphrased examples in my own wording, showing the level of reasoning an auditor expects. Your version will have 93 rows and your own evidence.
| Control area | Applies? | Justification | Status |
|---|---|---|---|
| Policies for information security | Yes | Required in all cases; underpins the management system and customer commitments | Implemented: policy set approved and reviewed annually |
| Segregation of duties | Yes, proportionately | Risk: single-person approval of payments and access grants in a small finance function | Implemented: dual approval in the finance system, with a compensating review where headcount prevents full separation |
| Secure development lifecycle | No | The organisation develops no software and operates no code pipeline; purchased platforms only. Supplier controls apply instead | Excluded: justification recorded, revisited if development is brought in-house |
| Information security for cloud services | Yes | Core systems are SaaS and cloud-hosted; shared-responsibility boundaries must be defined per service | Implemented: responsibility matrix maintained for each significant provider |
How do you build the Statement of Applicability?
The order matters. Complete the risk assessment and treatment plan first, as my risk assessment guide explains, and let the controls you select flow from the risks you accepted, treated or transferred.
Where a risk demands a control that Annex A does not name, add it. Where an Annex A control addresses a risk you do not have, exclude it and say why.
Auditors test this linkage at both Stage 1 and Stage 2. A SoA assembled from a downloaded grid usually comes apart in the first hour.
Which Statement of Applicability mistakes do I see most?
- Exclusions without justifications, or justifications that read "not applicable" with nothing behind them.
- "Implemented" claimed for controls with no evidence. If you claim it, expect to be asked to show it.
- A frozen document. New suppliers, systems and services change the answers; the SoA must change with them.
- Missing the 2022 additions: threat intelligence, cloud services and ICT readiness are still commonly overlooked by organisations working from older templates.
How do you keep the Statement of Applicability up to date?
Version it, date it, approve it, and review it at least annually and whenever something material changes.
At surveillance the auditor will compare the SoA against the controls you actually run. Keeping the two in step during the year, as my maintenance guide sets out, makes that a short conversation.