The Statement of Applicability (SoA) is the one document that ties your whole ISO 27001 programme together. It lists every Annex A control, states whether it applies, and explains why. Auditors start here because it reveals, at a glance, whether you have actually thought about your risks — or just copied a template.
A weak SoA is the fastest way to a finding. A strong one makes the rest of the audit a confirmation exercise: the auditor reads your justification, asks to see the evidence, and moves on.
What the SoA actually is
It is the bridge between your risk assessment and your controls. Risk treatment decides what you will do about each risk; the SoA records which Annex A controls you apply as a result, and is explicit about anything you leave out. It is mandatory, and it is the document most likely to be requested first.
The columns that matter
However you format it, a defensible SoA answers four things for every control:
- Applicable? — included or excluded.
- Justification — why, tied to a risk or a requirement.
- Status — implemented, partially, or planned.
- Reference — the policy, process or evidence that proves it.
Justifying inclusions
For each included control, tie it to something concrete: a risk from your assessment, a legal or contractual requirement, or a business need. “Because the standard lists it” is not a justification. “To mitigate risk R-014, unauthorised access to customer data” is.
Marking a control “implemented” with no reference to evidence. If the SoA says implemented, the auditor will ask to see it. Link each one to the artefact that proves it operates.
Justifying exclusions
Exclusions are legitimate — but only with a reason that survives scrutiny. A control may not apply because you do not perform that activity (for example, no in-house software development). Record the specific reason; never exclude a control simply because it is inconvenient or unimplemented.
Keep it a living document
Your SoA should change when your risks change — a new system, a new supplier, a new product line. If it has not been touched since certification, that is itself a red flag. Tie SoA review to your risk-assessment cadence so the two stay in lockstep.
What auditors check
Expect them to sample: pick a few included controls and trace them to evidence, then pick an exclusion and challenge the rationale. They are testing whether the SoA reflects reality. When every line links to a live artefact, that test is quick. A continuous evidence layer keeps those links current instead of stale.
Key takeaways
- The SoA bridges your risk assessment and your controls — and auditors open it first.
- For every control: applicable?, justification, status, and an evidence reference.
- Justify inclusions against real risks; justify exclusions with specific, honest reasons.
- Review it whenever risks change — a static SoA is a red flag.
Want an SoA that stays current on its own? Book a 30-minute demo and we will connect your controls to live evidence.
This article is general guidance, not legal advice. Verify obligations and deadlines for your organisation with qualified counsel.