The ISO 27001 Statement of Applicability, explained for engineers

ComplianceDocs — Wed, 24 Jun 2026 17:23:23 +0000

If your startup is going for ISO 27001, the document the auditor opens first is the Statement of Applicability (SoA). Most engineering teams build it backwards and pay for it at the audit. Here's the mental model that actually holds up.

What the SoA actually is

The SoA is one document that lists every control in Annex A of ISO/IEC 27001:2022 and states, for each: does it apply to you, why, and what's its status. It's not optional — clause 6.1.3 d) names it by name as documented information you must produce. It's one of the very few documents the standard requires explicitly.

If your ISMS were a map, the SoA is the legend. It ties your assessed risks to the specific controls you've decided to operate.

Annex A:2022 has 93 controls in four themes: Organizational (A.5, 37 controls), People (A.6, 8), Physical (A.7, 14), and Technological (A.8, 34). The SoA walks all 93 — including the ones you exclude. The completeness is the point: an auditor should see you considered the whole set and made a deliberate call on each, not cherry-picked.

Build it in the right direction

The SoA is an output, not an input. The chain is:

Assess your risks (clause 6.1.2)
Decide how to treat each one — modify, avoid, share, retain (clause 6.1.3)
Determine the controls those treatment decisions require
Then check that set against Annex A as a completeness check

A control is "applicable" because a risk you identified or an obligation you carry needs it — not because it's in the standard. A control is "excluded" when nothing you found depends on it and you can say why. Classic defensible exclusion: if you do no software development, you can reasonably exclude the secure-development controls (~A.8.25-A.8.30) — as long as that's genuinely and durably true.

Do it backwards — pick controls off Annex A first, then reverse-engineer risks to fit — and an experienced auditor will usually notice.

The columns that matter

Treat the SoA like a schema. For each control, resolve: control ID + title, theme, applicable (Y/N), justification, implementation status, evidence reference.

Justification must be specific: "required to mitigate the access-control risks in our risk register" — not a restatement of the control title.
Status stays honest. "Planned," backed by a dated plan, is acceptable at a Stage 1 audit (which mostly checks documentation and readiness).
Evidence links each applicable control to proof — a log, an access review, a ticket, a signed acknowledgment. That's what turns the SoA from a list of intentions into a navigable index into your ISMS.

Mistakes that cost you at audit

Excluding controls to cut work instead of because they genuinely don't apply. Every exclusion needs to survive a follow-up question.
Leaving template placeholder justifications ("applies to company systems"). That tells the auditor you filled a spreadsheet but didn't connect it to your environment.
An SoA that disagrees with the rest of the ISMS — a control marked applicable with no policy behind it. Internal consistency is exactly what auditors sample.
Treating it as one-and-done. It's living documented information — update it after each risk cycle and any significant change.
Using the old 2013 structure (114 controls / 14 domains, A.5-A.18). Certification is against ISO/IEC 27001:2022, so your SoA must reflect the 93-control, four-theme Annex A.

The SoA is the index; the audit is the auditor checking the index points to something real.

A head start

Transcribing all 93 controls and laying out the columns before you can do any of the actual thinking adds nothing unique to your org — so it's worth not doing by hand. We publish a 93-control SoA workbook (pre-populated with every Annex A:2022 control, its theme, and starter justification wording) alongside the matching risk register and the policies the evidence column points back to, in the ISO 27001 Complete Toolkit.

Be clear about the boundary: a workbook gives you the structure, not the judgment — the applicability calls, the org-specific justifications, and the evidence have to be yours. And no template makes anyone "ISO 27001 certified"; certification comes only from an accredited body auditing a working management system.