The Statement of Applicability (SoA) explained for ISO 27001

The Statement of Applicability (SoA) is one of the most important documents in ISO/IEC 27001:2022 — and often the first thing a certification auditor asks to see. This guide explains what it is, what it must contain, and how to produce one that tells a consistent story.

What the SoA is

The SoA is a single document that lists every one of the 93 Annex A controls and, for each, records:

• Whether the control is applicable to your organisation.
• The justification for including or excluding it.
• The control’s implementation status (for example, in place, partially in place, or planned).
• Often, a reference to where the control is documented or evidenced.

In short, it is the bridge between your risk assessment and the controls you actually run. It shows an auditor, at a glance, what you’ve decided and why.

Why the SoA matters so much

The SoA is a mandatory document under ISO/IEC 27001, and it carries a lot of weight for three reasons:

1. It summarises your whole control set. Auditors use it as a map for the rest of the audit, sampling controls from it to test in practice.
2. It forces justified decisions. You can’t quietly ignore a control; you must state a reason to include or exclude it.
3. It links risk to action. A good SoA traces cleanly back to the risks identified in your assessment and forward to your risk treatment plan.

If the SoA, the risk assessment and the treatment plan disagree, that inconsistency is exactly what an auditor will probe.

What a good SoA contains

A typical SoA is a table with one row per control. A simplified example:

Control ref	Control name	Applicable?	Justification	Status
A.5.7	Threat intelligence	Yes	Relevant to our threat landscape; informs monitoring	In place
A.5.23	Information security for cloud services	Yes	Core systems are cloud-hosted	In place
A.7.4	Physical security monitoring	No	No owned premises; staff work remotely	Excluded
A.8.11	Data masking	Yes	Personal data used in test environments	Planned

The key is that each row makes sense on its own, and every exclusion has a defensible reason.

Applicable vs excluded controls

It is entirely legitimate to exclude controls that don’t fit your organisation — for instance, some physical controls if you have no premises of your own. What matters is the reasoning. Good exclusions are tied to your context and scope; weak exclusions look like you’re avoiding effort.

Conversely, a control might be applicable but not yet implemented. That’s fine at the readiness stage, provided your treatment plan shows when and how it will be put in place.

How the SoA connects to everything else

The SoA doesn’t exist in isolation. It sits at the centre of a chain:

• Risk assessment identifies the risks.
• Risk treatment plan decides how to treat them, selecting controls.
• Annex A provides the control catalogue (the 93 controls across four themes).
• SoA records, control by control, what applies and why.
• Evidence demonstrates each applicable control is operating.

Keeping this chain consistent is the single biggest factor in a smooth Stage 1 and Stage 2 audit.

Keeping the SoA current

Like the risk assessment, the SoA is a living document. Update it when:

• You add or retire systems, suppliers or services.
• A new risk changes which controls you need.
• A planned control moves into full operation.
• You transition between versions of the standard.

Auditors will check the SoA has been reviewed and reflects reality, not a snapshot from the day you first drafted it.

Common SoA mistakes

• Copy-paste justifications that don’t reflect the organisation.
• Excluding controls without a clear reason, which invites scrutiny.
• Marking controls “in place” that aren’t, which an auditor will test and find.
• Letting the SoA drift out of step with the risk assessment.
• Over-complicating it with so much detail it becomes hard to maintain.

A clear, honest, well-cross-referenced SoA is far more convincing than a long one.

If any of the terminology is new, our glossary explains the key terms, and our overview of what an ISMS is shows where the SoA fits in the bigger picture.

How we can help

Producing an SoA that lines up cleanly with your risk assessment and evidence is a skill, and it’s where an experienced eye pays off. We provide practical support throughout — helping you justify each control decision and keep the document consistent and audit-ready — as part of a transparent, fixed-fee engagement with a clear delivery process. Our free ISO 27001 gap assessment tool is a good starting point for seeing which controls need attention.

Learn more about our ISO 27001 service or contact us to talk it through.