The ISO/IEC 27001 Statement of Applicability: how to write one that survives the audit

What the Statement of Applicability is, and why auditors start there

Clause 6.1.3 places the SoA inside risk treatment. Once risks are assessed and treatments chosen, you produce a statement of four things: the necessary controls, the justification for including them, whether each is implemented, and the justification for excluding any Annex A control. Because every exclusion needs a reason, the SoA in practice records a decision on all 93 Annex A controls, plus any drawn from other sources.

At the Stage 1 readiness review, the certification body checks that the SoA covers Annex A, fits the scope and agrees with the risk treatment plan. At Stage 2 it guides the testing: controls marked implemented are sampled for records, exclusions are compared with what auditors see, and cited risks are traced to the register. A weak SoA casts doubt on the risk assessment behind it.

How the SoA is derived, from risk to control decision

The SoA is an output of the risk process, not a checklist to start from. Tick Annex A rows first and the document fails the first question an auditor asks of any row: which risk does this control treat? Clauses 6.1.2 and 6.1.3 set the route.

1. Assess the risks against your defined criteria, each with a risk owner.
2. Choose a treatment for each, for example reducing it with controls, avoiding, sharing or accepting it. An accepted risk may need no control.
3. Determine the necessary controls from any source: your own design, a contract, a regulation or Annex A.
4. Compare the list with Annex A so that nothing necessary is missed. If a control there reveals an unassessed risk, add the risk to the register first.
5. Record the outcome in the SoA and the treatment plan, which risk owners approve while accepting the residual risk.

A worked example

A SaaS company's register holds the risk of client data exposed through a misconfigured cloud storage service. The risk owner chooses to reduce it, and four controls follow: secure baselines (A.8.9 Configuration management), rules for using and managing cloud services (A.5.23), alerting on unusual access (A.8.16 Monitoring activities) and a pre-deployment check the engineers designed, entered as an additional control. Each row cites the risk; the treatment plan dates anything not yet running. Our guide to ISO/IEC 27001 risk assessment and treatment, step by step covers the method.

What a good SoA row contains

The standard fixes the content, not the format: the first four columns carry what clause 6.1.3 d) requires, and the other three are good practice that anticipates the auditor's next question.

Version, date, approver and change summary belong in the header. For what each control covers, see Annex A: the 93 controls by theme, explained.

Four defects that sink an SoA at audit

• All 93 controls applicable, with no reasoning. It feels safe, but ask for the risk behind a few rows and the answer is always "Annex A lists it". Applicability is earned by a risk, a requirement or a business decision, and the justification should name which.
• Exclusions without a real justification. "Not applicable" is a conclusion, not a reason; "no software is developed in scope, and acquired SaaS is governed by the supplier and cloud controls" can be tested. Exclusions also age: a business that excluded A.8.28 Secure coding in year one may have staff writing integration scripts by year two.
• "Implemented" with nothing to show. A control is implemented when it operates and leaves a trace: a backup restore test, an access review that removed accounts, an alert someone investigated. A signed policy shows intent, not operation.
• No version control, or no match with the treatment plan. If the SoA says a control is due in March and the treatment plan says June, the auditor cannot tell which is true. As documented information under clause 7.5, the SoA needs identification, review, approval and change control.

Keeping the SoA alive through change

Clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur, and clause 6.3 requires changes to the ISMS to be planned. Each such moment should end with one question: does the SoA still describe what is true? Typical triggers are a new service, site, cloud platform or critical supplier, a contract with security clauses, a significant incident or an audit finding. The 2022 transition proved the point: IAF MD 26 required transition audits to cover the updated SoA and risk treatment plan.

Review the SoA whenever the register changes materially and before each management review, keep the version history, and have internal audits test a sample of rows against reality every year.

Multi-site and cloud scopes

One ISMS normally has one SoA, but controls rarely apply identically everywhere: a delivery centre with secure areas and visitors carries physical controls that matter far less at a small sales office. Show the difference inside the SoA, with a site column or annex recording where each control applies, how it is delivered and where its evidence sits. Separate SoAs per site drift apart, while the certification body audits one system.

In the cloud, the provider secures its data centres, while configuration, identity and access, logging and often backup of what you deploy remain yours. Keep a provider-operated control applicable and state how it is delivered, citing the provider's certificate or attestation report and your own supplier and cloud controls, including A.5.23. Excluding physical controls "because everything is in the cloud" ignores the offices, laptops and home workers still in scope. Because Annex A is not exhaustive, cloud providers and customers can add ISO/IEC 27017 controls, and public-cloud PII processors ISO/IEC 27018 controls, as additional rows.

ISO/IEC 27001 Statement of Applicability: questions buyers ask