Statement of Applicability
Build a clearer ISO 27001 Statement of Applicability.
Create control applicability decisions, implementation statuses, and justifications that are easier to explain during audit.
What a Statement of Applicability is
The Statement of Applicability (SoA) is the central control document of an ISO 27001 Information Security Management System. It lists every Annex A control, records whether the control applies, justifies the decision, and states whether the control is implemented, partially implemented, planned, or not applicable.
It is required by Clause 6.1.3 d) of ISO 27001:2022 and is one of the first documents an auditor will read.
Why auditors care about the SoA
The SoA shows how risk, controls, exclusions, and evidence fit together. A weak SoA undermines the rest of the ISMS.
It proves you understand the standard
ISO 27001:2022 Clause 6.1.3 d) requires a Statement of Applicability. Auditors check it on day one of Stage 1.
It connects risk to controls
Every applicable Annex A control should trace back to a risk, a legal requirement, or a business need.
Exclusions must be justified
Auditors will challenge any control marked Not Applicable without a clear, business-based reason.
Implementation status must be honest
Marking everything as Implemented when it is not is a fast way to fail Stage 2.
How the SoA connects risk, controls, exclusions, and evidence
- Risk: Risks identified in your risk assessment justify which Annex A controls apply.
- Controls: Each applicable Annex A control is selected to treat one or more risks or to meet a legal, contractual, or business requirement.
- Exclusions: Controls that do not apply must have a clear, business-based reason - not just "Not applicable".
- Evidence: Each implemented control should map to evidence (a policy, a record, a screenshot, a sign-off) that proves it is actually in place.
Why weak justifications cause problems
"Not applicable" is the most common reason an auditor raises a nonconformity on the SoA. Be specific, be business-based, and explain the compensating processes.
A.8.25 Secure development lifecycle
"Not applicable."
Likely outcome: auditor raises a minor nonconformity or observation. You will be asked to rewrite it on the spot.
A.8.25 Secure development lifecycle
"Control excluded because the organisation does not perform software development. Supplier-developed applications are managed through supplier security, access control, and change management processes."
Likely outcome: auditor accepts the exclusion and moves on.
What your SoA looks like
Each row links a control to a justification, an implementation status, the risk it treats, and the evidence that proves it.
| Annex A control | Applies? | Justification | Implementation status | Linked risk | Evidence |
|---|---|---|---|---|---|
| A.5.15 Access control | Yes | Required to protect customer data and meet contractual obligations. | Implemented | R-007 Unauthorised access | Access control policy, quarterly access review |
| A.8.25 Secure development lifecycle | No | Organisation does not perform in-house software development. Supplier-developed applications are managed through supplier security, access control, and change management. | N/A | - | Supplier security policy |
| A.5.7 Threat intelligence | Yes | Needed to anticipate phishing and ransomware threats relevant to our sector. | Partial | R-012 Phishing | Threat intel subscription, monthly review notes |
| A.8.9 Configuration management | Yes | Required to maintain secure baselines on production systems. | Planned | R-019 Misconfiguration | Baseline standard (draft) |
Sample shown for illustration. Your actual SoA reflects your scope, risks, and controls.
What the SoA Generator does for you
All 93 Annex A controls
Pre-loaded with the full ISO 27001:2022 Annex A across Organisational, People, Physical, and Technological themes.
Justification prompts
Guided prompts help you write justifications an auditor will accept, instead of one-line answers that get challenged.
Audit-ready export
Export your SoA to a clean Excel or Word document you can attach to your ISMS documentation.
What the SoA Generator does not do
The SoA Generator helps you structure and justify your control decisions. It does not guarantee certification, replace professional judgement, or replace your certification body's audit. Your SoA must reflect your actual scope, risks, and implementation - not a template.
Frequently asked questions
What ISO 27001 and GRC practitioners are saying
"A useful audit reference for showing which applicable security controls have been implemented."
Comments have been lightly edited for clarity and attributed using first name and broad professional role. They are practitioner feedback, not formal customer testimonials.
Write an SoA that holds up in a Stage 2 audit.
Decide applicability, justify exclusions, and link risks and evidence in one place.
Use the SoA Generator