The Statement of Applicability is one of the most misunderstood documents in ISO 27001. Getting it right is not optional — it is the mandatory link between your risk assessment, the Annex A controls, and the scope of your certificate. Auditors read it first. Some audit it forensically.

What the SoA actually is

The Statement of Applicability is a document required by Clause 6.1.3(d) of ISO 27001:2022. It lists every Annex A control (93 in the 2022 edition), states whether each is applicable to your organisation, justifies inclusion or exclusion, and notes implementation status for applicable controls. It is not a spreadsheet exported from a tool. It is the reasoned output of your risk treatment process.

A well-written SoA tells the auditor the story of your ISMS in a single document. A poorly written one tells them you bought a template.

Why auditors read it first

The SoA is the map. An auditor reviewing it sees at a glance whether your control selection reflects a genuine risk assessment or whether controls were accepted wholesale from a template. Exclusions are where credibility is gained or lost. "Not applicable — we do not develop software" for control 8.25 is reasonable and defensible. "Not applicable" for A.6.3 awareness training in an organisation with employees is not.

What good looks like

Per-control justification in the organisation's own language. Not a generic policy quote. The reasoning should reference your specific risk assessment findings and business context.

Implementation status keyed to evidence. Each applicable control points to documented evidence, a policy, a process, or an artefact the auditor can inspect.

Consistency with the risk treatment plan. Controls selected in the SoA must match the treatments chosen for identified risks. Divergence signals a process problem.

Version-controlled. The SoA evolves. Each revision is dated, approved, and reviewed at least annually in management review.

Common mistakes

Declaring all 93 controls applicable to avoid difficult conversations — this commits the organisation to implementing controls that bring no risk reduction. Copying another organisation's SoA justifications verbatim — auditors recognise boilerplate. Treating the SoA as a one-time deliverable — it should be a living document reviewed whenever the ISMS scope or risk landscape changes materially.