Ask an ISO 27001 auditor what document they request first, and the answer is almost always the same: the Statement of Applicability (SoA). It is the single artifact that connects your risk assessment to your control environment — a declaration of which Annex A controls apply to your ISMS, which don't, and exactly why. Get it wrong and Stage 1 stalls; get it right and the rest of the audit has a backbone to follow.
What Clause 6.1.3 Actually Requires
The SoA is mandated by Clause 6.1.3(d) of ISO/IEC 27001:2022. The requirement is precise: you must produce a Statement of Applicability that contains the necessary controls — from Annex A and anywhere else — together with:
- A justification for inclusion of each control — linked to your risk treatment decisions.
- An implementation status — whether each included control is implemented or not.
- A justification for exclusion of any Annex A controls you decided not to apply.
Two subtleties trip people up. First, the SoA is not only about Annex A — controls from other sources (contractual obligations, NIST, internal policies) belong in it too. Second, "implemented or not" means an honest status: marking a control included-but-not-yet-implemented is perfectly acceptable; claiming implementation you can't evidence is not.
Where the SoA Sits in the Workflow
The SoA is an output, not a starting point. The sequence Clause 6.1 prescribes is: scope (4.3) → risk assessment (6.1.2) → risk treatment plan → SoA (6.1.3). Your risk assessment identifies what could go wrong; the risk treatment plan decides whether to modify, retain, avoid, or share each risk; and the SoA records which controls execute that plan. This ordering is why you cannot legitimately copy someone else's SoA — it encodes your risks, scope, and treatment decisions.
If you haven't baselined yet, our ISO 27001 gap analysis guide covers the assessment that comes before all of this, and the free gap analysis tool produces a clause-by-clause readiness report you can use to prioritize SoA work.
Annex A:2022 — The Menu You're Choosing From
The 2022 revision restructured Annex A into 93 controls across 4 themes (down from 114 in 14 domains in the 2013 edition):
- A.5 Organizational — 37 controls: policies, roles, asset management, supplier relationships, incident management, business continuity.
- A.6 People — 8 controls: screening, awareness and training, disciplinary process, remote working, confidentiality agreements.
- A.7 Physical — 14 controls: perimeter security, entry controls, equipment protection, clear desk, secure disposal.
- A.8 Technological — 34 controls: access control, authentication, cryptography, network security, logging, vulnerability management, backups, secure development.
Each control now also carries attributes (control type, security properties, cyber concepts, operational capabilities) — useful metadata for filtering and reporting, though the attributes themselves are informative, not requirements.
Anatomy of a Good SoA
Whether it's a spreadsheet or a GRC tool, a usable SoA has a consistent row structure. Minimum columns:
- Control reference and title (e.g., A.8.2 — Privileged access rights)
- Applicable? — Yes / No
- Justification — one or two sentences tying the decision to a risk, obligation, or scope boundary
- Implementation status — Implemented / Partial / Planned / Not implemented
- Evidence / link — where the proof lives (policy doc, config export, training records)
- Owner — who is accountable for the control
- Related risks — the risk register entries this control treats
Worked Example Rows
Three rows showing the range of honest answers:
- A.8.2 Privileged access rights — Applicable: Yes. Justification: admin access to production identified as high risk (R-12). Status: Implemented. Evidence: IAM policy + quarterly access review. Owner: CISO.
- A.7.4 Physical security monitoring — Applicable: No. Justification: fully remote organization, no owned premises; office access controlled by landlord under shared-responsibility agreement documented in supplier register. Status: N/A.
- A.8.28 Secure coding — Applicable: Yes. Justification: in-house SaaS product handles customer PII. Status: Partial — secure SDLC documented, SAST in CI, penetration test scheduled Q1. Owner: VP Engineering.
Notice the middle row: a legitimate exclusion, justified by scope, with the residual coverage point documented elsewhere. Auditors accept "not applicable, here's why" — they reject "not applicable" with a blank justification.
How to Justify Exclusions (and When You Can't)
You can exclude an Annex A control only when it is not necessary for your risk treatment. Valid justifications sound like: "no physical premises in scope," "no cardholder data processed — PCI controls unnecessary," "development outsourced — supplier control A.5.19 covers this risk instead." Invalid justifications sound like: "too expensive," "we're small," "we'll do it later." If a control treats an identified risk, excluding it without an alternative treatment is a nonconformity waiting to be found. Exclusions are where inexperienced implementations fail audits — not because they excluded too much, but because they couldn't show the reasoning.
Common SoA Mistakes
- Copying a template SoA wholesale. Auditors spot the same boilerplate justifications across dozens of companies. Your justifications must reference your risk register and scope.
- Treating it as a one-time document. The SoA is living documentation — update it when risks change, controls are implemented, or scope shifts. It belongs in your management review (Clause 9.3) inputs.
- All controls "implemented." Suspicious and usually false. An honest "Partial" with a remediation plan reads far better than unverifiable claims.
- No link between risks and controls. If control X doesn't map to risk register entry Y, the auditor can't verify your treatment plan — and neither can you.
- Missing version control and approval. The SoA is documented information under Clause 7.5 — it needs an owner, a version, a date, and management approval.
What Auditors Check
At Stage 1, auditors verify the SoA exists, is approved, covers all 93 Annex A controls (included or justifiably excluded), and is consistent with your scope and risk assessment. At Stage 2, they sample included controls and ask for evidence — which is why the "evidence link" column matters more than any formatting choice. An SoA that says "A.5.15 access control — implemented" with no pointer to the actual policy, config, or review record sends the auditor hunting, and hunting auditors find nonconformities.
The SoA Beyond ISO 27001
The mechanism is spreading. ISO/IEC 42001 (AI management systems) uses the same pattern — an AI Statement of Applicability selecting from its own 38 Annex A controls. If you build your ISMS SoA properly, the muscle transfers directly to AI governance — see our ISO 42001 guide and AI readiness assessment.
Frequently Asked Questions
Is the Statement of Applicability mandatory for ISO 27001?
Yes. Clause 6.1.3(d) makes the SoA a required piece of documented information. Without it a certification body cannot proceed — it is typically the first document requested at the Stage 1 audit.
How many controls does the SoA cover?
Under ISO/IEC 27001:2022, Annex A contains 93 controls across four themes (Organizational, People, Physical, Technological). Every one must appear in your SoA — marked applicable with justification and status, or excluded with justification. The 2013 edition had 114 controls in 14 domains; certified organizations had to transition by October 2025.
Can I exclude Annex A controls?
Yes — but only when a control is not necessary for your risk treatment, and you must justify each exclusion in the SoA itself. "No physical offices" is a legitimate exclusion for physical controls; "too expensive" is not. Any control needed to treat an identified risk cannot be excluded without an alternative treatment.
What is the difference between the risk assessment and the SoA?
The risk assessment (Clause 6.1.2) identifies and evaluates threats to your information assets. The SoA (Clause 6.1.3) records which controls you chose to treat those risks, their implementation status, and justifications. The assessment finds the problems; the SoA documents the answers.
How often should the SoA be updated?
Whenever something material changes — new risks identified, controls implemented or retired, scope modified, incidents revealing gaps — and at minimum at your periodic management review (Clause 9.3). Auditors at surveillance audits will compare it to the previous version and ask what changed and why.
