The Statement of Applicability (SoA) in ISO 27001

The Statement of Applicability, usually shortened to SoA, is the central document of an ISO 27001 management system. It takes every control in Annex A of the standard and records three things for each one: whether the control applies to your company, whether it is implemented, and the justification for that decision.¹ In effect it is a single map that connects what your company is exposed to, the controls you chose to manage that exposure, and the current state of each control. Nothing else in the management system ties those threads together so directly.

For a regulated company the SoA matters because it is the document everyone else points back to. An auditor reads it to understand the shape of your management system. Your own management reads it to see whether security investment tracks real risk. A customer running vendor risk management on you may ask to see it. ISO 27001 makes the SoA mandatory, so you cannot certify an information security management system without one.¹ It is also one of the few documents the standard requires by name, which is a strong signal of how much weight it carries.

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

What the SoA is and why it is central

The SoA is the bridge between risk and controls. The risk assessment says what your 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 your choice of controls is not arbitrary. It is grounded in risk. That single property is what makes the document credible, to an auditor and to your own board.

ISO 27001 requires the SoA explicitly under clause 6.1.3, which is part of why it carries so much weight.¹ It is the output of the risk treatment process, and it is the one place where the abstract requirements of the standard turn into a concrete, control-by-control record of decisions. Without it, an auditor has no efficient way to see which controls you selected or why. With it, they can read the logic of your entire program in a single pass.

The standard treats the SoA as a living statement of how risk decisions translate into controls, not a one-time formality. The 2022 revision of Annex A reorganised the controls into four themes, organisational, people, physical, and technological, and reduced the count to 93 controls.¹ Your SoA reflects that current structure, and it changes as your risks, technology, and business change.

What the SoA must contain

The standard expects the SoA to address the complete set of Annex A controls. For each control, the document records four things.¹

The justification column is where most of the value sits. A control marked applicable should trace to a specific risk from the risk assessment or to a legal, regulatory, or contractual obligation. A control marked not applicable should carry a reason an auditor can follow without further explanation. The status column should be honest about partial work rather than rounding everything up to implemented.

The SoA references the controls; it does not need to repeat them. The detailed guidance on what each control means and what good implementation looks like comes from ISO/IEC 27002:2022, the companion standard that expands every Annex A control into practical advice.² The SoA points to that guidance and to your own evidence, such as policies, configurations, or records, rather than restating the control text.

How the SoA is built from the risk assessment

The order of work matters more than almost anything else about the SoA. The controls must follow from risk, not the other way around. Teams that start from the Annex A list and work backward produce a document that looks complete but has no link to actual exposure, which is exactly what an auditor is trained to spot. The defensible path runs in one direction: risk first, then treatment, then the SoA as the record of the result.

1. 01
   Run the risk assessment

   Identify and analyse the risks to your information, following your risk assessment method. Each risk gets an owner and a level.
2. 02
   Decide the risk treatment

   For each significant risk, decide how to treat it: reduce it with controls, accept it, avoid the activity, or transfer it. This is your risk treatment plan.
3. 03
   Select controls to treat the risks

   Where you chose to reduce risk, select the Annex A controls that do the job. You may also add controls from outside Annex A if a risk needs them.
4. 04
   Compare against the full Annex A list

   Walk through all 93 Annex A controls. Confirm that each control you need is selected and that nothing relevant was missed. This comparison is a requirement of the standard.¹
5. 05
   Record applicability, justification, and status

   For every control, write whether it applies, the justification, and its implementation status. This record is the SoA itself.
6. 06
   Reconcile with the treatment plan

   Check that every applicable control maps back to a risk in the treatment plan and that no risk is left without a control. The two documents must agree.

Building the SoA this way keeps it defensible. Every applicable control traces back to a risk, and every exclusion has a reason that survives scrutiny. The wider discipline behind this is risk management, the ongoing process the SoA ultimately documents. In our experience a first SoA for a mid-sized company takes a few weeks of focused work once the risk assessment exists, though the real estimate depends on the scope of the management system and how much is already documented.

Why exclusions are allowed but must be justified

Annex A is a catalog, not a checklist of mandatory items, so a control can be marked not applicable. This is often misunderstood. Excluding a control is entirely legitimate when the control does not fit your context. A control for secure software development may genuinely not apply to a company that develops nothing in-house. A control for physical entry to facilities may not apply to a fully remote company that holds no premises of its own.

What the standard expects is a sound justification for each exclusion.¹ The exclusion itself is fine; the missing or weak justification is what fails an audit. A justification of "not relevant" is too thin. A justification of "the company outsources all software development to a managed provider and verifies their secure development practices through vendor risk management" is defensible because it explains both the exclusion and how the underlying risk is still handled. The point is to show you considered the control and made a reasoned decision.

Why the SoA is the auditor's first stop

The SoA gives an auditor a fast, complete picture of the 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 copied a generic list. It is the natural starting point for a certification audit because it sets the scope of everything that follows. The auditor uses the SoA to plan which controls to sample and which evidence to request.

Inconsistencies surface quickly through the SoA. A control marked implemented that does not actually exist undermines confidence in the entire management system, because the auditor now has to question every other entry. A clean, well-justified SoA does the opposite. It signals that the system is run deliberately and sets a constructive tone for the rest of the audit. The same logic applies under SOC 2 and other frameworks, where assessors look first for the document that ties controls to a stated rationale.

An auditor does not read your controls first. They read the document that explains why you chose them.

Common mistakes that fail an SoA

Most failed SoAs fail for a small number of recurring reasons. The patterns below come up repeatedly in real assessments and the ISO 27001 certification process.

• Marking a control as implemented when it does not exist in practice, to make the document look complete. The auditor checks, and the gap between the SoA and reality is one of the fastest ways to fail.
• Excluding controls without justification, or with a justification too thin to survive a single follow-up question.
• Copying another company's SoA, which leaves controls marked applicable that do not fit your context and exclusions that do not match your risks.
• Building the SoA from the control list instead of from the risk assessment, so the controls have no traceable link to actual exposure.
• Letting the SoA drift out of date, so it describes a system that no longer matches how the company operates.
• Treating the SoA as a static deliverable produced once for the audit rather than a record that is maintained continuously.

Maintaining the SoA as a living document

The SoA is not a one-time deliverable. ISO 27001 expects it to stay current, because the risks it documents change as the company changes.¹ A new product, a move to a new cloud provider, an acquisition, or a new regulation such as the NIS2 Directive or DORA can all change which controls apply and how. When that happens, the SoA has to be updated to match, along with the risk assessment behind it.

In practice this means reviewing the SoA on a defined cycle, typically alongside the management review and the periodic risk assessment, and updating it whenever a significant change occurs. The implementation status should reflect the current state, so a control that moves from planned to fully implemented is updated when that happens, not at the next audit. A maintained SoA is the difference between a management system that genuinely runs the company and one that is reconstructed in a panic before each surveillance audit.

How Raptoric helps

We help you produce an SoA that is accurate, justified, and aligned with reality, built from the risk assessment and reconciled with the treatment plan, through governance, risk, and compliance. We also keep it current as your risks and obligations change, so it holds up at every surveillance audit rather than only the first one. Book a scoping call.