The ISO 27001 statement of applicability — usually shortened to the SoA — is the single most important document in your certification. It lists every Annex A control, states whether you have applied it, and explains why. Auditors treat the ISO 27001 statement of applicability as the map of your entire security programme, cross-checking it against your risk assessment and the evidence on the ground.
What is the Statement of Applicability?
The Statement of Applicability (SoA) is a mandatory document that lists all 93 Annex A controls and, for each one, records:
- Whether the control is applicable to your organization
- Whether it has been implemented
- The justification for including or excluding it
- Optionally, a reference to where it’s addressed (a policy, procedure, or system)
In short, it’s the definitive summary of your security posture in one place.
Why auditors care so much about it
The SoA ties everything together. It proves you’ve considered every control, that your decisions trace back to real risks, and that nothing was silently dropped. An auditor can start at the SoA and follow any line down into your Annex A controls, policies, and evidence. A weak or inconsistent SoA is a fast route to audit findings.
A ready-made SoA, done right.
The ISO 27001 Toolkit includes a pre-built Statement of Applicability covering all 93 Annex A controls, plus the risk assessment and policies that feed it — auditor-written and editable.
What a SoA row looks like
| Control | Applicable? | Implemented? | Justification |
|---|---|---|---|
| A.5.7 Threat intelligence | Yes | Yes | Required to anticipate attacks on cloud services |
| A.7.4 Physical security monitoring | No | — | Fully remote company; no physical offices in scope |
How to build your SoA
- Complete your risk assessment first. The SoA is an output of your risk work, not a starting point.
- Review all 93 controls. For each, decide applicability based on your risks and context.
- Justify every decision — especially exclusions. “Not applicable because we have no on-premises servers” is fine; a blank cell is not.
- Link to evidence. Point each applicable control to the policy or procedure that implements it.
- Keep it current. Update the SoA whenever your risks, scope, or controls change.
Common mistakes to avoid
- Marking controls “applicable” without any implementing policy behind them.
- Excluding controls with no justification (auditors will flag this immediately).
- Letting the SoA drift out of sync with your actual environment.
How to build your ISO 27001 statement of applicability
Start from your risk assessment and risk treatment plan, because the SoA is where those decisions are recorded. For each Annex A control, note whether it is included or excluded, the justification, and its implementation status. Inclusions need a reason tied to a risk or a legal, contractual, or business requirement; exclusions need a defensible explanation. Keep it concise but complete — a good ISO 27001 statement of applicability fits on a few pages yet lets an auditor trace any control back to a risk. The control catalogue it references is maintained by ISO, and the SoA must be reviewed whenever your risks or controls change.
Frequently asked questions
Is the SoA mandatory?
Yes — it’s one of the explicitly required documents in ISO/IEC 27001:2022. See the full required documents checklist.
Can we exclude Annex A controls?
Yes, provided you justify each exclusion based on your risk assessment and scope.
New to the standard? Start with our complete guide to ISO 27001 certification.
Bottom line: your ISO 27001 statement of applicability is where risk meets reality. Build it directly from your risk treatment decisions, justify every inclusion and exclusion, and keep it current, and it becomes the backbone of a smooth audit rather than its biggest hurdle.