Introduction: Why the SoA Is the Backbone of Your ISO 27001
There's no way around the Statement of Applicability (SoA) in ISO 27001 certification. This document shows which security measures you've selected to protect your information assets.
A good SoA is like a map for your information security management system (ISMS). It shows auditors and internal teams which controls you apply, which you don't — and why. No SoA, no certification.
What Is the Statement of Applicability (SoA)?
The Statement of Applicability (SoA) under ISO 27001:2022 documents all relevant security measures (Annex A controls) and their implementation status.
It answers three key questions:
- Which Annex A controls were selected?
- What's the implementation status? (implemented, planned, excluded)
- Why were certain controls excluded?
Official definition:
According to ISO/IEC 27001:2022, the SoA is a document that "contains all relevant security measures, including their implementation status and the justifications for their selection or exclusion."
Why the SoA Is So Important
The SoA serves as evidence, a management tool, and a basis for communication.
| Function | Meaning |
|---|---|
| Transparency | Clearly shows which measures are relevant |
| Audit evidence | Foundation for every audit review |
| Risk management | Links risks to measures |
| Responsibilities | Assigns owners and documents |
| Continuous improvement | Basis for annual ISMS reviews |
Tip: Auditors usually start their review with the SoA. If it's well maintained, this significantly shortens the audit process.
The Structure of a Statement of Applicability
The SoA is typically organized as a table. A typical structure:
| Control | Description | Implemented | Justification | Evidence |
|---|---|---|---|---|
| A.5.1 | Information Security Policies | yes | Policy created and communicated | Policy document |
| A.6.2 | Segregation of Duties | no | Partially implemented, roles still being defined | Permission matrix |
| A.7.1 | Physical Security Perimeter | no | Not relevant for remote work | - |
How to Create a Statement of Applicability Step by Step
1. Conduct a Risk Analysis
Assess business risks: what threats exist to confidentiality, integrity, and availability?
2. Select Relevant Controls
Select all Annex A controls (ISO 27001:2022) that address your risks.
3. Document Implementation Status
For each control, mark whether it's implemented, planned, or excluded.
4. Add Justifications and Evidence
Briefly explain why you're excluding or still planning something. Link supporting evidence (e.g., policies, records).
5. Regular Updates
Review your SoA at least once a year or after any relevant changes.
Practical Example: Atlassian
The Atlassian Trust Center is a great example of how transparency builds trust. Atlassian openly publishes which ISO 27001 measures it has implemented — including documentation.
This shows how you can use your own SoA as an internal trust document — not just for auditors, but for partners and customers too.
Common Mistakes with the Statement of Applicability
| Mistake | Description | Solution |
|---|---|---|
| Missing justifications | Controls excluded without explanation | Always provide a reason, even for "not relevant" |
| Unclear responsibilities | No one is accountable | Define roles within the ISMS |
| Outdated versions | Changes not recorded | Schedule an annual review |
| Copied templates | Generic templates with no real relevance | Every SoA is unique |
Tip: Introduce "SoA versioning," similar to software, to keep changes traceable.
Automation & SoA Implementation with heyData
At heyData, we support businesses throughout their entire journey to ISO 27001 certification — and the Statement of Applicability (SoA) plays a central role in that process. We don't just provide a tool for documenting your SoA; we actively help you build it correctly and continuously adapt it as your ISMS grows.
Our approach ensures that your SoA doesn't remain a static document, but instead becomes a dynamic reflection of your security strategy.
With heyData, you can:
- Link Annex A measures to your risk analysis and policies.
- Generate your SoA, based on your asset and risk register — with clear traceability and evidence for every measure.
- Track implementation progress and transparently assign responsibilities.
- Ensure audit readiness, thanks to versioning and change tracking with every SoA update.
- Integrate continuous improvements, by feeding results from audits and management reviews directly into your SoA.
In short: heyData transforms the SoA from a mere compliance requirement into a living management tool that unites governance, risk, and security in one central system.
Conclusion: The SoA as the Heart of Your ISO 27001
The Statement of Applicability (SoA) isn't a form you simply "fill out" — it's the strategic heart of your ISMS. It connects risks, measures, and responsibilities.
With a structured, up-to-date, and transparent SoA, you lay the foundation for a successful ISO 27001 certification — and for your customers' trust.
FAQ
What is the Statement of Applicability under ISO 27001:2022?
What is the Statement of Applicability under ISO 27001:2022?
The SoA is a mandatory document that lists all 93 security controls (Annex A controls) and describes whether they're implemented, planned, or excluded.
Why is the SoA so important?
Why is the SoA so important?
It's the central proof for auditors that your ISMS is based on a conscious risk assessment.
How often should the SoA be updated?
How often should the SoA be updated?
At least once a year or after significant changes in the company.
Who creates the SoA?
Who creates the SoA?
Usually the ISMS team or the data protection or information security officer.
How can I automate the SoA?
How can I automate the SoA?
With tools like heyData, you can automatically maintain your SoA, version it, and export it audit-ready.







