The Statement of Applicability is the ISO 27001 document that lists every Annex A control, states whether it applies, and gives a reason for each inclusion and exclusion. Clause 6.1.3 makes it mandatory. It connects your risk treatment to the controls, and it is the master checklist your certification auditor works from.
What is the Statement of Applicability in ISO 27001?
The Statement of Applicability, or SoA, is the document required by clause 6.1.3 of ISO 27001. It records the controls you have judged necessary to treat your information security risks, why each one is included, whether it is implemented, and why any Annex A control has been left out.
Most people meet the SoA as a spreadsheet of 93 Annex A controls and assume the work is ticking the columns. That is the wrong way round. The controls come from your risk treatment first. You then compare that set against Annex A so nothing necessary is missed, and you write the comparison down. The SoA is that record. It is the single document that ties your risk assessment to controls an auditor can test, which is why it sits at the centre of an ISO 27001 certification and is a good place to start once you understand what ISO 27001 is.
What must the Statement of Applicability contain?
Clause 6.1.3 d sets four things the SoA must hold. Miss one and the document is incomplete.
| What the SoA records | What it means |
|---|---|
| The necessary controls | Every control your risk treatment needs, drawn from Annex A and any additional controls of your own |
| Justification for inclusion | The risk or requirement each included control addresses |
| Implementation status | Whether each control is implemented, in progress, or not yet in place |
| Justification for exclusion | The reason any Annex A control does not apply to your scope |
In practice the SoA accounts for all 93 Annex A controls so every one is marked applicable or not, plus any extra controls your risk treatment introduced that Annex A does not cover. Annex A is a reference set, not a fixed checklist. The readiness checklist covers the documents that sit around it.
Why does the auditor care so much about the SoA?
Because it is the master checklist for the whole audit. At Stage 1 the auditor reads your SoA against the risk assessment and Annex A and checks the exclusions are reasoned. At Stage 2 they sample the controls you marked implemented and ask for the evidence.
The quickest way to stall a Stage 1 is an SoA that does not exist yet, or one whose exclusions read “not applicable” with no reason. The SoA has to be finished before Stage 1, not built during it. An assessor reading “A.8.23 web filtering excluded, not applicable” on a cloud platform will stop and ask why, and a blank answer becomes a finding. This is also where how the two audit stages run.
How is the SoA different from the risk treatment plan?
Two documents, regularly confused. The risk treatment plan is the action plan: which risks, which treatment option, who owns the work, by when. The SoA is the standing control register: the full control set, each marked applicable or not, with status and justification. One is the plan of work. The other is the record of what controls govern the system. Both come out of the same risk treatment under clause 6.1.3, and the SoA must be approved before Stage 1.
What trips organisations up on the SoA?
Four mistakes show up again and again. The first is building it control first, straight from Annex A, so no control traces back to an actual risk. An auditor will pull that thread. The second is excluding controls with no justification, or excluding ones that plainly apply, like access control or logging on a system that clearly needs them. The third is marking a control implemented when it is only written down. Documented is not implemented, and Stage 2 is where that gap surfaces. The fourth is letting the SoA go stale the day after certification. It is living documented information; when the risk picture or the controls change, the SoA changes with them.
Treat the SoA as the spine of the ISMS, not a form to fill in at the end. Get it right and the rest of the audit has something solid to stand on.
Frequently asked questions
Yes. Clause 6.1.3 d requires it as documented information, and it must be in place before the Stage 1 audit. It is one of the few documents the standard names explicitly.
The risk treatment plan is the action plan for treating specific risks, with owners and dates. The SoA is the standing register of all controls, marked applicable or not, with justification and implementation status. Both derive from the same risk treatment.
You account for all 93, marking each applicable or not with a reason, and you add any controls your risk treatment needs that Annex A does not list. Annex A is a reference set, so controls can be excluded where justified.
Yes, where the control does not apply to your scope and you record the reason. An exclusion with no justification, or excluding a control that clearly applies, is a common audit finding.
Written by Gaurav Vikash, an ASD endorsed IRAP assessor and senior cyber security leader with 18 years of experience across Australia, the UK and Asia, including CISO and senior security leadership roles. He holds CISSP, CISA, CISM and CRISC and is an ISO 27001 and ISO 42001 Lead Implementer, and speaks regularly at industry conferences.
Sources:
- ISO/IEC 27001:2022, clause 6.1.3 (Statement of Applicability), 2022
- ISO/IEC 27002:2022 (control implementation guidance for Annex A), 2022
Last updated: 21 June, 2026