What is a Statement of Applicability?
Statement of Applicability (SoA) is a central document in ISO 27001. It lists all controls in Annex A and states for each control:
- Whether it is applicable or not
- Justification for the decision
- Implementation status
Insight: The SoA is not a checklist to tick off. It is a strategic document that shows the organisation has made conscious, risk-based choices about its security work.
Why is the SoA important?
The SoA serves several functions:
- Certification requirement — Mandatory under ISO 27001 clause 6.1.3
- Communication — Shows stakeholders which controls you have implemented
- Reference — Starting point for internal audit and control monitoring
- Traceability — Links risk assessment to concrete measures
- Transparency — Documents conscious choices and priorities
Without an SoA:
- No ISO 27001 certification possible
- Difficult to demonstrate systematic security work
- Risk of arbitrary control selection
ISO 27001:2022 Annex A structure
The 93 controls are organised into four themes:
| Theme | Number of controls | Focus |
|---|---|---|
| A.5 Organisational | 37 | Policies, roles, suppliers |
| A.6 People | 8 | Employment, training, termination |
| A.7 Physical | 14 | Premises, equipment, environment |
| A.8 Technological | 34 | Systems, networks, encryption |
SoA process step by step
- Conduct risk assessment first The SoA is based on your risk assessment. Identify what risks exist, which assets need protection and which threats are relevant. Without risk assessment, the SoA becomes arbitrary.
- List all Annex A controls Create a table with all 93 controls. Include control number, name and description. This becomes the foundation for your SoA.
- Assess applicability For each control: Is it relevant to your operations and risk profile? Answer yes or no. Remember that "not applicable" requires strong justification.
- Justify every decision Regardless of whether the control is applicable or not — document why. Link to the risk assessment. "Implement to handle risk X" or "Not applicable as we do not have Y".
- Document implementation status For applicable controls: Is it implemented? Partially? Planned? State status and any deadline.
- Link to documentation Connect each control to relevant policy, procedure or technical implementation. This facilitates audit.
- Review and approve The SoA should be approved by management. This shows ownership and responsibility for security choices.
Example SoA structure
| Control | Description | Applicable | Justification | Status | Documentation |
|---|---|---|---|---|---|
| A.5.1 | Policies for information security | Yes | Fundamental governance required | Implemented | POL-001 |
| A.5.9 | Inventory of information assets | Yes | Risk: Unidentified assets | Implemented | PROC-012 |
| A.7.3 | Securing offices and facilities | Yes | Physical office premises exist | Implemented | POL-015 |
| A.7.4 | Physical security monitoring | No | Handled by property owner, contract exists | Not applicable | CNT-023 |
| A.8.20 | Networks security | Yes | Critical infrastructure | Partial | PROJ-007 |
Valid and invalid justifications
• The risk does not exist (e.g. no physical servers = no physical server security)
• Handled by another control
• Outsourced to supplier with contract
• The business lacks relevant process (e.g. no system development)
• "We cannot afford it"
• "We do not have time"
• "It is too complicated"
• "No one has asked for it"
• No justification at all
Common controls often excluded
Controls often (legitimately) excluded:
| Control | Common justification |
|---|---|
| A.5.23 Information security for cloud services | No cloud usage |
| A.7.4 Physical security monitoring | Handled by property owner |
| A.8.25 Secure development life cycle | No internal development |
| A.8.26 Application security requirements | No internal development |
| A.8.28 Secure coding | No internal development |
| A.8.31 Separation of development environments | No internal development |
Important: Even if you do not develop internally, you may use software that requires secure configuration. Consider carefully.
Auditor’s perspective
What the auditor looks at:
- Completeness — All 93 controls must be included
- Consistency — Justifications must be logical and consistent
- Risk connection — Decisions should link to risk assessment
- Implementation — Applicable controls should actually exist
- Documentation — References should lead to correct documents
- Currency — SoA should be up to date
Common non-conformities:
- Missing controls
- Inadequate justifications
- Applicable controls that are not implemented
- Old SoA that does not reflect current state
SoA and NIS2 requirements
The SoA can be extended to cover NIS2 requirements that go beyond ISO 27001:
| NIS2 requirement | Relevant ISO 27001 controls | SoA note |
|---|---|---|
| Incident reporting 24h | A.5.24-A.5.28 | Extended procedure for time requirements |
| Supply chain security | A.5.19-A.5.22 | Enhanced due diligence |
| Business continuity | A.5.29-A.5.30 | Testing frequency per NIS2 |
| Management training | A.6.3 | Specific content for management |
Maintaining the SoA
- Annual review Go through the entire SoA at least annually. Is the control status correct? Has the business changed? Are there new risks?
- Update on changes New business, new systems, organisational changes — all can affect the SoA. Update proactively.
- Link to internal audit Internal audit should verify that the SoA reflects reality. Non-conformities lead to updates.
- Version control Keep track of changes. Who changed what and why? Save history.
SoA checklist
Before certification audit:
- All 93 Annex A controls listed
- Applicability stated for each control
- Justification documented for each decision
- Exclusions have valid reasons
- Implementation status updated
- References to policy/procedure exist
- Connection to risk assessment clear
- Approved by management
- Version control in place
- Last updated date specified
How Securapilot can help
Securapilot simplifies SoA management:
- Pre-built structure — All 93 controls predefined
- Justification templates — Examples and guidance
- Status tracking — See implementation progress
- Document linking — Connect to policies and procedures
- Version history — Full traceability of changes
- Audit reports — Export for external audit
Book a demo and see how we simplify your SoA work.
Frequently asked questions
Must all 93 controls be included in the SoA?
Yes, all 93 controls in Annex A must be listed in the SoA. For each control you must state whether it is applicable or not, and justify the decision.
Can I exclude controls?
Yes, but every exclusion must be justified. Valid reasons include that the risk does not exist (e.g. no mobile working) or that it is handled by another control. 'We cannot afford it' is not a valid justification.
How often should the SoA be updated?
The SoA should be a living document that is updated when there are changes in operations, risk landscape or control implementation. It should be reviewed at least annually.
What does the auditor look at in the SoA?
The auditor checks: 1) That all controls are listed, 2) That justifications are reasonable, 3) That applicable controls are actually implemented, 4) Connection to risk assessment.
