Frameworks

What is a Statement of Applicability?

A Statement of Applicability (SoA) is the ISO 27001 document that lists the Annex A controls, states which ones apply to your organization, whether each is implemented, and the justification for including or excluding it.

Definition

A Statement of Applicability (SoA) is a required ISO/IEC 27001 document that lists every Annex A control, records whether it is applicable to your organization, whether it is implemented, and the justification for each inclusion or exclusion.

Background

ISO/IEC 27001:2022 Annex A contains 93 controls, grouped into four themes (organizational, people, physical, and technological). Not every control applies to every organization, so the standard requires you to produce a Statement of Applicability that ties your risk-treatment decisions to the specific controls you have chosen to apply. It is one of the first documents an ISO 27001 auditor asks to see because it shows how your controls trace back to your risks.

Why it matters

The SoA is the map between your risk assessment and your actual controls. A clear, justified SoA demonstrates that your control selection is deliberate and risk-based, not copied from a template, which is exactly what a certification auditor is checking.

Step by step

1. Complete your risk assessment and risk-treatment plan first, so control decisions have a basis.
2. List all Annex A controls as the reference set.
3. For each control, mark whether it is applicable, and if not, record why.
4. For applicable controls, record whether they are implemented and reference the supporting policy or evidence.
5. Keep the SoA current as risks, controls, and scope change.

Examples

• A cloud-only company marks physical-media controls as not applicable and documents that it operates no data centers of its own.
• A company adds a control it does not strictly need after a customer contract requires it, and records that commitment as the justification.

Common mistakes

• Marking controls applicable without any linked evidence that they are actually implemented.
• Excluding controls without a defensible justification tied to the risk assessment.
• Producing the SoA once and never updating it as the ISMS changes.

FAQ