Statement of Applicability for ISO 27001
The Statement of Applicability is a mandatory document for ISO 27001 . It is abbreviated as SoA. In this document, you record for each control in Annex A whether you apply it and why. The SoA follows directly from your risk analysis, and it is one of the first documents that the auditor asks for.
The Statement of Applicability is unique to ISO 27001. Other management system standards do not have this document. The NEN version of the standard requires it explicitly in clause 6.1.3.
What is the Statement of Applicability?
The Statement of Applicability is an overview of all 93 controls in Annex A of ISO 27001:2022. For each control, you record three things: whether you apply it, why or why not, and how far you are with implementing it.
The document links your risks to concrete controls. Your risk analysis shows which risks you want to reduce. The SoA shows which controls you use to do that. This way, the auditor can see at a glance whether your choices are justified.
The SoA is not a standalone checklist. It is the bridge between your risk analysis and the controls you have actually put in place. Without an underlying risk analysis, an SoA is worthless.
Which parts are mandatory?
ISO 27001 sets out what the Statement of Applicability must contain. For each control in Annex A, you record the following:
| Part | What you record |
|---|---|
| Control | The number and title from Annex A (for example A.8.5) |
| Applicable | Yes or no |
| Justification | Why you do or do not apply the control |
| Implementation status | Implemented, in progress or planned |
| Reference | To the policy, procedure or evidence |
The most important part is the justification. For every control you do not apply, you must explain why not. “Not applicable” without a reason is a common cause of an audit finding.
Example of an SoA row
This is what a completed row in the Statement of Applicability looks like. Suppose your risk analysis has identified the risk of “unauthorised access to client data”.
| Control | Applicable | Justification | Status | Reference |
|---|---|---|---|---|
| A.8.5 Secure authentication | Yes | Risk R001: unauthorised access. MFA reduces the likelihood. | Implemented | Access policy v2.1 |
| A.7.4 Physical security monitoring | No | Fully cloud-based, no own server room | N/A | Scope document |
The second row shows how to justify an exclusion. A software company without its own data centre does not need physical security monitoring, but it should record that clearly.
How do you write the Statement of Applicability?
You write the SoA after you have completed the risk analysis. The steps below follow the logical order.
Start with your risk analysis
The SoA builds on your risk analysis, so start there. Read how to do it on the page about the ISO 27001 risk analysis.
List all 93 Annex A controls
Create an overview of all the controls in Annex A. You may use the numbers and titles freely. Buy the full text of the standard from NEN . A simple spreadsheet is sufficient.
Decide for each control whether it applies
Go through each control. Ask yourself: does this control help reduce one of my risks? If so, it applies. If not, explain why not.
Record the justification and status
For each control, enter the justification and state how far you are with implementing it. Refer to the policy or procedure in which the control is worked out.
Have the SoA approved
The board approves the SoA as part of risk treatment. In this way, management confirms the choices made.
A common mistake is copying a standard SoA from the internet. The auditor will see through this. The SoA must reflect how your organisation has applied the standard, not what a template looks like.
The link with Annex A and the risk analysis
The Statement of Applicability does not stand on its own. Three documents belong together:
- The risk analysis determines which risks you want to address.
- Annex A provides the catalogue of 93 controls you choose from.
- The Statement of Applicability records which controls you choose and why.
The SoA is a living document. If your risk profile changes, controls may become relevant or irrelevant. Review the SoA regularly, together with your risk analysis, as part of your ISMS maintenance.
More information
- Annex A: The 93 controls explained
- Risk analysis: From risk to control
- Requirements of the standard: Clause 6.1.3 on the SoA
- Mandatory documents: Full overview of all documents the standard requires
- Step-by-step guide: The SoA in the overall process
- What is ISO 27001?: Back to the hub