The Statement of Applicability is one of the most important artefacts an ISMS produces — and one of the most consistently underwritten. The SoA explains which Annex A controls the organisation has implemented, which it has excluded, and the reasoning behind both. It is the document auditors examine first, customers ask to see during enterprise procurement, and regulators reference during investigations. Most SoAs are mechanical — long tables of controls with "yes" against each, identical justifications copied from templates, no narrative connecting decisions to organisational reality. The SoAs that hold up tell a coherent story.
What the SoA Is Actually Meant to Communicate
The Statement of Applicability has four components per Annex A control: whether the control is applicable to the organisation, whether it is currently implemented, the justification for inclusion or exclusion, and a reference to where the implementation is documented. Each of these has substantive content. "Applicable" means the control addresses a risk the organisation actually has. "Implemented" means the control is operational, not just documented. "Justification" means the reason the organisation reached the inclusion or exclusion decision. "Reference" means the documents, processes, or systems that demonstrate the implementation.
Why Generic Justifications Fail
A justification that reads "this control is required by ISO 27001" is not a justification — it is restating the prompt. A justification that reads "this control supports confidentiality, integrity, and availability of information" is generic enough to apply to any organisation and therefore conveys nothing. Strong justifications connect the control to the organisation's specific risk profile: "Applied because the organisation processes regulated payment card data on the in-scope systems and access controls are required to satisfy both ISO 27001 A.5.15 and PCI DSS." The audit value is the specificity, not the language.
Exclusions That Hold Up
Controls can be excluded if they are not applicable to the organisation. The exclusion must be defensible. A common mistake is excluding controls that look operationally inconvenient rather than genuinely inapplicable. ISO 27001 A.7 (physical controls) excluded by a cloud-native organisation because "we don't have offices" — except the organisation ships laptops to remote employees, which is exactly the physical security context the controls cover. Exclusions that an auditor can defeat with one follow-up question undermine the credibility of the entire SoA.
A useful test for any SoA exclusion: state the exclusion and the justification out loud, then ask "would this hold up if a reasonable auditor pressed on it?" Most exclusions in templated SoAs do not. The exclusion is convenient but not defensible. The remediation is either implementing the control (often easier than the exclusion implies) or producing a defensible justification that actually engages with the control's scope.
Linking the SoA to Risk Assessment
The Statement of Applicability is supposed to flow from the risk assessment. Controls included are those that address identified risks; exclusions are made where risks the control would address are not present in scope. SoAs that read as if they were written independently of the risk register lose this connection, and the audit visibly identifies the gap. Strong SoAs reference the specific risks each control addresses, with traceability back to the risk assessment artefact.
Components of a SoA That Carries Its Weight
- Control-by-control coverage with inclusion/exclusion decision per Annex A control
- Risk-linked justification — each inclusion references the specific risks it addresses
- Specific implementation reference — the document, process, or system that demonstrates operation
- Defensible exclusions with reasoning that survives auditor follow-up questions
- Version control and review history — the SoA should be updated as the ISMS evolves
- Approved by the appropriate level of management with documented evidence of approval
Why It Matters Beyond the Audit
Enterprise procurement increasingly asks for the SoA as part of vendor security due diligence. Insurance underwriters request it during cyber insurance underwriting. Regulators reference it during incident investigations. The audience for the SoA has expanded substantially beyond the certification audit, and the level of scrutiny varies. SoAs written for the certification audit alone often fail to satisfy the broader audience. Writing the SoA with this broader audience in mind produces an artefact that does multiple jobs well, rather than one that scrapes through a single annual audit and proves inadequate everywhere else.