The ISO 27001 Statement of Applicability, explained

Of everything an information security management system produces, the Statement of Applicability is the document auditors ask for first and read most closely. It is where your risk assessment turns into decisions: which controls you have chosen, why, and whether they are actually in place.

It is also the document most often written badly. Teams copy the list of Annex A controls into a spreadsheet, mark nearly everything "applicable", add one-line justifications such as "required by ISO 27001", and move on. That version passes nobody's scrutiny, because it shows no link between the risks you identified and the controls you selected.

This guide sets out what the standard actually requires, how to make the applicability decision control by control, and how to keep the document alive once it exists.

ISO/IEC 27001:2022 requires the Statement of Applicability in clause 6.1.3 d), as part of information security risk treatment. Read closely, the requirement has four parts. The document must contain:

Annex A of the 2022 edition lists 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). Your Statement of Applicability has to account for every one of them, either as included or as excluded with a reason.

The Statement of Applicability is not a starting point. It depends on three pieces of work that have to exist first.

When those three are in place, the Statement of Applicability almost writes itself: each selected control traces back to a treatment decision, and each exclusion can be explained by the scope or by the absence of the risk the control addresses.

When they are missing, teams end up writing the Statement of Applicability first and reverse-engineering a risk assessment to fit it. Auditors notice, because the justifications cannot point to anything.

Work through Annex A in order, and for each control ask four questions.

The most common mistake is excluding a control because it is inconvenient rather than because it is unnecessary. If a risk exists and the control is the obvious treatment, excluding it will not survive the audit conversation.

A good justification is short, specific and traceable. Compare these two entries for the same control:

The strong version tells an auditor where to look and proves the decision came from the risk work. The same applies to exclusions:

A useful test: could someone who was not in the room read the justification and reach the same decision? If not, add the missing reference.

Most organisations keep the Statement of Applicability as a controlled spreadsheet, exported to PDF for each approved version. A workable set of columns is:

Keep the version history. The Statement of Applicability is a controlled document, and auditors will expect to see it approved, dated and reviewed when the risk picture changes.

The document goes out of date the moment the organisation changes. Review it whenever one of these happens:

Treat it as a working record of decisions rather than a deliverable that was finished once. Organisations that do this find the certification audit easier, because the answer to most questions is already written down.

If you are beginning from nothing, resist the urge to open the control list first. Confirm the scope in writing, run a first risk assessment with a method you can repeat, and draft treatment decisions for the risks above your threshold. Then build the Statement of Applicability from those decisions.

The ISO 27001 Transformation System follows exactly this sequence: context and scope, risk assessment, risk treatment, then four documents dedicated to the Statement of Applicability — what it has to do, deciding applicability control by control, writing justifications that survive challenge, and maintaining it. It is independent guidance; it does not certify anything, and certification decisions are made by accredited certification bodies.