Writing a statement of applicability

The Statement of Applicability is the document an auditor reads first and the one most often written last. It is the bridge between your risk assessment and the controls you actually operate, and a weak one makes everything else harder to defend.

Its job is simple to state: for every control in Annex A, say whether it applies, why, and whether it is implemented. Doing that well is mostly about the quality of the reasoning, not the length of the text.

What it has to contain

For each control:

• Whether it is applicable. Included or excluded.
• The justification. Why, in a sentence that references something real.
• The implementation status. Implemented, partially implemented, or planned with a date.
• A reference to how. Which policy, procedure, system or record demonstrates it.

The fourth item is what turns the document from an assertion into something an auditor can follow. A Statement of Applicability that says "implemented" with no pointer to evidence generates a request for evidence on every line.

Justifications that hold up

The justification is where these documents are strong or weak. Compare:

> Included. Required by ISO 27001.

This says nothing. Every control is in the standard; that is not a reason.

> Included. Risk R-14 identified unauthorised access to the customer database as a significant risk; access control is the primary treatment.

This traces to your own risk assessment. An auditor can follow it, check the risk exists, and check the treatment matches.

The same applies to exclusions:

> Excluded. Not applicable.

This will be challenged.

> Excluded. The organisation operates no development activity; all software is commercially licensed and not modified. Confirmed with the Head of Technology, March 2026.

This is specific, checkable, and dated.

Exclusions worth thinking carefully about

Some controls are legitimately excluded by many organisations. Others are excluded too readily and cause problems.

Usually safe to exclude, with justification:

• Secure development controls, where no software is developed or modified in-house. Be careful: automation scripts, low-code applications and infrastructure code can count, and auditors increasingly ask.
• Controls relating to specific facilities you do not have, such as loading bays or delivery areas, where the site genuinely lacks them.
• Controls for activities you genuinely do not perform, provided you can show the activity does not occur.

Often excluded and frequently challenged:

• Teleworking or remote working controls, excluded on the basis that everyone is in the office. Verify this is still true.
• Removable media controls, excluded because they are technically blocked. If they are blocked, the control is implemented, not excluded. This distinction matters and is easy to get wrong.
• Supplier security controls, excluded because suppliers are considered low risk. If you use any external service, this needs a real answer.

The rule of thumb: exclusion means the control is not relevant to your scope. If you have addressed the risk by preventing the activity, that is implementation, not exclusion.

Common mistakes

Writing it before the risk assessment. The Statement of Applicability derives from the risk treatment. Written first, it becomes a checklist you then reverse-engineer risks to justify, and the seams show.

Marking everything as implemented. A document with no partial implementations and no planned dates looks like an aspiration rather than an assessment. Auditors expect a real organisation to have work in progress, and honesty here builds credibility for everything else.

Copying a template without editing. Justifications that reference departments you do not have or systems you do not run are common and immediately visible.

Letting it go stale. The Statement of Applicability should change when your scope, your risks or your controls change. One that has not been updated since certification, sitting alongside a business that has changed considerably, is a finding waiting to happen.

Making it enormous. Two or three sentences per control is plenty. The value is in precision, not volume.

Keeping it current

Treat it as a live register rather than a project deliverable. Three habits are enough:

• Review it whenever the risk assessment changes. New risk, new treatment, updated line.
• Review it whenever scope changes. A new location, service or system can make excluded controls applicable.
• Review it as part of the annual internal audit, checking a sample of lines against actual evidence rather than reading it.

Version it and keep the history. Being able to show how the document has evolved is itself evidence that the management system is operating.

How the auditor will use it

Expect the auditor to sample. They will pick a handful of controls marked as implemented and ask to see the evidence referenced. They will pick a handful of exclusions and test whether the justification is true.

This is why the reference column matters so much. If each line points to a specific policy section, system report or record, the sampling goes quickly and the auditor forms a good impression of the whole. If each line requires a search, the audit slows and the sample tends to widen.

The practical test

Before you submit it, hand it to someone in your organisation who was not involved in writing it, along with three controls picked at random. Ask them to find the evidence.

If they can, the document works. If they cannot, the references are not specific enough, and an auditor will reach the same conclusion in less charitable circumstances.