The SoA, or Statement of Applicability, is one of the central documents of an information security management system (ISMS). Without a robust SoA, certification in accordance with ISO 27001 is not possible. This article explains the benefits of the SoA, how it is structured under ISO 27001:2022, and what role it plays in the audit.
What is SoA under ISO 27001?
SoA is a mandatory document in accordance with Section 6.1.3 d) of ISO/IEC 27001:2022. For each of the 93 measures (controls) from Annex A, it documents whether the control is applicable to your organization, why it was included or excluded, and—for applicable controls—how it has been implemented. Your SoA thus forms the bridge between your risk assessment and the specific security measures you have chosen.
Key to understanding it: Annex A is a reference catalog, not a mandatory checklist. ISO 27001 does not require you to implement all 93 controls. What is required is that every inclusion and every exclusion be justified in a comprehensible way based on your risk assessment. SoA is therefore the document that makes your risk-based decisions visible and verifiable.
The importance of SoA in the ISMS
Auditors examine the SoA particularly closely. It is among the most intensively reviewed documents in certification and surveillance audits. The reason lies in its function: The SoA makes it visible at a glance how a company manages its information security. It links the results of the risk assessment with the risk treatment plan and the measures actually implemented.
For CISOs, IT managers, and compliance officers, SoA is therefore much more than a formality. It is the management tool that demonstrates that security decisions were made on a risk-based and well-founded basis, and not according to the principle of "we just take all controls." A well-maintained SoA shortens audits because it provides auditors with a clear roadmap of the chosen security architecture. Conversely, an incomplete or generic SoA leads to follow-up questions, nonconformities, and rework.
SoA and risk treatment plan: two documents, one process
In practice, SoA and the risk treatment plan are frequently confused. Both belong to Section 6.1.3, but they serve different purposes: The risk treatment plan defines how and by when specific risks are to be addressed—it is therefore the implementation roadmap. The SoA, by contrast, is the inventory; it documents which controls are applicable, why, and whether they have been implemented.
ISO 27005:2022, the companion standard for information security risk management, recommends deriving the SoA directly from the risk assessment and the risk treatment plan. Controls should therefore not be included in the SoA independently of the risk process, since only in this way can the chain from the identified threat to the implemented measure remain consistently traceable.
Structure: what SoA must contain according to ISO 27001:2022
According to Section 6.1.3 d), a complete SoA must contain four elements:
- Necessary controls: the list of all measures required to treat the identified risks, aligned with Annex A and, where necessary, supplemented by additional sources (such as NIST publications or ENISA guidelines). Annex A is considered comprehensive, but not exhaustive.
- Justification for inclusion: the risk-based, legal, or business-related rationale for why an applicable control has been included.
- Implementation status: the indication of whether an applicable control has already been implemented or not.
- Justification for exclusion: the rationale for each Annex A control that is not applicable and has therefore been excluded.
In practice, the SoA is usually maintained as a table, supplemented by columns for references to related policies as well as review and approval dates. This way, it remains a living document that reflects the current status of your security architecture.
Because the SoA discloses which security measures a company implements and which it does not, it is considered a confidential document. While it is presented to the auditor, it should not be shared without protection, as the information it contains could otherwise be used as a roadmap for attacks. In addition, the SoA must be reviewed and approved by management or the responsible authority. Without this approval, it will not hold up in an audit.
Overview of the 93 Annex A controls
With the ISO 27001:2022 revision, Annex A was fundamentally restructured. The former 114 controls in 14 domains have been consolidated into 93 controls, organized into four subject areas:
- Organizational controls (A.5): 37 controls (5.1–5.37) – policies, roles and responsibilities, supplier relationships, threat intelligence, and incident management.
- People controls (A.6): 8 controls (6.1–6.8) – screening, terms and conditions of employment, awareness and training, disciplinary process, remote working.
- Physical controls (A.7): 14 controls (7.1–7.14) – access control, physical monitoring, protection of facilities and equipment.
- Technological controls (A.8): 34 controls (8.1–8.34) – access rights, cryptography, logging, secure development, network security.
The shift from 14 domains to four subject areas is more than a cosmetic change. The controls are now organized according to the nature of what they govern (organizational, people, physical, technological) rather than by technical domain. For SoA, this means that anyone transitioning from a 2013 version must map existing assignments to the new structure and also take the merged and renamed controls into account.
Eleven controls were newly added in the 2022 version, including Threat Intelligence (5.7), Information Security for Cloud Services (5.23), and Data Masking (8.11). Important for practice: As of October 31, 2025, certificates issued under the old ISO 27001:2013 version are no longer valid. Every current SoA based on ISO 27001:2022 must therefore be built on the 93-control catalog. Anyone still working with the old 14-domain structure is thus maintaining a document based on a withdrawn standard.
Four steps to your SoA
A robust SoA is the result of risk management:
- Conduct a risk assessment: Identify and evaluate the risks to your information assets. This is the only way to determine which controls are actually necessary. Without this step, the SoA lacks its foundation.
- Derive controls and reconcile with Annex A: Derive the required measures from the risk treatment and reconcile them with Annex A. This comparison ensures that you do not overlook any relevant measure. It is explicitly not intended to be used to adopt all controls across the board.
- Justify inclusions and exclusions: Document the decision for each control with a traceable, risk-based justification. Generic wording is the most common cause of audit nonconformities here.
- Recording and approving implementation status: Record which controls have been implemented and have the SoA approved by responsible parties. It is then reviewed and updated regularly, and at the latest whenever there is a significant change in the risk situation.
C
ommon mistakes when creating the SoA
Three patterns come up again and again in audits:
- Generic justifications: Blanket wording that does not refer to the specific risk assessment will not withstand scrutiny.
- Lack of updates: An SoA that is no longer maintained after certification loses its value as a management tool and diverges from the actual security posture.
- Decoupling from risk assessment: If controls are included without reference to the risk analysis, the result is a document that feigns security rather than substantiating it.
Athereon GRC: Creating the SoA in the ISMS module
Creating and maintaining the SoA can be significantly simplified with the right software. Athereon GRC is an ISMS software solution that reliably supports companies in creating the SoA in accordance with ISO 27001. As a leading European GRC platform, Athereon GRC combines risk assessment, control selection, and the SoA into one seamless process: The measures derived from risk treatment, including their justification and implementation status, flow directly into the Statement of Applicability.
Athereon GRC is built on a framework-agnostic architecture. In addition to ISO 27001, other frameworks can be mapped—from TISAX® to industry-specific requirements—without having to switch systems. As part of a platform with ISMS, ERM, BCM, DSM, and SRM modules, the SoA is connected to your entire governance, risk, and compliance management. This makes it possible to leverage compliance as an opportunity—100% Made in Germany.
You can find more about the regulatory framework of the standard on our ISO 27001 topic page.
AI agent LAiKA supports control mapping
Mapping risks to the appropriate Annex A controls is the most labor-intensive part of the SoA. This is where AI agent LAiKA comes in. Building on the foundation of the platform, LAiKA Assist supports recurring tasks and hands off to the specialized agents when needed. For SoA, the Compliance Assistant is particularly relevant: Based on your risk assessment, it suggests suitable controls and helps justify inclusions and exclusions. The Infrastructure Mapper captures the underlying infrastructure, while the Questionnaire Assistant supports structured completion of control questionnaires.
The following principle applies throughout: Nothing without your OK. LAiKA prepares and proposes. You make the decision about every inclusion, every exclusion, and every justification. Especially with SoA, whose statements must hold up in an audit, the responsibility for the content therefore remains where it belongs.
Conclusion
SoA is the heart of ISO 27001 documentation: It combines risk assessment, control selection, and implementation status into a coherent overall picture. Those who build it on a risk-based, well-justified, and well-maintained foundation not only pass the audit but also gain a management tool for information security.
Would you like to create and maintain your SoA according to ISO 27001:2022 efficiently? Athereon GRC supports you throughout the entire journey—from risk assessment to the finished Statement of Applicability. Learn more about ISO 27001 with Athereon GRC.
