The Statement of Applicability, or SoA, is perhaps the most important document of an ISO 27001 implementation. It is the hinge between your risk assessment and the controls you actually implement. Yet many organizations struggle with it. In this article we explain what the SoA exactly is, what belongs in it and how to draft it without falling into the familiar pitfalls.
What is the Statement of Applicability
The SoA is a document in which you record, for each control from Annex A of ISO 27001, whether it applies to your organization, and if so, how it is implemented. In the 2022 version, Annex A has 93 controls divided across four themes: organizational, people, physical and technological. For each control you justify whether you apply it and, if you do not apply it, why not. The SoA thus connects the outcomes of your risk assessment with concrete controls.
Why the SoA is so important
For an auditor the SoA is the first document they reach for. It shows in one overview how the organization has set up its information security and the choices behind it. A good SoA demonstrates that the controls stem from a considered risk assessment and not from a checklist. A weak SoA, in which all controls are blindly marked 'applicable' without justification, is an immediate red flag.
The relationship with the risk assessment
The SoA does not stand alone. It follows logically from the risk assessment: you identify risks, determine how you treat them, and select controls from Annex A for that. The SoA records that selection. That is why the order matters: first the risk assessment, then the SoA. Anyone who fills in the SoA without an underlying risk analysis reverses the logic and pays for it at the audit.
How to justify a control
For each applied control you briefly describe how it is implemented and refer to the underlying policy or procedure. For access management, for example, you refer to your access policy and the process for granting and revoking rights. It is not about long texts, but about a clear, traceable reference. For controls you do not apply, you give a justified reason, for example that you do no in-house software development and certain development controls are therefore not relevant.
Exclusions: are they allowed, and how
Yes, you may exclude controls, provided you justify them. Unlike some other standards, exclusion in ISO 27001 is permitted as long as the reason is defensible and matches your scope and risks. The mistake we often see is that organizations, out of caution, mark everything 'applicable' and thereby claim controls they have not really implemented. That is more dangerous than a well-justified exclusion, because at the audit you must be able to demonstrate every 'applicable'.
Common mistakes
The first mistake is decoupling the SoA from the risk assessment. The second is marking everything 'applicable' without actually having the corresponding controls. The third is drafting the SoA and then forgetting it: the SoA is a living document that moves with changes in scope, systems and risks. The fourth is justifications that are too extensive or too terse; aim for a clear reference traceable to policy and evidence.
Maintaining the SoA with tooling
Because the SoA connects the risk assessment, the controls and the evidence, it lends itself excellently to management in a GRC platform. Change a risk or a control and you update the SoA in one place, keeping the coherence with the evidence intact. That prevents the situation in which the SoA in a separate document slowly drifts out of step with reality, a common finding at surveillance audits.
Secure Audit helps organizations draft and maintain a solid Statement of Applicability, linked to the risk assessment and the evidence in our GRC tool. Get in touch for support with your ISO 27001 project.
Frequently asked questions
What is a Statement of Applicability?+
The SoA is the document in which you record, for each control from Annex A of ISO 27001, whether it applies and how it is implemented. It connects the risk assessment with the controls actually implemented.
How many controls are in the SoA?+
In ISO 27001:2022, Annex A has 93 controls divided across four themes: organizational, people, physical and technological. For each control you justify whether you apply it.
May you exclude controls in the SoA?+
Yes, provided you justify it. A defensible exclusion that matches your scope and risks is permitted and often wiser than marking everything applicable, because every applied control must be demonstrable at the audit.
Does the SoA come before or after the risk assessment?+
After. The SoA follows logically from the risk assessment: you identify risks, determine treatment and select controls from Annex A. The SoA records that selection. Reversing the order leads to problems at the audit.
About the author
Partner | IT Auditor