Start with the direct answer.
To write a Statement of Applicability, start with the current scope of the ISMS, the risk assessment and treatment decisions, and the control set you are using. Then document which controls are applicable, why they are applicable or excluded, how they are implemented, and where the supporting evidence or policy sits.
The Statement of Applicability should not read like a pasted Annex A table. It should read like a current management record that explains the organisation's control choices clearly enough for internal owners, auditors, and reviewers to follow.
What the SoA is actually doing.
The SoA sits between the abstract control set and the reality of your implementation. It explains which controls matter in your environment, how the organisation treats them, and where to look next if someone wants to test the answer.
That is why a weak SoA causes more pain than its size suggests. If the logic is vague or the links to evidence are stale, teams end up reconstructing the story manually every time they need to explain their controls.
What to include in a useful SoA.
The exact table format can vary, but the underlying questions should stay clear. A reviewer should be able to read the SoA and understand what the control is doing in the ISMS, not just where it sits in the numbering scheme.
- Control identifier and clear control name
- Applicability decision
- Rationale for inclusion or exclusion
- Implementation status or implementation note
- Owner or accountable function where appropriate
- Reference to linked policy, process, record, or evidence location
Common mistakes to avoid.
The easiest mistake is to treat the SoA as a one-time spreadsheet task. The second is to keep justifications so generic that they stop being useful. The third is to let the SoA drift away from current risk treatment and evidence.
In practice, the SoA works best when it is reviewed as part of the live operating model rather than as a side document updated only before audit.
Prefer to talk it through?
If your SoA feels inherited or overgrown, talk to AI-27001.
A lot of SoAs look finished until someone asks for the current evidence and rationale behind them. If you are cleaning one up, our team can talk through the next step.