Statement of Applicability (SoA): what it is and how to write one for ISO 27001

The Statement of Applicability, or SoA, is a list of every control in Annex A of ISO 27001, with your decision on each one: whether it applies to you, why, and whether it's in place. It's the document an auditor uses to navigate your ISMS, and usually the first one they ask for.

Annex A in the 2022 version has 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34).

Why it matters

The SoA is required by clause 6.1.3 d) of ISO/IEC 27001:2022. In summary, it must contain:

• The controls you need to treat your risks, whether from Annex A or elsewhere.
• Why each is included.
• Whether each is implemented.
• Why any Annex A control is excluded.

It ties three things together: your risks (why a control is needed), your policies and procedures (how it's done) and your evidence (proof that it works). It's also referenced on your certificate, so its version matters.

What an auditor looks for

• All 93 controls are addressed. None is missing or left blank.
• Justifications are specific. "Applicable: required to treat risk R-07 (admin account takeover)" is good. "Applicable: best practice" for every line is not.
• Exclusions are reasoned. Excluding 7.4 physical security monitoring because you have no premises of your own is fine if it's true and explained. Excluding a control because it's inconvenient is not.
• Status matches reality. If a control is marked implemented, the auditor will ask to see it working.
• It's approved and versioned. Top management signed off the current version, and changes are tracked.

Common reasons it fails: copied justifications; controls marked implemented with no evidence; exclusions contradicted by the scope (for example, excluding secure development when you build software); or an SoA that doesn't match the risk treatment plan.

An example entry

Illustrative, for a fictional software company:

Common mistakes, and how to keep it manageable

• Writing essays. Each line needs a reason, a status and a pointer to how it's done. The detail belongs in the policy or procedure, not the SoA.
• Copying policy text into the SoA. Link to the policy and point to the passage instead. When the policy changes, the link stays right; a copy goes stale.
• Applying everything by default. It looks thorough, but every applicable control needs evidence. Apply what your risks and obligations need.
• Forgetting the clauses aren't controls. The SoA covers Annex A. Clauses 4 to 10 are requirements you must meet regardless.
• Never re-approving it. When the scope, risks or controls change, update the SoA and get it approved again.

How to do it in ClearIMS

1. Start from the draft. The onboarding chat drafts a first SoA from what you tell it about your business, alongside your risks. It's a draft until approved.
2. Open Statement of Applicability and work through each control: applicable or not, the reason, and the status. The AI can review an entry and suggest improvements; you decide what stays.
3. Link the evidence. Link a policy or document to a control and highlight the lines that satisfy it. When an auditor asks "show me", one click takes you to the highlighted passage.
4. Get it approved. Approving the SoA needs a member marked as top management. The AI never approves anything.
5. Coming from Cyber Essentials? If you used the Cyber Essentials plan, the evidence and owners you set up carry across to the matching ISO 27001 controls.

Related pages

• Risk register and Treatment plans: why each control is needed.
• Controls and policies: how each control is carried out.
• Evidence library: the proof behind each control.
• Policy coverage: which controls your policies cover.