Statement of applicability: the one ISO 27001 document auditors read first

A statement of applicability is the mandatory ISO 27001 document that lists every control in Annex A and records, for each one, whether it applies to your organisation, the justification for that decision, and whether it is currently implemented. It is the bridge between the risk assessment and the management system — and it is where an auditor starts, because it tells them what you have claimed.

Nothing else in the standard exposes an unfinished management system so quickly. A statement of applicability with every control marked applicable and implemented, produced by an organisation of eleven people, tells the auditor that the document was filled in rather than derived.

What each row of the statement of applicability contains

• The control reference and title, from the version of Annex A you are certifying against.
• Applicable or not applicable — a decision, not a blank.
• The justification: which risk, legal requirement or contractual obligation makes it necessary, or why it genuinely does not apply.
• Implementation status, and where the evidence of that implementation lives.
• The owner of the control.

Exclusions are legitimate and expected — an organisation with no development function can exclude secure development controls — but the justification has to be a fact about the organisation, not a preference. "We do not develop software" is an exclusion. "Not a priority this year" is a gap being described as an exclusion, and auditors read the difference immediately.

How it connects to everything else

1. The risk assessment identifies risks and their treatment.
2. Treatment decisions select controls — from Annex A and from anywhere else that helps.
3. The statement of applicability records those selections against the full Annex A list, so nothing was skipped silently.
4. The risk treatment plan says who will implement what, by when.
5. Evidence accumulates as the controls operate.
6. The internal audit and the certification audit sample that evidence, using the SoA as the index.

Read in that order, the SoA is a summary of decisions already made. Written in the opposite order — filling in the SoA first and reverse-engineering risks to match — it becomes the document that has to be defended, and defending it is much harder than deriving it.

Version the statement of applicability and date every change. Controls move in and out of scope as the business changes, and a surveillance auditor comparing this year’s SoA to last year’s will ask about every difference. Being able to say when a control became applicable, and why, turns that conversation into a two-minute one.

Keeping it honest as the business changes

The most common failure is not a wrong row; it is a stale one. A company that starts developing its own software, or takes on a first public-sector customer, or opens an office in another jurisdiction, changes what is applicable. Nobody notices, because the SoA is reviewed annually and the change happened in month two.

Tie the review to events rather than to the calendar: new product line, new type of customer data, new supplier holding your data, new jurisdiction, significant reorganisation. Each is a reason to reopen the list.

Because the SoA is a controlled document whose history matters as much as its contents, it belongs somewhere versioned rather than in a shared folder of near-identical files. Ettex Records keeps the statement with its revision history and links each row to the evidence behind it, so the auditor’s question — when did this become applicable, and what proves it operates — is answered from the record. The underlying internal controls still have to be designed and run by the organisation.