Free ISO 27001 SoA Template (2026) — All 93 Controls, Excel
Free ISO 27001 Statement of Applicability template with all 93 Annex A controls pre-loaded (XLSX, PDF, MD): applicability, justification, status, evidence.
Download this template
Version 1.0 · Updated Jul 13, 2026 · Free, no email required
ISO 27001 Statement of Applicability: Free Template
The Statement of Applicability (SoA) is the mandatory ISO 27001 document that lists all 93 Annex A controls of ISO/IEC 27001:2022, states whether each control is applicable or excluded, justifies both decisions, and records the implementation status of every applicable control — exactly what clause 6.1.3(d) requires. This free template ships with every control pre-loaded across the four Annex A themes, plus justification, evidence, owner and review columns, so you complete decisions instead of building spreadsheets.
Ask any certification auditor which document they open first and the answer is the SoA — it is the roadmap they audit against. Yet most teams still assemble it by hand, copying 93 control names from a PDF into a spreadsheet before they can make a single applicability decision. This template — available as XLSX, PDF, and a machine-readable Markdown file for AI agents — removes that step. It is the working companion to our ISO 27001 checklist, which walks the full certification journey; this page gives you the single most important artefact on that journey, ready to complete.
Key Takeaways
- The SoA is required by clause 6.1.3(d) of ISO/IEC 27001:2022 and must contain the necessary controls, the justification for their inclusion, their implementation status, and the justification for excluding any Annex A control.
- Annex A has 93 controls in four themes — Organizational (37), People (8), Physical (14), Technological (34) — and all 93 must appear in the SoA with an explicit decision.
- Eleven controls are new since the 2022 revision (flagged in the template), and since 31 October 2025 all valid certificates run against ISO/IEC 27001:2022 — a 2013-structured SoA is now an audit finding, not a formality.
- Exclusions need substance. Auditors accept "no physical offices" for perimeter controls; they do not accept cost or effort as justification.
- For EU companies the SoA works twice: the applicable-control set maps onto NIS2 Article 21(2) risk-management measures, so a well-kept SoA becomes reusable evidence for NIS2 compliance — the template includes the mapping sheet.
What's Inside the Template
The XLSX contains four sheets: the Statement of Applicability register itself (all 93 controls pre-loaded), an auto-calculated Summary (decisions and implementation counts per theme, plus completeness checks that flag undecided rows), a NIS2 Art 21 Mapping reference sheet, and Instructions. The PDF mirrors the register for print and review meetings; the Markdown variant carries the full structure with YAML metadata so an AI agent can draft your SoA from your risk register.
Here is a preview of actual register rows, one from each theme:
| Control ID | Control name | Theme | Applicable? | Justification (example) | Status |
|---|---|---|---|---|---|
| A.5.23 | Information security for use of cloud services | Organizational | Yes | Core SaaS stack processes customer data; treats risk R-12 (cloud provider compromise) | Implemented |
| A.6.7 | Remote working | People | Yes | Fully remote workforce; contractual and technical controls per remote-work policy | Implemented |
| A.7.1 | Physical security perimeters | Physical | No | No physical premises — fully remote organisation; office-dependent risks not present | — |
| A.8.12 | Data leakage prevention | Technological | Yes | Regulated customer data in scope; DLP tooling on endpoints and email gateway | Partially implemented |
Each row in the XLSX also carries the workflow fields auditors expect to probe — evidence reference, control owner, last-reviewed date — and dropdown validations keep the applicability and status values consistent. The 11 controls introduced in 2022 are flagged in their own column, so a team migrating an older SoA sees immediately where the gaps usually are.
How to Use It
Step 1 — Start from the risk assessment, not the control list. Controls are selected because they treat identified risks, legal obligations, or contractual commitments; the SoA records the outcome of that reasoning. Working the other way — ticking controls first, inventing risks later — is the single most common SoA failure mode, and experienced auditors recognise it on sight. If you have not run the risk assessment yet, the ISO 27001 checklist covers that stage in detail.
Step 2 — Decide all 93 rows. Every control gets an explicit Yes or No in the Applicable column. The Summary sheet counts undecided rows precisely because a blank row reads as an incomplete SoA in a certification audit. For applicable controls, write the justification for inclusion — which risk, law, or contract the control treats — set the implementation status, and reference the evidence that demonstrates it: a policy, a procedure, a system configuration, a record.
Step 3 — Justify exclusions substantively. Excluding a control is legitimate; excluding it lazily is not. The justification must show the control's subject matter genuinely does not apply to your organisation. A fully remote company can exclude several physical controls; a company with no in-house development can exclude parts of the secure-development set (A.8.25–A.8.31) — but should then look hard at outsourced development (A.8.30).
Step 4 — Keep it alive. Assign each control an owner and a last-reviewed date, keep the document under version control, and update it whenever the risk assessment, the control set, or the organisational context changes — then review it at least once per ISMS cycle, at management review and before each surveillance audit. A stale SoA is one of the fastest routes to a nonconformity, because it is the first inconsistency an auditor finds when comparing document against reality. Our guide to getting ISO 27001 certified explains how the SoA is tested at Stage 1 and Stage 2.
Standard Basis
The template is anchored in ISO/IEC 27001:2022, the current edition of the standard, including Amendment 1:2024 — the February 2024 "climate action changes" amendment that added a requirement to clause 4.1 to determine whether climate change is a relevant issue, and a note to clause 4.2 that interested parties can have climate-related requirements. Both feed the context analysis your SoA decisions ultimately trace back to. The transition period from the 2013 edition ended on 31 October 2025: certificates against ISO/IEC 27001:2013 have expired or been withdrawn, so every SoA now needs the 2022 Annex A structure — 93 controls, four themes — rather than the old 114-control, 14-domain layout. The official standard and ISO/IEC 27002:2022 (the implementation guidance catalogue) contain the control text; this template deliberately reproduces only the control identifiers and titles, so you will still need the standards themselves — from ISO or your national standards body — for the control requirements.
For EU companies, the SoA has a second life as regulatory evidence. NIS2 — Directive (EU) 2022/2555 — lists ten risk-management measure families in Article 21(2), from incident handling to supply-chain security and cryptography, and each maps onto identifiable Annex A controls. The template's mapping sheet pairs every Article 21(2) measure with its representative controls, mirroring the fuller Article 21 → Annex A mapping in our NIS2 guide — with the important caveat that ISO 27001 alignment supports but does not by itself demonstrate NIS2 compliance, because NIS2 adds its own governance, reporting and enforcement expectations under national transposition laws. The same reuse logic applies to demonstrating GDPR Article 32 security measures, where an ISO 27001 control set is widely treated as strong evidence of "appropriate technical and organisational measures".
Beyond the EU: UK and Norway
ISO/IEC 27001 is an international standard, so unlike our regulation-specific templates this one needs no jurisdictional translation — but the certification context differs. In the UK, accredited certification runs through UKAS-accredited certification bodies, and ISO 27001 sits alongside the government-backed Cyber Essentials scheme: Cyber Essentials covers five baseline technical controls, while ISO 27001 certifies the management system — larger UK buyers increasingly expect both. In Norway, certification bodies are accredited by Norsk akkreditering, and an ISO 27001 SoA doubles as strong evidence toward the NSM ICT Security Principles (grunnprinsipper for IKT-sikkerhet) — the national baseline of 21 principles and 118 measures that NSM itself maps to ISO/IEC 27002:2022, and that Norwegian public-sector buyers and the digitalsikkerhetsloven supervision regime reference. One SoA, kept current, feeds all three conversations.
From Spreadsheet to Living Evidence
A spreadsheet SoA proves you made the decisions; it cannot keep them true. Controls drift, owners change, evidence goes stale — and the document that was accurate at certification quietly stops matching reality. Orbiq's ISMS software keeps the same control register connected to live evidence, flags controls whose evidence has lapsed, and publishes the buyer-facing side to a European Trust Center — so the work you did for the auditor also answers the next customer security review. If you are still choosing your ISMS tooling, our comparison of the best ISMS software covers the field.
Sources & References
- ISO/IEC 27001:2022 — Information security management systems — the standard itself; clause 6.1.3(d) and Annex A.
- ISO/IEC 27001:2022/Amd 1:2024 — Climate action changes — published February 2024; clause 4.1/4.2 additions.
- Directive (EU) 2022/2555 (NIS2) — full text — Article 21(2) risk-management measures.
- ENISA — Technical Implementation Guidance on Cybersecurity Risk Management Measures — June 2025; maps NIS2 measures to international standards.
- NCSC — Cyber Essentials scheme overview — the UK baseline scheme alongside ISO 27001.
- NSM ICT Security Principles (grunnprinsipper for IKT-sikkerhet) — Norway's national ICT-security baseline, version 2.1, with NSM's own mapping to ISO/IEC 27002:2022.
Related Reading
Download this template
Version 1.0 · Updated Jul 13, 2026 · Free, no email required
Frequently Asked Questions
What is a Statement of Applicability in ISO 27001?
The Statement of Applicability (SoA) is the mandatory ISO 27001 document that lists all 93 Annex A controls, states whether each is applicable or excluded, justifies both decisions, and records whether each applicable control is implemented. It is required by clause 6.1.3(d) of ISO/IEC 27001:2022, and certification auditors use it as the roadmap for the entire audit.
What must the SoA contain under clause 6.1.3(d)?
Clause 6.1.3(d) requires four things: the necessary controls determined through the risk treatment process, the justification for including each control, whether each necessary control is implemented or not, and the justification for excluding any Annex A control. Anything beyond that — control owners, evidence references, review dates — is good practice rather than a textual requirement, but auditors expect to see it.
How many controls are in ISO 27001:2022 Annex A?
ISO/IEC 27001:2022 Annex A contains 93 controls in four themes: 37 Organizational (A.5), 8 People (A.6), 14 Physical (A.7), and 34 Technological (A.8). Eleven controls are new in the 2022 revision, including threat intelligence (A.5.7), information security for use of cloud services (A.5.23), configuration management (A.8.9), data leakage prevention (A.8.12), and secure coding (A.8.28).
Can I exclude Annex A controls from my SoA?
Yes — no Annex A control is automatically mandatory, but every exclusion needs a documented, substantive justification. 'We have no physical offices' is a valid reason to exclude physical-perimeter controls; 'it would cost too much' is not. All 93 controls must still appear in the SoA with an explicit applicable-or-excluded decision, and auditors will probe weak exclusion reasoning.
How often should the Statement of Applicability be updated?
ISO 27001 sets no fixed interval, but the SoA must stay aligned with your risk assessment and risk treatment plan. In practice that means updating it whenever risks, controls, or organisational context change materially, and reviewing it at least once per ISMS cycle — typically at each management review and before every surveillance or recertification audit.
Is the SoA the same as the risk treatment plan?
No. The risk treatment plan says what you will do about each identified risk — options chosen, owners, deadlines. The Statement of Applicability says which controls are in scope and why, control by control, with implementation status. They must be consistent with each other: every control the risk treatment plan relies on should appear as applicable in the SoA.