The Statement of Applicability
The Statement of Applicability (SoA) is a mandatory document that identifies which information security controls the organization has selected to manage its risks. It requires a formal justification for why specific controls are included or excluded and a statement on their current implementation status.
What it means
The SoA acts as the bridge between your risk assessment process and your actual operational security environment. Rather than blindly implementing every possible security measure, the SoA allows you to tailor your security framework based on your specific business needs, legal obligations, and identified risks.
In practice, the SoA serves as a master index for your entire Information Security Management System (ISMS). It tells an auditor exactly which controls from Annex A (and potentially other frameworks) are in scope and where they stand in terms of deployment.
It is not merely a checklist but a record of decision-making. By documenting why certain controls were omitted, the organization demonstrates that it has consciously evaluated its risk landscape rather than simply ignoring requirements.
How to meet it
- Conduct a comprehensive risk assessment to identify threats and vulnerabilities relevant to your business.
- Review every control listed in Annex A of ISO/IEC 27001:2022 to determine if it is necessary to treat an identified risk or satisfy a legal requirement.
- Create a document (typically a spreadsheet) that lists all Annex A controls as the baseline.
- For each selected control, write a brief justification explaining why it is necessary and how it addresses your specific risks.
- For every excluded control, provide a clear technical or business justification for why it does not apply to your environment.
- Indicate the current implementation status of each applicable control (e.g., "Implemented," "In Progress," or "Planned").
Evidence an auditor asks for
- The completed Statement of Applicability document containing the list of controls, justifications, and statuses.
- A risk treatment plan that maps identified risks to the controls selected in the SoA.
- Supporting evidence (policies, configurations, logs) for any control marked as "Implemented" within the SoA.
- Evidence of management review and formal approval/sign-off on the version of the SoA currently in use.
Common pitfalls
- Excluding controls without a valid justification or using generic phrases like "not applicable" without explaining why.
- Treating the SoA as a static document that is only created during initial certification rather than updating it after risk reviews.
- Selecting every single Annex A control to avoid the effort of justifying exclusions, which creates an unnecessary and unsustainable compliance burden.