The Statement of Applicability (SoA) in ISO 27001

The Statement of Applicability, usually shortened to SoA, is one of the most important documents in ISO 27001. It connects a company's risks to the controls in Annex A, and for each control it records whether it applies, whether it is implemented, and why. Auditors routinely look at it among the first things they read, because it shows quickly whether the management system reflects reality or only exists on paper. This post explains what the SoA contains and how to produce one correctly.

This is part of our security program overview. We lead the SoA and the supporting documentation through governance, risk, and compliance.

What the SoA is

The SoA is the bridge between risk and controls. The risk assessment says what the company is exposed to. Annex A offers a catalog of possible controls. The SoA joins the two: for every control in Annex A it records whether the control is applicable, whether it is already implemented, and the justification for that decision. In doing so it demonstrates that the choice of controls is not arbitrary but grounded in risk. That single property is what makes the document credible, both to an auditor and to your own management.

ISO 27001 requires the SoA explicitly, which is part of why it carries so much weight. You cannot certify an information security management system without one, and the document has to be kept current rather than written once and filed away. The standard treats it as a living statement of how risk decisions translate into controls, not as a one-time formality.

What the SoA contains

For each control in Annex A, the SoA typically records the following.¹

The level of detail behind each entry matters more than the format. A control marked as implemented should point to how it is implemented in practice, and an excluded control should carry a justification that an auditor can follow. The descriptions of the controls themselves come from ISO/IEC 27002, which expands each Annex A control into guidance on what good implementation looks like.² The SoA references those controls; it does not need to repeat them.

Why auditors look at it first

The SoA gives an auditor a fast picture of the whole system: which controls were selected, why, and whether they are implemented. From it they can tell immediately whether the selection is grounded in risk or whether someone simply copied a list. Inconsistencies, for example a control marked as implemented that does not actually exist, surface quickly and undermine confidence in the entire management system. A clean, well-justified SoA does the opposite: it sets the tone for the rest of the audit and signals that the system is run deliberately.

How to produce a good SoA

A good SoA is accurate, justified, and aligned with reality.

1. 01
   Start from the risk assessment

   The choice of controls must follow from risk, not the other way around.
2. 02
   Address every control

   For each Annex A control, state its applicability and status.
3. 03
   Justify the decisions

   Be especially clear about the controls you exclude.
4. 04
   Align with reality

   The status must match what is actually implemented.
5. 05
   Maintain the document

   Update the SoA whenever risks or controls change.

The order of those steps is deliberate. Teams that start from the control list and work backward end up with a document that looks complete but has no link to actual risk, which is exactly what an auditor is trained to spot. Starting from the risk assessment keeps the SoA defensible: every applicable control traces back to a risk, and every exclusion has a reason that survives scrutiny. The wider context for this is risk management, which is the process the SoA ultimately documents.

Exclusion is allowed, and this is often misunderstood. Annex A is a catalog, not a checklist of mandatory items, so a control can be marked as not applicable. What the standard expects is a sound justification for the exclusion. A control for software development, for instance, may genuinely not apply to a company that develops nothing in-house. The exclusion is fine; the missing justification is what fails an audit.

How Raptoric helps

We help you produce an SoA that is accurate, justified, and aligned with reality, linked to the risk assessment, through governance, risk, and compliance. Book a scoping call.