ISO 27001 · Guide
ISO 27001 Statement of Applicability: what it is, with a worked example
ISO 27001 Statement of Applicability: what it is, with a worked example
Key takeaways
The ISO 27001 Statement of Applicability records, for every Annex A control, whether it applies, why, and how far implementation has got. It comes out of risk treatment: controls are excluded only when no risk in scope needs them, never because they are costly. Auditors read it at Stage 1 and test it at Stage 2, so every line should trace to a risk and to evidence.
- Clause 6.1.3 d)
- ISO/IEC 27001:2022 requires a Statement of Applicability under clause 6.1.3 d), produced after the organisation compares its necessary controls with Annex A so that none is inadvertently omitted.
- 93 controls
- Annex A of ISO/IEC 27001:2022 holds 93 controls in four themes. It replaced the 2013 Annex A, merging, updating and adding controls, so every Statement of Applicability had to be updated.
- 2013 transition
- Certificates to ISO/IEC 27001:2013 expired or were withdrawn at the end of the transition period on 31 October 2025, and transition audits had to cover the updated Statement of Applicability.
- UKAS accreditation
- UKAS is the UK's national accreditation body. It accredits the certification bodies that audit ISO 27001, against requirements including ISO/IEC 27006-1:2024 for bodies certifying an ISMS.
The certification body has sent its Stage 1 document request, and the Statement of Applicability is near the top. You have a spreadsheet with 93 rows, a column of "Yes" answers and a few "N/A" cells that nobody can explain. The audit date is fixed, and an enterprise deal is waiting on the certificate.
This guide shows the Statement of Applicability working. It is written for founders, CTOs and security leads at UK SaaS firms preparing for Stage 1, whether you are writing your first one or checking one that a consultant or tool produced. It includes a worked example, exclusion wording that holds up, ownership, update triggers and what the auditor checks.
What is a Statement of Applicability?
The Statement of Applicability is the mandatory ISO 27001 document, required by clause 6.1.3 d), that lists all 93 Annex A controls, says whether each one applies, justifies every inclusion and exclusion, and records implementation status. It is the bridge between risk treatment and the controls, and one of the first documents an auditor reads.
People shorten it to SoA. For what ISO 27001 is and how certification works, start with our ISO 27001 hub.
The Statement of Applicability is a short document with a long reach. Each line is a decision someone made about a risk, and the reason they made it. That is why an auditor reads it early: it tells them what your ISMS claims to do before they test whether it does.
A Statement of Applicability nobody can explain isn't a record of decisions. It is a record that no decisions were made.
How does the Statement of Applicability follow from risk treatment?
The Statement of Applicability is an output of risk treatment, not a starting point. You assess risks, choose a treatment for each, and work out the controls those treatments need. Then you compare your list with Annex A so nothing is missed, and record the result, control by control, in the Statement of Applicability.
The accreditation forum's transition rules for ISO 27001:2022, IAF MD 26, describe this order. The comparison with Annex A exists so that "any necessary information security control from the reference set in Annex A of ISO/IEC 27001:2022 is not inadvertently omitted". If the comparison finds a gap, the risk treatment plan is updated first.
The method for assessing and treating risk belongs to Clause 6.1, and this guide does not repeat it. What matters here is the rule that follows from it. A control is excluded because no risk in your scope needs it, never because it is hard or costly to implement. Whether you must implement every control is covered in our Annex A controls guide.
What does an ISO 27001 Statement of Applicability example look like?
A working Statement of Applicability has one row per Annex A control and six columns: control ID, control name, applicable, justification, implementation status and evidence reference. The example below is illustrative only, for a fictional 60-person UK B2B SaaS firm that runs production on a public cloud and works fully remotely.
| Control ID | Control name | Applicable | Justification | Implementation status | Evidence reference |
|---|---|---|---|---|---|
| 5.7 | Threat intelligence | Yes | Risk R-07: targeted phishing of finance and support staff | Implemented | Monthly threat review minutes |
| 5.23 | Information security for use of cloud services | Yes | Risks R-02 and R-11: all production data is hosted with one cloud provider | Implemented | Cloud provider assessment, configuration baseline |
| 6.7 | Remote working | Yes | Risk R-05: every employee works from home on company laptops | Implemented | Remote working policy, device compliance report |
| 7.4 | Physical security monitoring | No | No information processing at our premises. We use a serviced desk space with no servers or network equipment. Production runs in the cloud provider's data centres, covered under 5.23 | Not applicable | Office lease, cloud provider assurance report |
| 8.11 | Data masking | Yes | Risk R-09: customer data could reach test environments | Partially implemented | Test data procedure, open treatment action T-14 |
| 8.25 | Secure development life cycle | Yes | Risks R-03 and R-08: we build and ship our own software weekly | Implemented | Development policy, pull request review records |
| 8.30 | Outsourced development | No | All development is done by employees. No development work is contracted out. Reassess before engaging any agency or contractor | Not applicable | Contractor register (no development suppliers) |
Three things make this example work. Every "Yes" points to a risk ID, so an auditor can trace each control back to the risk register. Every "No" gives a business fact that can be checked, plus the condition that would change the answer. And the status column tells the truth: data masking is partly done, and the open action is named.
A real Statement of Applicability carries all 93 controls, plus any you add from other sources. Keep the control titles and leave the ISO control text out; the standard's wording belongs in your purchased copy, not your spreadsheet.
How do you word an exclusion an auditor will accept?
An exclusion holds up when it states a fact about your organisation that an auditor can verify, explains why that fact means no risk needs the control, and says what would change the decision. It fails when it is a label, an opinion or a cost argument.
| Control | Wording that fails | Wording that holds |
|---|---|---|
| 7.4 Physical security monitoring | "N/A, we are cloud based" | "No information processing at our premises. We use a serviced desk space with no servers or network equipment. Production runs in the cloud provider's data centres, covered under 5.23" |
| 8.30 Outsourced development | "Not relevant" | "All development is done by employees. Reassess before engaging any agency or contractor" |
| 8.11 Data masking | "Too expensive to implement this year" | Not an exclusion: the risk exists, so mark it applicable, record "Planned" and point to the treatment action |
The third row is the one to watch. Cost and difficulty are reasons to schedule a control, not to exclude it. Where a risk needs the control, the honest entry is "applicable, planned", with a date in the risk treatment plan.
Who owns, approves and signs the Statement of Applicability?
We recommend one named owner, usually the security lead or ISMS manager, who maintains the Statement of Applicability day to day. Top management approves each version, because it records which risks the business has chosen to treat. Control owners confirm the status of their own lines before each approval.
The form of sign-off matters less than the record behind it. What the auditor looks for is evidence that someone accountable has reviewed and accepted the content. In practice that means:
- Owner: keeps the document current and runs the review.
- Control owners: confirm the status and evidence for their controls.
- Approver: a director or the management review signs off each version.
- Record: the approval sits in the management review minutes or a version history, with a date.
Under Clause 6.1, named risk owners accept the residual risk. The approver of the Statement of Applicability should be those same senior people, or the forum they report to, so the trail from accepted risk to selected control stays unbroken.
When should you update the Statement of Applicability?
Update the Statement of Applicability whenever the inputs behind it change: a change to the ISMS scope, new or changed risks, a significant incident, an audit finding, or a new service or supplier. Review it at least once a year in management review, even when nothing has visibly changed.
The 2022 edition added a requirement to plan changes to the ISMS. IAF MD 26 lists it among the key changes: "changes to the ISMS shall be carried out by the organization in a planned manner". The Statement of Applicability is where many of those changes become visible.
Use these triggers:
- Scope change: a new product, office, legal entity or acquisition.
- New or changed risks: the outcome of a risk assessment, or a new threat.
- Incidents: a significant security incident that exposes a missing or weak control.
- Audit findings: internal audit results or certification body nonconformities.
- Annual review: a full pass at management review.
Control the document like any other ISMS record. Give each version a number, a date, an approver and a short change log. Our guide to ISO 27001 mandatory documents covers how documented information is controlled across the set.
What does the auditor check in the Statement of Applicability?
At Stage 1, the auditor reads the Statement of Applicability to check it exists, covers every Annex A control and justifies each decision. At Stage 2, the auditor tests whether it is true: sampling included controls for evidence, probing exclusions and tracing risks from the register to the controls that treat them.
Your auditor works for a certification body. In the UK, the national accreditation body, UKAS, accredits certification bodies for ISO 27001 certification and lists ISO/IEC 27006-1:2024 as the requirements for bodies that audit and certify an ISMS.
Expect these checks at each stage:
| Stage | What the auditor checks |
|---|---|
| Stage 1 | All 93 controls are listed; each has a decision and a reason; the version is approved and dated; the document matches the scope statement |
| Stage 2 | Sampled "implemented" controls have evidence; exclusions match observable facts; sampled risks trace through to Statement of Applicability lines; "planned" items appear in the risk treatment plan |
The ISO 27001 certification process guide covers both audit stages in full.
A status column that reads "Implemented" all the way down is the first thing a good auditor tests.
What changed between the 2013 and 2022 Statement of Applicability?
ISO 27001:2022 replaced the 2013 Annex A, so every Statement of Applicability had to be updated against the new control set. The control count fell from 114 controls in 14 clauses to 93 controls in four themes: organisational, people, physical and technological. Certificates against the 2013 edition expired or were withdrawn by 31 October 2025.
IAF MD 26 made that update part of the move: the transition audit had to include "the updating of the statement of applicability (SoA)". Which controls are new, merged or updated is covered in our Annex A controls guide.
If a Statement of Applicability you inherit still uses 2013 numbering such as A.12 or A.14, it was written for a standard you can no longer be certified against. Map it to the 2022 controls rather than editing old rows in place.
How does a Statement of Applicability work in ISO 27701 and ISO 42001?
The same pattern runs through both standards: assess risks, decide treatment, compare your controls with the standard's own control annex, then record and justify every decision. Only the control set changes. ISO 42001 applies it to AI risks; ISO 27701 applies it to privacy risks.
ISO/IEC 42001 is the AI management system standard. Its risk treatment step also leads to a Statement of Applicability, measured against its own Annex A of AI controls rather than the ISO 27001 set. If you add an AI management system to an existing ISMS, we recommend keeping one method and one format, with a separate Statement of Applicability for each standard's controls.
ISO/IEC 27701 changed in 2025. The 2019 edition extended an ISO 27001 ISMS, so its privacy controls were added to the existing Statement of Applicability. The 2025 edition stands on its own, with its own control annex, so a privacy-only organisation can run it without ISO 27001 underneath.
For a UK SaaS firm, the practical rule is simple. One method, one owner, and one Statement of Applicability per standard you are certified against.
What are the most common Statement of Applicability mistakes?
The mistakes to look for are justifications that say nothing, a status column that overstates progress, and a document that has not changed since it was first approved. Each one is easy to spot at Stage 1 and easy to fix before it.
- "N/A" with no reason. Every exclusion needs a checkable fact and a trigger to reassess.
- Everything implemented. Honest "partially implemented" and "planned" entries, backed by the treatment plan, read as a working ISMS.
- No link to risk. A "Yes" with no risk ID tells the auditor the control came from a checklist, not a decision.
- A frozen document. An approval date older than the latest risk assessment shows the two are not connected.
Frequently asked questions
An ISO 27001 SoA, or Statement of Applicability, is the document required by clause 6.1.3 d) of ISO 27001. It lists every Annex A control, states whether each applies, justifies each decision and records implementation status. Auditors read it early and use it to decide what to test.
Start from your risk assessment and risk treatment plan. List the controls each treatment needs, then compare that list with all 93 Annex A controls. Record a decision, a reason, a status and an evidence reference for each control, and have top management approve the first version.
Yes, where no risk in your scope needs the control. The justification must state a fact the auditor can check, such as having no outsourced development. A control cannot be excluded because it is expensive or difficult; that is a reason to plan it, not to remove it.
Update it whenever scope, risks or controls change, after significant incidents and audit findings, and review it at least once a year at management review. We recommend a simple rule between reviews: a control owner can update the status of a line, but a change to whether a control applies, or why, needs a new approved version.
Some enterprise customers ask for it during security due diligence, because the certificate alone does not show which controls are in scope. Decide in advance whether you share it in full, in summary or under a non-disclosure agreement, as it describes your security arrangements in detail.
Standard engine
ISO 27001 reference directory.
Every control in this framework and the clause guides that sit above them, grouped by control domain. Open any entry for its control definition, implementation steps and the audit evidence it expects. Dimmed entries are planned.
ClausesThe management systemClause guides · 23 guides
Clause 4.1Understanding the organization and its contextClause 4.2Understanding the needs and expectations of interested partiesClause 4.3Determining the scope of the information security management systemClause 4.4Information security management systemClause 5.1Leadership and commitmentClause 5.2PolicyClause 5.3Organizational roles, responsibilities and authoritiesClause 6.1Actions to address risks and opportunitiesClause 6.2Information security objectives and planning to achieve themClause 7.1ResourcesClause 7.2CompetenceClause 7.3AwarenessClause 7.4CommunicationClause 7.5Documented informationClause 8.1Operational planning and controlClause 8.2Information security risk assessmentClause 8.3Information security risk treatmentClause 9.1Monitoring, measurement, analysis and evaluationClause 9.2Internal auditClause 9.2Preparing for Your ISO 27001 Stage 2 Audit: A Practical ChecklistClause 9.3Management reviewClause 10.1Continual improvementClause 10.2Nonconformity and corrective action
A.5Organizational Controls37 guides
A.5.1Policies for information securityA.5.2Information security roles and responsibilitiesA.5.3Segregation of dutiesA.5.4Management responsibilitiesA.5.5Contact with authoritiesA.5.6Contact with special interest groupsA.5.7Threat intelligenceA.5.8Information security in project managementA.5.9Inventory of information and other associated assetsA.5.10Acceptable use of information and other associated assetsA.5.11Return of assetsA.5.12Classification of informationA.5.13Labelling of informationA.5.14Information transferA.5.15Access controlA.5.16Identity managementA.5.17Authentication informationA.5.18Access rightsA.5.19Information security in supplier relationshipsA.5.20Addressing information security within supplier agreementsA.5.21Managing information security in the ICT supply chainA.5.22Monitoring, review and change management of supplier servicesA.5.23Information security for use of cloud servicesA.5.24Information security incident management planning and preparationA.5.25Assessment and decision on information security eventsA.5.26Response to information security incidentsA.5.27Learning from information security incidentsA.5.28Collection of evidenceA.5.29Information security during disruptionA.5.30ICT readiness for business continuityA.5.31Legal, statutory, regulatory and contractual requirementsA.5.32Intellectual property rightsA.5.33Protection of recordsA.5.34Privacy and protection of PIIA.5.35Independent review of information securityA.5.36Compliance with policies, rules and standards for information securityA.5.37Documented operating procedures
A.6People Controls8 guides
A.6.1ScreeningA.6.2Terms and conditions of employmentA.6.3Information security awareness, education and trainingA.6.4Disciplinary processA.6.5Responsibilities after termination or change of employmentA.6.6Confidentiality or non-disclosure agreementsA.6.7Remote workingA.6.8Information security event reporting
A.7Physical Controls14 guides
A.7.1Physical security perimetersA.7.2Physical entryA.7.3Securing offices, rooms and facilitiesA.7.4Physical security monitoringA.7.5Protecting against physical and environmental threatsA.7.6Working in secure areasA.7.7Clear desk and clear screenA.7.8Equipment siting and protectionA.7.9Security of assets off-premisesA.7.10Storage mediaA.7.11Supporting utilitiesA.7.12Cabling securityA.7.13Equipment maintenanceA.7.14Secure disposal or re-use of equipment
A.8Technological Controls34 guides
A.8.1User endpoint devicesA.8.2Privileged access rightsA.8.3Information access restrictionA.8.4Access to source codeA.8.5Secure authenticationA.8.6Capacity managementA.8.7Protection against malwareA.8.8Management of technical vulnerabilitiesA.8.9Configuration managementA.8.10Information deletionA.8.11Data maskingA.8.12Data leakage preventionA.8.13Information backupA.8.14Redundancy of information processing facilitiesA.8.15LoggingA.8.16Monitoring activitiesA.8.17Clock synchronizationA.8.18Use of privileged utility programsA.8.19Installation of software on operational systemsA.8.20Networks securityA.8.21Security of network servicesA.8.22Segregation of networksA.8.23Web filteringA.8.24Use of cryptographyA.8.25Secure development life cycleA.8.26Application security requirementsA.8.27Secure system architecture and engineering principlesA.8.28Secure codingA.8.29Security testing in development and acceptanceA.8.30Outsourced developmentA.8.31Separation of development, test and production environmentsA.8.32Change managementA.8.33Test informationA.8.34Protection of information systems during audit testing
OtherAdditional Guides7 guides
ISO 27001 Accelerator
Ready to accelerate your path to certification?
Work with a Trust Architect to scope your ISMS, close the gaps, and get audit-ready — without stalling your roadmap.