ISO 27001 Statement of Applicability (SoA) Guide
Quick Answer
The Statement of Applicability (SoA) is a mandatory ISO 27001 document that lists all 93 Annex A controls and states whether each is applicable or not, with justification. It's the bridge between your risk assessment and your implemented controls.
What Is the Statement of Applicability?
The Statement of Applicability (SoA) is one of the most important documents in your ISMS. Required by Clause 6.1.3(d), it's a comprehensive document that lists every Annex A control and records your decision about each one: is it applicable? Is it implemented? Why or why not?
Key Takeaways
- Mandatory document required by ISO 27001 Clause 6.1.3(d)
- Must list all 93 Annex A controls with applicability status and justification
- Links your risk assessment to your actual control implementation
- Auditors review the SoA extensively — it's a primary audit artifact
- Should be a living document, updated when risks or controls change
SoA Required Content
| Field | Description | Example |
|---|---|---|
| Control Reference | Annex A control number and name | A.8.5 Secure Authentication |
| Applicable (Yes/No) | Whether the control applies to your ISMS | Yes |
| Justification for Inclusion/Exclusion | Why the control is or isn't applicable | Required to address risk R-012: Unauthorized access to production systems |
| Implementation Status | Current state of the control | Implemented — MFA enforced on all production access |
| Implementation Method | How the control is achieved | Okta SSO with hardware key MFA for all production systems |
| Risk Reference | Link to the risk(s) this control addresses | R-012, R-015 |
Creating Your SoA
Step-by-Step SoA Creation
Complete the risk assessment first
The SoA must be informed by your risk assessment. You need to know your risks before you can determine which controls are applicable. Don't create the SoA before the risk assessment.
List all 93 Annex A controls
Create a document or spreadsheet listing every Annex A control. Most compliance platforms provide this as a template. Include the control number, name, and description.
Determine applicability for each control
For each control, decide if it applies to your ISMS scope. Consider: Does this control address an identified risk? Is it relevant to your operations? Is it required by legal/regulatory obligations?
Document justifications
For every control — whether included or excluded — document why. Included controls should reference specific risks. Excluded controls need clear justification (e.g., 'Physical security monitoring not applicable — fully remote organization with no physical premises').
Record implementation status
For applicable controls, document: fully implemented, partially implemented, or planned. Include how the control is implemented and what evidence exists.
Get management approval
The SoA should be formally approved by management, as it represents the organization's decisions about risk treatment.
Common SoA Mistakes
- Marking everything as applicable: If all 93 controls are applicable, auditors will question whether you did a genuine risk assessment or just selected everything
- Weak exclusion justifications: 'Not applicable' is not a justification. Explain why: 'No mobile devices used in ISMS scope' for mobile device management controls
- Disconnected from risk assessment: The SoA must trace to your risk assessment. If a control is included, it should address an identified risk. Random control selection undermines the risk-based approach
- Treating it as static: The SoA should be updated whenever your risk profile changes, new controls are implemented, or the ISMS scope changes
- Missing implementation details: Simply stating 'implemented' without describing how is insufficient. Auditors need to understand the implementation method
✅ SoA as a Security Dashboard
Think of your SoA as a high-level dashboard of your entire security control environment. When done well, anyone (auditors, management, customers) can look at the SoA and understand what controls you have, why, and how they're implemented. It's your single source of truth for control decisions.
93
Controls to Assess
Every Annex A control must be addressed
Clause 6.1.3(d)
ISO 27001 Requirement
Mandates the SoA document
60-80
Typical Applicable Controls
Most organizations implement
Living Document
Update Frequency
Review with each risk assessment cycle
Can I exclude controls from the SoA?
Yes, and you should exclude controls that aren't relevant to your risk profile or ISMS scope. However, you must document a clear justification for each exclusion. Auditors will specifically check that exclusions are reasonable and well-justified.
What format should the SoA be in?
ISO 27001 doesn't mandate a format. Most organizations use a spreadsheet or their compliance platform's built-in SoA module. The key is that it's comprehensive, clear, and easy to update. Templates are widely available.
How often should the SoA be updated?
At minimum, review the SoA during each risk assessment cycle (at least annually). Also update it when: new risks are identified, controls are added or removed, the ISMS scope changes, or significant organizational changes occur.
Do auditors focus heavily on the SoA?
Yes. The SoA is one of the first documents auditors review. It gives them a roadmap of your entire control environment. They'll check that control selections are justified by risks, exclusions are reasonable, and stated implementations match reality.
Build Your Statement of Applicability
Compare platforms with SoA templates, control mapping, and automated evidence tracking.
Browse ISO 27001 Tools