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.
Free review
Not ready to book? Get a practical evidence next step instead.
Pick the lower-friction option that fits where you are. We’ll use your page and campaign context to understand the request without adding tracking clutter to the visible URL.
We’ll look at one evidence flow and send practical gaps or next steps.
Prefer to talk it through?
If your SoA feels inherited or overgrown, compare notes.
A lot of SoAs look finished until someone asks for the current evidence and rationale behind them. If you are cleaning one up, I’m happy to compare notes.