The Statement of Applicability is the artefact that makes ISO 27001 different from every other compliance framework. Annex A lists 93 controls; the SoA is the document where you state which of those apply to your organization, why, and how they are implemented. Get it right and the rest of the audit is a checklist. Get it wrong and every finding traces back to it.
Most companies get it wrong, and the failure mode is nearly always the same: the SoA describes the organization as it was when the document was written, not as it is now.
Key takeaway
The SoA is a living artefact. When it stops being one, it stops being useful — first to the team, then to the auditor, then to the certificate itself.
What drift looks like
A typical drift pattern from a recent audit:
- The SoA states that control A.8.24 (cryptography) is implemented via a central KMS policy with quarterly key rotation.
- The KMS policy is still there. The quarterly rotation was automated twelve months ago and now runs every 90 days.
- Two business units have since adopted customer-managed keys outside the central policy. Neither is documented.
- The audit evidence for A.8.24 is a screenshot of the central policy from last year. Nothing in it reflects the current state.
The finding is not “you lack a cryptography control.” The finding is “your SoA does not describe your actual controls,” and that finding casts doubt on every other control in the document. It is the most damaging kind of non-conformity because it is systemic.
Why the SoA drifts
Three mechanisms, and each one is fixable:
1. Controls are written by compliance, implemented by engineering
The SoA is typically authored by a compliance lead with input from owners. The implementation sits in code, IAM policies, runbooks, and configurations maintained by engineers. The feedback loop between the two — “we changed how this works, update the SoA” — is social, not systemic. It survives until someone gets busy.
2. The SoA is reviewed annually, the environment changes weekly
Cloud environments change at deployment cadence. Most SoAs are reviewed once a year, during the internal audit cycle. The gap between the document and reality grows monotonically for eleven months, then gets patched in a panic for the twelfth.
3. Annex A control IDs are an unnatural unit of tracking
Engineers do not think in Annex A numbers. They think in IAM policies, Terraform modules, CI pipelines, and alert rules. Mapping those artefacts back to control IDs is bookkeeping, and bookkeeping is the first thing to slip.
The mechanism that keeps the SoA honest
The fix is not more diligence. It is to invert the ownership model.
Make each control owner a named engineer, not a compliance function
A control that is “owned by security” is owned by nobody. A control that is “owned by the platform team’s infrastructure lead” has a Slack handle. Quarterly, that lead receives the relevant slice of the SoA and is asked one question: “does this still describe how the control works?” If yes, sign off. If no, propose the edit.
Attach each control to its implementation artefact
For every Annex A control the SoA declares as applicable, the SoA entry should reference the artefact where the control lives — the Terraform module, the IAM policy name, the runbook URL. When the artefact changes, the SoA entry gets reviewed, because the artefact is versioned and its git log is visible.
Pattern
Add SoA impact as a PR checklist item on any infrastructure repo that hosts control implementations. “Does this change the SoA?” becomes a line in the review checklist. Most of the time the answer is no — but when it’s yes, the SoA update happens in the same PR as the change, not nine months later.
Review the SoA quarterly, not annually
An hour per quarter is two orders of magnitude cheaper than the remediation work triggered by a systemic SoA finding. The review can be lightweight: walk through the delta in the artefact register since last quarter and ask, for each change, whether the SoA entry still reads correctly.
What to change before your next surveillance audit
- Convert the SoA from a standalone document into a view over a structured register. One row per applicable control, with named owner, implementation artefact, and last-reviewed date.
- Assign each row to a specific engineer. Share the view with them.
- Schedule a quarterly 60-minute review on the calendar. No exceptions.
- Add a PR checklist item in infrastructure repos that asks whether the change affects the SoA.
The SoA is the easiest ISO 27001 artefact to keep current and the easiest to let rot. Nothing about the standard demands the rot; it is an ownership problem dressed up as a documentation problem.