The Statement of Applicability is where ISO 27001 audits are won or lost

Ask an ISO 27001 lead auditor where they start, and a surprising number will say the same thing: the Statement of Applicability. Not the policy pack, not the risk register — the SoA. It is a short document, often a spreadsheet, and it is the closest thing the standard has to a confession.

What the SoA actually claims

The SoA lists every Annex A control and, for each one, three things: whether it applies, why, and whether it is implemented. That is a set of assertions about your organisation, and every one of them is testable. When an auditor picks a sample, they are not picking at random from your controls — they are picking from the ones you told them you had.

This is why an SoA written at the end of a project, after the policies are already drafted, causes so much pain. It gets filled in optimistically. Someone marks a control as implemented because a policy mentions it, not because anyone does it. The document then quietly commits you to evidence you cannot produce.

The three failure patterns

• Inclusion without evidence. A control is marked applicable and implemented, but the only artefact is the policy that says it should be. Auditors treat a policy as intent, not as operation.
• Exclusion without justification. Controls are excluded because they seemed irrelevant, with a one-line reason that does not connect to the risk assessment. Every exclusion has to trace back to a risk decision.
• Drift. The SoA is accurate on the day it is signed and never touched again. Twelve months later the organisation has changed, the SoA has not, and the surveillance audit finds the gap.

Writing it in the right order

The sequence that survives audit is unglamorous. Establish scope and context first, so you know what you are protecting. Run the risk assessment and produce a risk treatment plan. Only then open Annex A and ask, control by control, whether it treats a risk you have actually identified. The SoA becomes a summary of decisions you already made, rather than a decision-making exercise in its own right.

Written this way, the justification column writes itself. Applicable because it treats risk R-014. Excluded because the organisation operates no development function, per scope statement section 2.3. Auditors are looking for that traceability far more than they are looking for perfection.

The maintenance habit that costs an hour a quarter

Put the SoA on the agenda of your management review. Four times a year, walk the exclusions and ask whether any of them have become applicable — a new product line, a new office, a first developer hire. Record the answer even when nothing changed. That record is what turns a surveillance audit from an interrogation into a conversation.

If you are building an ISMS from scratch, do not start with templates. Start with scope, then risk, then Annex A. The templates are worth far more once you know which controls you are defending.