ISO 27001 Content Hub
Statement of Applicability (SoA)
The mandatory document for ISO 27001 certification: all 93 Annex A controls, 9 mandatory fields, CC-BY-4.0 template to download.
The Statement of Applicability (SoA) is the central document of every ISO 27001 certification. It lists all 93 Annex A controls with their applicability, justification, implementation status, and reference to the corresponding policy. Without a complete, correctly filled SoA, ISO 27001 certification is not possible. Auditors use the SoA as their primary reference document to check whether your ISMS is complete and consistent.
What is the Statement of Applicability?
The Statement of Applicability is a mandatory document under ISO 27001:2022 Clause 6.1.3(d). The standard requires you to explicitly document for all Annex A controls whether they are applicable or not, and why. The SoA contains three core elements:
- 1.List of Controls: All 93 Annex A controls listed individually, structured by A.5 through A.8.
- 2.Justification: For each control, a written justification of why it is applicable or not applicable. "Not applicable" is not a free pass — it is a decision that requires justification.
- 3.Implementation Status: The current state of implementation per control: implemented, partially implemented, planned, or not applicable.
Certification auditors use the SoA as their primary reference document. They use it to check which controls you have declared applicable, then test on a sample basis whether the stated policies and evidence actually exist.
The Difference from the ISMS and Risk Treatment
A common misconception: the SoA is not the ISMS document itself. It is also not a risk treatment plan. These three documents have different roles:
| Document | Purpose | Content |
|---|---|---|
| ISMS Documentation | Describe the management system | Scope, context, policies, procedures |
| Risk Treatment Plan | Plan operational measures | Risks, measures, owners, timelines |
| Statement of Applicability | Formal declaration of controls | 93 controls, applicability, justification, status |
Risk treatment determines which controls are necessary. The SoA documents those decisions in a standardised format. The risk treatment plan shows how the controls are implemented operationally. All three documents must cross-reference each other and be consistent.
The 9 Mandatory Fields of an SoA Row
Each row in the SoA represents exactly one Annex A control. For the SoA to be audit-ready, each row needs these 9 fields:
Control Number
The official identifier per ISO 27001:2022, e.g. A.5.1. Standardised and immutable.
Control Title
The normative title of the control, e.g. "Information Security Policies". Take it verbatim from the standard.
Applicable (Yes / No)
"No" is permitted but always requires a written justification.
Justification for Applicability / Non-Applicability
Written and traceable. Example: "Not applicable: no physical server rooms within ISMS scope." Auditors scrutinise these justifications closely.
Implementation Status
Four possible values: implemented, partially implemented, planned, not applicable. "Planned" should not be older than 6 months.
Reference to Policy / Procedure
Link or document number of the corresponding policy. Example: "SEC-POL-001 Information Security Policy, Version 3.2".
Reference to Evidence
Where is the proof of implementation? Ticket number, audit log, training record, or system configuration.
Responsible Role
Who is accountable for this control? Always a role (not a name), e.g. CISO, IT Manager, HR Manager.
Last Reviewed (Date)
When was this control last reviewed? Mandatory for the annual revision and management review.
The 4 Annex A Categories in the SoA
ISO 27001:2022 organises the 93 controls into four thematic groups. The SoA must cover all four categories in full:
Organisational Controls
Policies, roles, supplier management, incident management, business continuity. The largest category with the most policy references.
Examples: A.5.1 Information Security Policies, A.5.19 Supplier Security
People Controls
Employee security from onboarding to offboarding: screening, training, remote work, reporting obligations.
Examples: A.6.1 Screening, A.6.3 Awareness and Training
Physical Controls
Building protection, access control, physical security zones, hardware protection. Particularly relevant for organisations with their own data centres.
Examples: A.7.1 Physical Security Perimeters, A.7.2 Physical Entry
Technological Controls
IT security measures: access controls, cryptography, network security, patch management, backup, secure development.
Examples: A.8.5 Secure Authentication, A.8.24 Use of Cryptography
Important: no control may be missing from the SoA. Even controls you rate as "not applicable" must be explicitly documented. The SoA is only complete when all 93 controls are listed.
Using Risk Treatment to Populate the SoA
The SoA should not be created in a vacuum — it should flow directly from your risk analysis. This 4-step workflow connects both:
Build the Risk Register
Identify all relevant information security risks in your organisation. Assess likelihood and potential impact. The risk register is the foundation for all subsequent decisions.
Map Controls to Each Risk
For each identified risk: which Annex A controls mitigate it? This step makes the causal relationship explicit and is critical for the justification quality in the SoA.
Mark Applicable Controls
All controls mapped to at least one risk are marked as "applicable" in the SoA. The result is a selection derived directly from the risk analysis, which is robust under audit.
Justify Non-Applicable Controls
For all remaining controls (those not mapped to any risk), write a justification. Also consider: are there other reasons for applicability, such as contractual requirements or sector-specific regulations?
Practical example: Control A.7.11 (Supporting Utilities) is a physical control for server room infrastructure. If your scope includes no physical server rooms, you can mark this control as "not applicable". SoA justification: "A.7.11 not applicable: no physical server room within ISMS scope. All IT infrastructure is operated with certified cloud providers (AWS EU)."
Common Mistakes When Creating the SoA
These five mistakes are the most common ones auditors see in practice:
"Not Applicable" Without Justification
Every "not applicable" decision needs a written justification. "n/a" or an empty field is an automatic audit finding.
SoA Created as a Last Step
The SoA should be developed in parallel with the risk analysis, not as retrospective documentation. An SoA backfilled after implementation is usually inconsistent.
Missing or Outdated Policy References
Controls without a policy reference are a red flag. Even worse: references to policies that have since been deleted or renamed.
"Planned" Status Older Than 6 Months
A control marked "planned" signals a need for action. If a control has been "planned" for more than 6 months, the auditor will ask for a binding implementation timeline.
No Clear Role Per Control
Every control needs an accountable role. Without accountability, there is no ownership, and auditors cannot verify whether anyone is actively responsible for the control.
Best Practice: SoA Versioning
The SoA is not a static document that goes in a drawer after certification. It is a living document that grows with your ISMS:
- →Annual revision is mandatory under ISO 27001 Clause 9.3 (Management Review). New risks, new controls, revised justifications.
- →Versioning with change history: Each new SoA version gets a version number (e.g. 2.0), a date, and a brief changelog entry.
- →Management approval: Changes to the SoA, especially new "not applicable" decisions, must be approved and documented by management.
- →Event-driven updates: New technologies (e.g. AI systems), changed business processes, or security incidents may require an extraordinary SoA revision.
Audit Perspective: What Auditors Look for in the SoA
ISO 27001 auditors follow a three-stage review process when examining the SoA:
Stage 1: Completeness
Are all 93 controls listed in the SoA? Not a single control may be missing. Even if you only mark 5 controls as "not applicable", all 93 must be explicitly documented.
Stage 2: Consistency with Risk Analysis
Does the applicability decision match the risk analysis? If your risk register shows a high data leakage risk but A.8.12 (Data Leakage Prevention) is marked "not applicable", the auditor will challenge this.
Stage 3: Sample Verification
The auditor selects a sample of controls and checks: does the referenced policy actually exist? Is the stated evidence present? Typical finding: SoA says "implemented", but the referenced policy has not been updated in 3 years or can no longer be found.
Tooling: SoA in Excel vs. GRC Software
The choice of tool affects how much effort SoA maintenance requires:
| Criterion | Excel / Spreadsheet | GRC Software |
|---|---|---|
| Getting Started | Immediate, no cost | Onboarding required |
| Scalability | Manageable up to ~50 employees | Scales without effort |
| Consistency | Must be ensured manually | Automatic via links |
| Evidence Linkage | Manual links / file storage | Automatic linking |
| Versioning | Manual file versioning | Automatic audit trail |
| Management Review | Export + email workflow | In-system with approval |
Excel works well for the first certification cycle if you have a small team and a manageable scope. By the second audit cycle, manual maintenance becomes burdensome. GRC software such as Kopexa automatically links SoA rows to the risk register, evidence archive, and management review workflow, saving time and preventing consistency errors.
Download: SoA Template (CC-BY-4.0)
To help you get started immediately, we have created a complete SoA template. It contains all 93 Annex A controls with the 9 mandatory fields as a fillable table. Licensed under CC-BY-4.0, so free to use with attribution.
ISO 27001:2022 SoA Template
93 Annex A controls, 9 mandatory fields, organised by category
CC-BY-4.0 licence — free use with attribution to Kopexa GmbH. Not a substitute for legal advice.
The template is a structured worksheet. It does not replace the individual engagement with your organisation's risks and your specific control decisions.
Related Resources
The SoA is a core element of ISO 27001 certification. Here are additional resources directly related to it:
More ISO 27001 Topics
Start
Certification
Industry Applications
Framework Mapping
Let's talk about your ISO 27001 implementation
Free & non-binding