The Statement of Applicability is required by clause 6.1.3(d) of ISO 27001:2022. It documents every one of the 93 Annex A controls — whether you have implemented it, why you have or have not, and where the implementing evidence lives. The certification body auditor will read your SoA before they walk into your office. If it is internally inconsistent, missing controls, or weakly justified, the rest of the audit goes downhill from there. This guide takes you through the SoA from first principles to certification-ready output.
What Is the Statement of Applicability?
The Statement of Applicability is a controlled document — typically a spreadsheet or a structured table inside your ISMS documentation — that lists every Annex A control alongside four mandatory pieces of information: whether it applies to your organisation, the justification for that decision, the current implementation status, and where the implementing controls and evidence are located.
It is the document that translates your risk assessment into a concrete control register. The risk assessment tells you what could go wrong and how badly. The SoA documents which Annex A controls you have selected to address those risks — and equally important, why you have decided certain controls do not apply to your organisation.
If you are unfamiliar with the Annex A control set itself, our walkthrough of all 93 Annex A controls covers the four categories (Organisational, People, Physical, Technological) in detail. The SoA references that exact same control list.
Why the SoA Matters More Than You Think
Auditors read your SoA before they walk into your office. They use it to plan the audit. They cross-reference it during the on-site review. They return to it when writing the final report. Every weakness, inconsistency, or unjustified exclusion they find becomes a finding.
Other ISMS documents matter, but the SoA is the master inventory. It is where the auditor's pen touches first and last. A clean, defensible SoA signals a mature ISMS programme; a sloppy or generic SoA signals the opposite — and auditors will dig deeper to find more problems.
Beyond audit, the SoA also serves as your internal map. When a new control needs implementation, when a vendor questionnaire asks about a specific Annex A area, when you onboard a new compliance owner — the SoA is the reference. Done well, it pays back many times over the effort of building it.
What the SoA Must Contain
ISO 27001:2022 clause 6.1.3(d) requires four pieces of information for every Annex A control. Most mature SoAs include a fifth and sixth column to make the document operationally useful. Here is the minimum versus the practical structure.
| Column | Required by 6.1.3(d)? | What it captures |
|---|---|---|
| Control ID & name | Mandatory | Reference to the Annex A control (e.g., A.5.1, A.8.24) |
| Applicability (Yes / No) | Mandatory | Whether the control applies to your organisation |
| Justification | Mandatory | Why the control is included or excluded — the business or risk reasoning |
| Implementation status | Mandatory | Implemented / Partially implemented / Planned / Not applicable |
| Reference document(s) | Strongly Recommended | Pointer to the policy, procedure, or technical control that implements it |
| Owner | Strongly Recommended | Named individual or role accountable for the control |
The justification column is where most SoAs fail an audit. "Industry best practice" is not a justification. "Required by the risk assessment" without a risk reference is not a justification. The auditor wants to see a defensible link between identified risk, regulatory obligation, contractual requirement, or business decision — and the control selection.
A Sample SoA Entry
Here is what a well-constructed SoA entry looks like for a single control, illustrated with two contrasting examples — one included, one excluded.
The two patterns are different but the underlying logic is the same — every cell tells the auditor exactly what they need to know, with no follow-up question required. That is the bar.
How to Build the SoA
Building the SoA is a six-step process. It assumes you already have a defined ISMS scope and a completed risk assessment — both prerequisites without which the SoA cannot be built.
The SoA is bounded by the scope of your ISMS. If you have not finalised the scope, do that first — see our walkthrough on ISO 27001 scope definition. Out-of-scope assets, business units, and locations are excluded from SoA consideration entirely.
Start from the official ISO 27001:2022 Annex A — all 93 controls across A.5 (37 organisational), A.6 (8 people), A.7 (14 physical), A.8 (34 technological). Use the standard reference numbering exactly. Do not abbreviate, paraphrase, or renumber.
For every risk in your risk register that requires treatment, identify which Annex A controls (one or many) address that risk. This mapping is what justifies inclusion. Many controls will be selected by multiple risks — record all the references in the justification column.
Some controls will be selected not by risk but by external requirement — DPDP Act, GDPR, customer contractual clauses, sector regulations. Capture these as separate justifications. A single control may have both risk-based and regulatory justifications.
For controls you exclude, provide a clear, defensible reason — typically based on scope (the asset class is not present), the shared responsibility model (a third party operates the control), or the risk profile (the control addresses a risk that does not exist for your organisation). Generic exclusions like "not applicable to our business" will fail.
For every included control, the SoA must point to where the control actually lives — the policy that mandates it, the procedure that operates it, or the technical configuration that enforces it. Auditors will follow these references during Stage 2. Broken references are a fast way to fail.
Including vs Excluding — What Auditors Look For
The SoA is not just an inventory; it is a series of decisions. Each decision needs to stand up to scrutiny. Here is what good and bad decisions look like, side by side.
✅ Defensible Inclusions
- Controls tied to identified risk register entries
- Controls required by regulation (DPDP, GDPR, sector laws)
- Controls required by enterprise customer DPAs
- Controls justified by business decision and documented elsewhere
- Controls cited as compensating controls for excluded ones
⚠️ Risky Inclusions
- Controls "for completeness" with no risk linkage
- Controls included but not actually implemented
- Controls referencing draft or non-existent policies
- Controls owned by no one — orphaned controls
- Controls copied from a generic SoA template without review
✅ Defensible Exclusions
- Physical premises controls when fully cloud-native and operating in shared, leased space
- Application development controls when no in-house development exists
- ICS or operational technology controls when no OT environment is in scope
- Controls handled by third party with retained evidence (e.g., AWS, GCP SOC 2)
⚠️ Risky Exclusions
- "Not applicable to our business" with no further justification
- Excluded because "we do not have time to implement"
- Excluded because the team does not understand the control
- Excluded contradicting the risk assessment
- Excluded contradicting the ISMS scope statement
Common SoA Mistakes
1. Generic Justifications Copied Across Controls
The fastest way to fail a Stage 1 review is to use the same justification ("Required by ISO 27001 best practice") for dozens of controls. Auditors see this as evidence the team has not actually thought about each control. Each justification should be specific to that control and ideally reference the underlying risk or requirement.
2. SoA Out of Sync with the Risk Register
If a risk in the register requires a treatment that maps to control A.5.20, and the SoA marks A.5.20 as not applicable — that is a major non-conformity. Internal consistency between the risk assessment, the risk treatment plan, and the SoA is non-negotiable. Build the cross-reference and audit it before the auditor does.
3. Missing the 11 New 2022 Controls
ISO 27001:2022 introduced 11 new controls — including threat intelligence (A.5.7), cloud services (A.5.23), data masking (A.8.11), DLP (A.8.12), and secure coding (A.8.28). Organisations that built their SoA against the 2013 version need to specifically address these. Auditors check this first because it tells them whether the SoA has been refreshed or just reused.
4. Excluding Controls the Scope Includes
If your scope statement says you operate in a leased office in Pune, you cannot exclude all physical security controls on the basis of being cloud-native. The SoA must be consistent with the scope. Misalignment here is one of the most embarrassing audit findings because it reveals the documents were written separately and never reconciled.
5. Implementation Status That Does Not Match Reality
Marking a control as "Implemented" when the policy is in draft, or when the procedure is documented but not operating, will be caught during Stage 2 testing. It is far better to be honest — "Partially implemented, target completion Q2 2026" — than to overstate. Auditors respect candour and downgrade trust quickly when reality contradicts the SoA.
6. Treating the SoA as a One-Time Deliverable
The SoA must be reviewed and updated when scope changes, when the threat environment shifts, when new regulations apply, and at the annual ISMS management review at minimum. A document dated two years ago with no version history is a red flag that the entire ISMS may be coasting.
Keeping the SoA Current
The SoA is a living document. The mature ISMS pattern is to integrate SoA review into existing operating rhythms rather than treating it as a discrete annual task.
- Quarterly: Review the SoA in your management review meeting. Capture any control whose status has changed (newly implemented, newly partial, newly retired).
- After every risk assessment cycle: Re-map risks to controls; update justifications where new risks have driven new control selections.
- After scope changes: If the ISMS scope expands or contracts, the SoA must be reviewed end to end. New scope often introduces new applicable controls.
- After regulatory changes: When DPDP, GDPR, or sector-specific guidance changes, revisit the regulatory justifications and any controls those changes affect.
- After incidents: A material security incident may indicate a control gap. Update the SoA implementation status if the incident reveals a control was not operating as documented.
- Before every certification or surveillance audit: Run a final consistency check between SoA, risk register, scope statement, and policy register. This is the time to catch and fix drift before the auditor does.
The SoA is one of several documents the auditor will examine in detail. For the broader audit-readiness picture, our walkthrough on how to prepare for a security audit covers the surrounding evidence, interview prep, and document control practices that complete the picture.
Build the SoA seriously the first time, keep it honest, and maintain it as a working document rather than an audit prop. Done that way, it stops being a chore and starts being one of the most useful artefacts in your entire ISMS.
Frequently Asked Questions
The Statement of Applicability (SoA) is a document required by ISO 27001 clause 6.1.3(d). It lists every Annex A control, declares whether each applies to your organisation, justifies inclusion or exclusion, records implementation status, and references the controlling documentation. It is the bridge between your risk assessment and your selected controls — the single document that proves you have made deliberate, justified decisions about your information security posture.
Yes. Clause 6.1.3(d) of ISO 27001:2022 explicitly requires a Statement of Applicability. Without one, you cannot pass certification. It is the most reviewed document in both Stage 1 and Stage 2 audits, and exclusions without justification will be raised as non-conformities.
All 93 Annex A controls from ISO 27001:2022 must appear in the SoA — including those you exclude. The SoA must address every control by reference; you cannot simply leave out controls you have decided do not apply. A typical SaaS startup applies 70–80 controls and excludes the rest with documented justification, most commonly the physical data centre controls for fully cloud-native organisations.
The risk treatment plan is the operational schedule for treating identified risks — it lists actions, owners, and deadlines. The SoA is the control register that documents which Annex A controls apply, why, and where they are implemented. The two link together: risks identified in the risk assessment drive control selection, which is then documented in the SoA. The risk treatment plan tracks the work; the SoA documents the decision.
At minimum, after every annual risk assessment. The SoA is also updated whenever your scope, threat landscape, applicable regulations, or organisational structure changes materially. Many mature ISMS programmes review the SoA quarterly to capture incremental changes. It is a living document, not a one-time deliverable.
No. Every excluded control requires a clear, documented justification. "Not applicable" alone is insufficient. The justification must reference the ISMS scope, the shared responsibility model, the risk profile, or another defensible basis for exclusion. Generic exclusions are one of the most common audit findings and frequently result in non-conformities.
ISO 27001 is format-agnostic — the SoA can be a spreadsheet, a structured table inside a Word document, a database, or output from a GRC tool. Most organisations use a spreadsheet for ease of sorting and filtering, but the format matters far less than the content quality. What matters is version control, cell-level traceability, and the ability to navigate the document quickly during an audit.