Statement of Applicability (SoA): what it is and how to build it in ISO 27001

By the QuantumSec team

The Statement of Applicability — SoA — is, along with the security policy, the document most scrutinized by any ISO 27001 auditor. It's the written proof that your company has reviewed all 93 Annex A controls one by one and decided, with reasoning, which apply and which don't. An SoA copied from a generic template is the fastest signal that the rest of the ISMS isn't real either.

What the standard requires of the SoA

Clause 6.1.3.d) of ISO/IEC 27001:2022 requires producing a Statement of Applicability that contains: the controls deemed necessary based on the risk assessment, the justification for their inclusion, whether they are implemented, and the justification for excluding any Annex A control that does not apply. It is not optional or a decorative appendix: it is an auditable requirement.

The 93 Annex A controls (2022 edition) and their four categories

The 2022 revision reorganized the previous 114 controls into 93, grouped into four themes: organizational (37 controls: policies, roles, supplier relationships...), people (8: remote working, training, terms of employment...), physical (14: secure perimeter, equipment, cabling...) and technological (34: access control, cryptography, vulnerability management, secure development...). The SoA must walk through all 93, not just the ones that are convenient to apply.

How it is built: from the risk assessment to control-by-control justification

The correct process starts from the risk assessment, not from Annex A: first you identify which risks exist and what treatment you decide to give them (mitigate, transfer, avoid or accept); then, for each mitigated risk, you identify which Annex A controls address it. Only then do you fill in the SoA, marking that control as applicable with a justification that cites the specific risk it addresses — not a generic template sentence.

Excluding a control (with justification) is just as valid as including it

A common mistake is assuming "more controls marked" is better. It is not: a cryptography-in-transit control that does not apply because no data flow requires it should be excluded, with that exact justification. An experienced auditor immediately spots an SoA where everything is marked applicable with no exceptions: it signals that nobody did the real analysis exercise, only ticked boxes.

FAQ

Is the SoA reviewed once, or does it need updating?

It's reviewed whenever something relevant changes: a new asset, a newly identified risk, a change in ISMS scope, or at minimum during each annual system review. An SoA that's out of sync with the current risk assessment is a typical finding in surveillance audits.

Can we use an SoA template as a starting point?

As a structure, yes. As content, no: every justification must reflect your organization's real risk assessment. A template with generic, copied justifications is exactly what an experienced auditor spots and questions in the first review.

Who must sign off or approve the Statement of Applicability?

Top management, as part of their accountability for the ISMS (ISO 27001 clause 5.1). It's not a purely technical document: it involves a business decision about which risks are accepted and which are mitigated.