What the SoA is
The Statement of Applicability is a mandatory document listing all 93 Annex A controls, stating whether each one applies to your ISMS, and justifying the decision either way. It is required by clause 6.1.3.
It is the document that connects everything else together. Your scope says what the ISMS covers. Your risk assessment says what could go wrong. The SoA says which controls follow from that, and why the others do not.
It is also the first thing a Stage 1 auditor opens, because it tells them in one document whether you have thought about the standard or filled in a template.
What it must contain
| Element | Required | What good looks like |
|---|---|---|
| All 93 controls listed | Yes | Every control present, none quietly omitted |
| Applicable yes or no | Yes | An explicit decision per control |
| Justification for inclusion | Yes | Tied to a specific risk or a legal or contractual requirement |
| Justification for exclusion | Yes | A reason, not a blank cell |
| Implementation status | Yes | Implemented, partial, or planned with a date |
| Reference to the control | Good practice | Where the control actually lives — a policy, a system, a procedure |
The last row is not strictly required but it is what turns the SoA from a compliance artifact into a working document. An auditor asking how control 8.16 is implemented should be able to read the answer rather than ask a second question.
Justifying an exclusion properly
Exclusions are normal. Most organizations exclude a meaningful number of controls, and cloud-native companies exclude or inherit much of the physical theme. What matters is the reason.
Justifications that work:
The activity does not occur — for example, secure development controls where you build no software. Physical controls performed by a named cloud provider under a documented shared responsibility model. A control addressed by another control you have implemented, with the compensating control named.
Justifications that fail:
Not applicable, with no elaboration. Too expensive. We are too small. Out of scope, where the scope statement does not actually exclude it. Each of these is an invitation for the auditor to look harder, and they usually find something.
Why Stage 1 reads it first
Stage 1 is a documentation review. The auditor is deciding whether your ISMS is coherent enough to be worth testing at Stage 2 — and the SoA is the fastest way to find out.
What they are checking:
Does it cover all 93? A missing control is an immediate finding. Do the inclusions trace to risks? Controls included with no corresponding risk suggest the risk assessment is decorative. Are the exclusions defensible? This is where most Stage 1 findings originate. Does it match the scope? An SoA excluding controls for areas the scope statement includes is an internal contradiction.
See Stage 1 vs Stage 2 for what happens next.
The template problem
Downloadable SoA templates are widely available and they are a reasonable starting structure. The failure is treating the pre-filled justifications as answers.
A template arrives with plausible justifications for every control. They were written for a hypothetical company. An auditor who has read forty SoAs recognises template language immediately, and the follow-up question is always the same: which risk drove this decision? If the answer is that the template said so, Stage 1 gets longer.
Use the structure, write your own justifications. It is a day of work and it is the difference between a smooth Stage 1 and a remediation cycle.
Keeping it current
The SoA is a living document, and it is one of the first things surveillance audits check for drift. It should be revisited when scope changes, when the risk assessment is refreshed, when you adopt a new system or supplier, and at minimum annually alongside the management review.
An SoA whose last modified date precedes a major architectural change is a finding waiting to happen.
FAQs
What is the Statement of Applicability in ISO 27001?
A mandatory document, required by clause 6.1.3, listing all 93 Annex A controls with a decision on whether each applies to your ISMS and a justification for that decision. It connects your scope and risk assessment to the controls you actually implement.
Is the Statement of Applicability mandatory?
Yes. It is one of the documented information requirements of ISO 27001 and a certification body will not proceed without it. It is also typically the first document reviewed at Stage 1.
How do I justify excluding an Annex A control?
Give a specific reason tied to your organization: the activity does not occur, the control is performed by a named provider under a shared responsibility model, or another implemented control addresses the same risk. Not applicable with no elaboration is the most common cause of a Stage 1 finding.
What is the difference between the SoA and the risk treatment plan?
The risk treatment plan says what you will do about each identified risk and by when. The Statement of Applicability records which Annex A controls that implies, plus a justified decision on every control you are not applying. The treatment plan drives the SoA, not the other way round.
How often should the Statement of Applicability be updated?
Whenever scope changes, the risk assessment is refreshed, or you adopt a significant new system or supplier — and at minimum annually alongside the management review. Surveillance audits check it for drift against what you actually run.
Where to go next
Work out which controls apply in Annex A controls, get the SoA drafted as part of an an ISO 27001 gap assessment, or see how the whole engagement runs in ISO 27001 consulting.