The Statement of Applicability: ISO 27001’s Most Important Document

Ask any ISO 27001 auditor which document they open first and you’ll get the same answer: the Statement of Applicability. Required by clause 6.1.3(d), the SoA is the bridge between your risk assessment and your controls — a single table that says, for every control, whether you apply it, why, and how far along you are. Get it right and the audit follows your script. Get it wrong and the audit becomes archaeology.

What the SoA must contain

For each of the 93 Annex A controls (ISO 27001:2022, organised into four themes — organisational, people, physical, technological), the SoA records:

The logic auditors trace

The SoA sits in the middle of a chain the auditor will walk in both directions: risk assessment → risk treatment plan → SoA → implemented control → evidence. Every included control should trace back to a risk or requirement, and every treated risk should trace forward to a control. The classic nonconformity is a break in that chain — a control marked “implemented” with no evidence, or a high risk treated by a control the SoA says is excluded.

Exclusions: where audits are won and lost

You are free to exclude controls — ISO 27001 certifies your management of risk, not a fixed checklist. But exclusions must be justified, and the justification must survive contact with your scope statement. If your scope includes a SaaS product, excluding secure development (A.8.25–A.8.31) will not fly. Common legitimate exclusions for cloud-native companies: physical-media controls where no removable media exists, or source-code escrow style controls with no applicable scenario. When in doubt, include the control and mark it “implemented via provider” with the inherited-control evidence.

Five mistakes that cause findings

• Copying a template SoA and forgetting to tailor the justifications — auditors spot boilerplate instantly.
• Version drift: the SoA references the 2013 control set (114 controls) after transitioning to 2022 (93).
• Status inflation: “implemented” where the honest answer is “planned” — one failed sample undermines the whole document’s credibility.
• No linkage to risks: justifications that say “best practice” instead of pointing at a risk register entry.
• Treating it as an annual artefact: the SoA must change when your risks, scope or controls change — a stale SoA is a clause 6.1.3 finding in itself.

Building it efficiently

• Start from the risk register, not the control list — decide treatments first, then let the SoA fall out of them.
• Give every included control an owner and a linked evidence source on day one.
• Keep it in a system, not a spreadsheet — so status, owners and evidence update live instead of quarterly.
• Review it at every management review and after any significant change (new product, new region, new provider).
• Reuse it: the same control decisions feed SOC 2, Cyber Essentials and CAF mappings — one library, many views.

The bottom line

The SoA is not paperwork — it is the index of your entire ISMS, and the auditor’s roadmap through it. Make it live: risk-linked, honestly statused, owned, and wired to evidence. Do that, and certification audits become confirmations rather than investigations.