SoA Statement of Applicability.

Why ISO 27001 makes the SoA mandatory

The Statement of Applicability is the bridge between your risk work and the controls an auditor will actually inspect. ISO/IEC 27001 leaves the body of the standard deliberately open on which controls you must run, because the right answer depends on your context and your risks. The SoA is where you close that gap: for every reference control in Annex A, you record whether it applies, the justification for including or excluding it, whether it is already implemented, and where the supporting evidence sits. It is one of the few documents the standard names explicitly as required output, which is why no certification audit proceeds without it.

A useful way to think about it is that the SoA turns a generic control catalogue into a statement about your organisation specifically. The Annex A reference set is the same for everyone. Your SoA is not. Two certified companies of similar size can legitimately exclude different controls, because their risk assessments and their operating context differ. The document exists to make those choices visible and defensible rather than implicit.

How the SoA relates to risk assessment and risk treatment

The SoA does not stand alone. It is the downstream product of the risk assessment and the risk treatment plan, and the three have to agree. The risk assessment identifies what could go wrong. The risk treatment plan decides what to do about each risk, including which controls to apply. The SoA then declares, control by control, what that decision means against the Annex A reference set. When an auditor reads the SoA, they are really checking that the line from a documented risk, to a treatment decision, to an applied control, to actual evidence holds together end to end.

Exclusions deserve particular care. Marking a control as not applicable is legitimate, but only with a stated reason tied to your context. "We do not develop software in-house" is a defensible basis for narrowing certain development controls. "We did not get to it" is not an exclusion, it is a gap. Auditors probe exclusions precisely because they are where organisations sometimes hide unfinished work.

What practitioners actually maintain

Treating the SoA as a living register rather than a one-off spreadsheet is what separates a smooth surveillance audit from a scramble. In practice, maintaining it well looks like this:

1. Keep one row per Annex A control, with applicability, justification, implementation status and an evidence pointer that an auditor can follow without you in the room.
2. Re-cut the SoA whenever the risk assessment or treatment plan changes, so the three documents never quietly diverge.
3. Tie each evidence pointer to something real and current, a policy, a configuration, a ticket, a log, not a promise to produce it later.
4. Review the document on a fixed cadence and at management review, not only in the weeks before an audit.
5. When transitioning between versions of the standard, remap the SoA against the revised control set and confirm nothing fell through merged or newly introduced controls.

Done this way, the SoA stops being audit paperwork and becomes the index to your whole information security management system. It is the first document an experienced auditor asks for, because it tells them where everything else lives.