Statement of Applicability (SoA): The Single Most Important ISO 27001 Document

Everything you need to know about writing, maintaining, and defending your Statement of Applicability — the document auditors will spend the most time on.

By RGI bv editorial teamPublished December 4, 1969Updated December 27, 19699 min read
SoADocumentationAudit

If you only get one ISO 27001 document right, make it the Statement of Applicability. It's the bridge between your risk assessment, your risk treatment plan, and the 93 Annex A controls — and it's the first thing every external auditor opens.

What a SoA must contain

Clause 6.1.3 d) of ISO 27001:2022 is explicit. For every Annex A control your SoA must record:

  • Whether the control is applicable (yes/no)
  • The justification for inclusion or exclusion
  • Whether the control is currently implemented
  • A reference to the policy, procedure, or evidence that supports it

How to actually write one

Most teams use a spreadsheet with one row per control. Don't over-engineer the format — auditors care about content, not styling. Typical columns: Control ID, Control name, Applicable (Y/N), Justification, Implementation status, Reference to evidence, Owner.

Common audit findings on the SoA

  • Generic justifications. "Not applicable — we are a cloud company" is not a justification. Spell out why the underlying risk doesn't apply.
  • Stale references. Policy v1.0 was retired 18 months ago but the SoA still points to it.
  • Mismatched status. SoA says "implemented" but the auditor finds no evidence.
  • Inheriting from the cloud provider without saying so. Document the shared responsibility model.

Versioning and review

Treat the SoA as a controlled document. Version, date, approver. Review at least annually, and any time the risk assessment changes materially (new product, new region, new supplier with elevated risk).

Related posts

Related: external

RGI bv — ISO 27001 implementation support

Keep reading