ISO 27001 Statement of Applicability: A Plain-English Guide

The ISO 27001 Statement of Applicability (SoA) is the single most important document in your information security management system. It lists every control from Annex A, states whether each one applies, and explains why. Your certification auditor uses it as a roadmap for the entire audit. Get it wrong, and the audit unravels from the start.

This guide explains what the SoA is, how it connects to the 93 Annex A controls in ISO 27001:2022, how to justify inclusions and exclusions, and the mistakes that trip up UK SMBs. For context on overall ISO 27001 certification costs — and how the SoA drives audit scope and fees — see our ISO 27001 certification cost breakdown.

What Is the Statement of Applicability?

Clause 6.1.3(d) of ISO 27001:2022 requires a Statement of Applicability containing:

• The necessary controls (from your risk assessment and treatment process)
• Justification for their inclusion
• Whether they are implemented or not
• Justification for excluding any Annex A controls

The SoA proves you've systematically considered every Annex A control. It also tells your auditor which controls to assess and provides the reason for any you've excluded.

The 93 Annex A Controls

ISO 27001:2022 reorganised Annex A from 114 controls (2013 edition) to 93 controls across 4 themes:

Theme	Controls
Organisational (A.5)	37
People (A.6)	8
Physical (A.7)	14
Technological (A.8)	34

Eleven controls are entirely new, including A.5.23 (cloud services security), A.8.9 (configuration management), A.8.12 (data leakage prevention), and A.8.28 (secure coding). Each of these 93 controls must appear in your SoA.

How to Write Your SoA

Step 1: Complete Your Risk Assessment First

The SoA flows from your risk assessment and risk treatment plan (Clauses 6.1.2 and 6.1.3). You identify risks, decide treatment, and select controls. The SoA documents which Annex A controls you selected and which you didn't need. Writing the SoA before the risk assessment works backwards — and produces justifications that won't survive audit.

Step 2: Create the SoA Table

A spreadsheet works. Create columns for: control reference, control name, applicable (yes/no), justification, implementation status (implemented/partial/not yet), and notes.

Step 3: Work Through All 93 Controls

For each, ask: does the risk exist in our environment? Did our risk assessment identify it? Is there a legal reason to include it? The Data Protection Act 2018 (UK GDPR) may require certain controls regardless — A.8.11 (Data masking) and A.8.10 (Information deletion) directly support UK GDPR data minimisation principles.

Step 4: Justify Every Exclusion

Valid exclusion reasons:

• The risk doesn't exist. "We exclude A.8.28 (Secure coding) because we do not develop software." Defensible.
• Another control addresses it. "We exclude A.7.4 (Physical security monitoring) because our managed office provides 24/7 CCTV and access control under their own ISO 27001 certification." Also defensible.

Invalid reasons:

• "We don't have budget." Cost doesn't justify exclusion under ISO 27001.
• "We plan to implement later." Mark it as applicable with status "not yet implemented" — don't exclude it.
• "We didn't think it was relevant." Without a risk assessment link, this won't survive audit.

How Many Controls Can You Exclude?

No fixed limit, but patterns matter. Excluding 5–10 controls is typical for a UK SMB. More than 15–20 will draw scrutiny. More than 30 suggests the risk assessment missed things.

Cross-reference your SoA against the NCSC's Cyber Essentials and 10 Steps to Cyber Security to confirm you haven't overlooked applicable controls.

Common SoA Mistakes

Writing the SoA without the risk assessment. Every control's inclusion must trace back to a specific risk. No risk assessment, no traceability — that's a major nonconformity against Clause 6.1.3.

"N/A" without explanation. Every exclusion needs a documented reason, not just "N/A" in the justification column.

Missing non-Annex A controls. Clause 6.1.3(b) allows controls from any source. If your risk treatment uses PCI DSS controls or NHS Digital's Data Security and Protection Toolkit requirements, include them alongside Annex A.

Treating the SoA as static. Review it annually at management review, minimum. When your risk profile changes (new services, new threats, new regulations like the NIS Regulations 2018), update the SoA.

Confusing "not yet implemented" with "excluded." If a control applies but isn't done yet, mark it applicable with a target date. Hiding the gap by excluding it backfires — the auditor will identify the risk themselves.

Use our ISO 27001 controls checklist to work through all 93 controls and track implementation alongside your SoA.

Statement of Applicability Checklist

Before audit, verify:

• All 93 Annex A controls are listed — none omitted
• Each control has a clear applicable/not applicable determination
• Every exclusion has a justified reason linked to the risk assessment
• Every applicable control has an implementation status
• Non-Annex A controls from your risk treatment are included
• Version number, date, and approver are recorded
• Legal requirements (DPA 2018, UK GDPR, NIS Regulations 2018) have been considered
• The SoA aligns with the risk treatment plan
• The document has been reviewed within the last 12 months
• If pursuing both standards, you've reviewed the shared management system clauses — Clauses 4–10 overlap heavily between ISO 9001 and ISO 27001

This article is for general informational purposes only and does not constitute legal, regulatory, or professional compliance advice. ISO certification requirements vary by scope, sector, and certification body. Always verify requirements with your UKAS-accredited certification body or a qualified consultant before making compliance decisions.