ISO 27001
January 2026
What is a Statement of Applicability and why does it matter for ISO 27001?
By Swapna De., Managing Director, AuditVantage® GmbH
The Statement of Applicability is one of the most misunderstood documents in ISO 27001. Getting it right is not optional, it is the mandatory link between your risk assessment, the Annex A controls, and the scope of your certificate. Auditors read it first. Some audit it forensically.
What the SoA actually is
The Statement of Applicability is a document required by Clause 6.1.3(d) of ISO 27001:2022. It lists every Annex A control (93 in the 2022 edition), states whether each is applicable to your organisation, justifies inclusion or exclusion, and notes implementation status for applicable controls. It is not a spreadsheet exported from a tool. It is the reasoned output of your risk treatment process.
A well-written SoA tells the auditor the story of your ISMS in a single document. A poorly written one tells them you bought a template.
Why auditors read it first
The SoA is the map. An auditor reviewing it sees at a glance whether your control selection reflects a genuine risk assessment or whether controls were accepted wholesale from a template. Exclusions are where credibility is gained or lost. "Not applicable, we do not develop software" for control 8.25 is reasonable and defensible. "Not applicable" for A.6.3 awareness training in an organisation with employees is not.
What good looks like
Per-control justification in the organisation's own language. Not a generic policy quote. The reasoning should reference your specific risk assessment findings and business context.
Implementation status keyed to evidence. Each applicable control points to documented evidence, a policy, a process, or an artefact the auditor can inspect.
Consistency with the risk treatment plan. Controls selected in the SoA must match the treatments chosen for identified risks. Divergence signals a process problem.
Version-controlled. The SoA evolves. Each revision is dated, approved, and reviewed at least annually in management review.
Common mistakes
Declaring all 93 controls applicable to avoid difficult conversations, this commits the organisation to implementing controls that bring no risk reduction. Copying another organisation's SoA justifications verbatim, auditors recognise boilerplate. Treating the SoA as a one-time deliverable, it should be a living document reviewed whenever the ISMS scope or risk landscape changes materially.
Frequently asked questions
Related questions on this topic, answered from the audit chair.
Why is the Statement of Applicability mandatory?+
ISO/IEC 27001:2022 Clause 6.1.3 requires a Statement of Applicability for every certified ISMS. The SoA records which Annex A controls are applicable, which are excluded, why, and how applicable controls are implemented. The certification body uses the SoA as the spine of the Stage 2 audit. Every applicable control listed in the SoA must be supported by evidence that the control operates as described.
How often does the SoA need to be updated?+
The SoA is updated whenever applicability or implementation changes. New risks, new processes, organisational changes, and significant changes to controls all trigger updates. At minimum, the SoA is reviewed during management review. Treating the SoA as a static document signed once at implementation and never revisited is a frequent finding category at surveillance audits.
How long should an SoA be?+
The length is determined by the scope and complexity of your operations, not by a target page count. A focused ISMS with a tight scope and clearly justified exclusions can have a concise SoA. A complex multi-site organisation with broader scope will have a longer one. Defensibility matters more than length. A short SoA with weak justifications will fail audit scrutiny; a long SoA full of generic language will fare no better.
Can I exclude Annex A controls?+
Yes, with documented justification. Annex A is a reference list, not a mandatory checklist. Exclusions must be based on actual scope and risk decisions: the control is not relevant because the underlying activity does not exist in your scope, or the risk is treated through a different control. Exclusions that read as cost-saving rather than risk-based are challenged at audit.
Should I use a template SoA?+
Templates can accelerate the first draft, but a template SoA used without adaptation is one of the most common reasons SoAs fail audit scrutiny. The SoA must reflect your specific risks, your specific control implementations, and your specific scope decisions. Template language that does not match the organisation that signed it tells the auditor the document was never meaningfully reviewed.
What changed in the 2022 version of ISO 27001 for the SoA?+
The 2022 revision restructured Annex A into 93 controls across four themes (Organisational, People, Physical, Technological), down from 114 controls in the 2013 version. The SoA structure follows Annex A, so SoAs prepared against the 2013 version need to be remapped to the 2022 control set. Eleven new controls were introduced. Organisations that re-certified after October 2025 must use the 2022 control structure.