The Statement of Applicability, and why an auditor opens it first

It is the document ISO/IEC 27001 requires at clause 6.1.3 d), and it is the bridge between two things that otherwise never meet: the risks you identified, and the controls you operate. For each control it records that the control is necessary, why, whether it is actually implemented — and for each Annex A control you have left out, why that was reasonable.

It is usually short. A few pages, or a spreadsheet with 93 rows and a column of reasoning. That brevity is deceptive: it is the densest document in the pack, because every row is a decision with your name on it.

It also has a life outside the audit. The SoA is the one artefact that says, in one place, what your organisation actually does about security — which is why enterprise customers ask for it during procurement, and why it is worth writing for a reader who is not your auditor.

Here is the sequence the standard describes. You assess risk. You decide how to treat each risk, and in doing so you determine the controls necessary to carry out that treatment — from any source you like, including controls of your own design. Only then do you compare that set against Annex A, to verify that nothing necessary was omitted. The SoA is the record of that work.

Notice the direction. Annex A is a cross-check applied at the end, not a catalogue you shop from at the beginning. Its 93 controls exist so that an organisation reasoning from its own risks has something to check itself against before it discovers the gap the expensive way. The standard does not require you to implement all 93, and it does not require your controls to come from Annex A at all.

What most organisations do instead is open the list of 93 and work down it, deciding applicability control by control. The result usually passes, because the controls end up broadly right. But it inverts the logic, and the inversion shows: the justifications reference the control rather than the risk, exclusions are argued from inconvenience rather than scope, and there is no visible line back to any risk assessment. An experienced auditor reads three rows and knows.

If you have already built one this way, you do not need to start again. Take your existing rows and, for each, write down which risk it treats. The ones where you cannot name a risk are the ones to look at — either the risk exists and you never recorded it, or the control is there because the spreadsheet had a row for it.

A justification has one job: let a stranger reconstruct your reasoning without asking you. That is the whole test, and it is why one-word entries fail — not because they are short, but because they transfer nothing.

For an inclusion, name the driver. A risk from your own assessment, a contractual obligation, a statutory requirement, or a decision your organisation made deliberately. “Treats R-014, unauthorised access to customer data in the production database” is a justification. “Applicable” is a placeholder someone intended to come back to.

For an exclusion, the argument almost always rests on scope. If you write no software, the secure coding control has nothing to attach to; if you run no physical premises inside the certified scope, the physical entry controls have nothing to guard. State the fact that makes it inapplicable, not the conclusion. And be careful that the fact stays true — exclusions are where SoAs go stale first, because the company starts doing the thing a year later and nobody revisits the row.

Write every one of them as if a stranger will ask you to defend it, because at Stage 2 that is exactly what happens, and the auditor chooses which rows to test.

The 2013 edition had 114 controls in 14 clauses. The 2022 edition has 93, reorganised into four themes: 37 organisational, 8 people, 14 physical and 34 technological. The reduction is not a relaxation — 24 controls were merged rather than dropped, and 11 are genuinely new.

The new ones are worth knowing by name, because they are where most organisations found real gaps rather than paperwork: threat intelligence (A.5.7), information security for use of cloud services (A.5.23), ICT readiness for business continuity (A.5.30), physical security monitoring (A.7.4), configuration management (A.8.9), information deletion (A.8.10), data masking (A.8.11), data leakage prevention (A.8.12), monitoring activities (A.8.16), web filtering (A.8.23) and secure coding (A.8.28).

The practical consequence is that a 2013 SoA cannot be renumbered into a 2022 one. Merged controls mean several old rows collapse into one, and the merged control is often broader than either original — so an implementation status inherited from the old row can be wrong in the new one. The eleven new controls have no predecessor to inherit from at all.

That is the work, and it is not clerical. Treat a transition SoA as a fresh determination that happens to reuse evidence, rather than a mapping exercise with a lookup table.

Because it is the fastest read in the pack and it tells them where to spend the rest of the day. An SoA is a map of what you claim, and Stage 2 is the process of sampling that map against reality.

Two patterns draw attention immediately. An SoA with no exclusions at all, where every one of the 93 is marked applicable, almost always means the determination was skipped — no real organisation needs all of them, and claiming otherwise creates 93 things you must now evidence. And an SoA where every control is marked fully implemented, with no partials and no dates, is a claim that an auditor can disprove with three samples.

The counter-intuitive move is that honest partial status is safer than uniform green. A control marked partially implemented, with a line in the risk treatment plan and a date, is a functioning management system doing what a management system is for. A control marked implemented that turns out not to be is a nonconformity plus a question about everything else you asserted.

Certificates say almost nothing. They name a scope in a sentence and a standard, and the questions a customer actually has — do you encrypt this, who can reach production, what happens when someone leaves — are not answered anywhere on them.

The SoA answers them, which is why security questionnaires increasingly ask for it directly, and why sending a well-written one can replace a long questionnaire round. If yours reads like a decision record rather than a compliance artefact, it does commercial work as well as audit work.

Most organisations share a redacted version: control, applicability, justification, status — without the internal risk identifiers, system names or gap dates. That is worth preparing once, deliberately, rather than assembling under deadline when a prospect asks.