The Statement of Applicability is the document the auditor reads first

There is a way to write a Statement of Applicability that takes an afternoon: list the 93 Annex A controls, mark almost all of them "applicable", write "implemented" next to each, and attach it to the management system. Certification bodies see this version constantly and know exactly what it means, which is that the risk assessment was not used.

The SoA is the hinge of the whole management system. It is the document that connects the risks you identified to the controls you chose, and it is the first thing an auditor reads because it tells them where to look for everything else.

What it has to contain

Clause 6.1.3 d) requires four things per control, and the fourth is the one that gets skipped:

1. Whether the control is applicable.
2. Justification for including it.
3. Whether it is implemented.
4. Justification for excluding any control you excluded.

An SoA where nothing is excluded is a warning sign rather than a virtue. It usually means nobody assessed anything; they just accepted the whole catalogue. A twenty-person SaaS company with no development of its own operating system, no physical data centre and no industrial control systems legitimately excludes several controls, and saying so with a reason is stronger than claiming everything applies.

It has to follow from the risk assessment, not precede it

The correct sequence is: identify risks, evaluate them against your criteria, decide treatment, and select controls to implement that treatment. The SoA then records which Annex A controls the treatment used, and Annex A serves its intended purpose — as a checklist to verify you did not forget a category of control, not as the source of the controls themselves.

Written the other way round, the risk register becomes a document reverse-engineered to justify a control list, and an auditor spots it in one question: "show me the risk that this control treats". If the answer is "it's in Annex A", the management system is decorative and the audit gets longer.

Note also that the standard does not restrict you to Annex A. If your risk treatment needs a control that Annex A does not contain — and for a cloud-native company it frequently does, around tenancy isolation, key management or supply chain — include it. Annex A is a reference set, not a limit.

Make the implementation column point at evidence

The most useful change you can make to a standard SoA template is to add a column for where the evidence lives, and to make it a link rather than a description.

Instead of "8.13 Backup — implemented — backups are taken daily", write "8.13 — implemented — terraform/backup.tf, restore test record 2026-06-14, retention policy in docs/backup.md". The auditor follows the link. Without it, they ask, you search, and a fifteen-minute item becomes an hour.

This also has an effect internally: a control whose evidence link is a wiki page written once is visibly weaker than one whose evidence is a pipeline output or a Terraform file, and putting them side by side in one table makes that obvious to whoever is deciding where to spend the next quarter.

Partial implementation is allowed, and better than a lie

Controls that are in progress should say so, with a date and an owner. "Partially implemented — MFA enforced for administrators since 2026-03; rollout to all staff scheduled 2026-10, owner: Head of IT" is an acceptable entry. It shows a managed system.

Marking it "implemented" when it is not is the one thing that genuinely damages an audit, because once an auditor finds one entry that overstates, they re-test everything else. The cost of honesty is a minor nonconformity; the cost of being caught is the whole schedule.

Keep it alive

The SoA is a living document, and the surveillance audit in year two will compare it to the one from year one. If it is byte-identical, that is a finding in itself: nothing in your risk landscape changed in twelve months, in a company that shipped features, hired people and adopted new services?

Review it whenever the risk assessment changes, whenever a significant new service or supplier is introduced, and at the management review. Keep the version history — the trail of changes is itself evidence that the management system operates.

Scope discipline pays here more than anywhere

Every control in the SoA applies to whatever your scope statement says. A scope of "the production platform and the teams that build it" makes a manageable SoA. A scope of "the company" pulls in the sales laptops, the marketing SaaS estate and the office, each with their own controls and evidence.

Narrow scope is not cheating, as long as it is coherent and the boundary is defensible — your customers will read the scope on the certificate, so it has to cover the thing they are buying. But the difference between those two scope statements is months of work, and it is decided in the first week of the project, before anybody opens the SoA template. Get the scope right and the rest of Annex A becomes tractable.