The Statement of Applicability (SoA) is one of the most important documents in an ISO 27001 Information Security Management System (ISMS). It connects your organization’s information security risks with the controls selected to address them.
Yet creating an SoA can be challenging, particularly for organizations implementing ISO 27001 for the first time.
Which controls should be included? Do all 93 Annex A controls need to apply? How should exclusions be justified? And how do you determine whether a control is implemented?
This guide explains how to create an ISO 27001:2022 Statement of Applicability, what information it must contain, and how to maintain it as your ISMS evolves.
What Is an ISO 27001 Statement of Applicability?
A Statement of Applicability is a documented record of the information security controls an organization has determined are necessary to address its risks and meet its information security requirements.
Under ISO/IEC 27001:2022, Clause 6.1.3(d), the SoA must include:
- The necessary information security controls.
- Justification for including those controls.
- Whether the necessary controls have been implemented.
- Justification for excluding any controls from Annex A.
The SoA serves as an important connection between the organization’s information security risk assessment, risk treatment decisions, and implemented controls.
It also provides management, internal auditors, and certification auditors with a structured view of the organization’s control decisions.
An SoA is not simply a checklist of security controls. It should explain why controls are necessary and accurately reflect the organization’s information security environment.
Understanding the 93 ISO 27001:2022 Annex A Controls
ISO/IEC 27001:2022 Annex A contains 93 reference controls organized into four categories.
| Control Category | Number of Controls |
|---|---|
| Organizational Controls | 37 |
| People Controls | 8 |
| Physical Controls | 14 |
| Technological Controls | 34 |
| Total | 93 |
These controls cover a broad range of information security practices, including security policies, access management, incident management, supplier relationships, physical security, and technological safeguards.
Annex A provides a reference set of controls to help organizations ensure they have not overlooked necessary security measures during risk treatment.
However, ISO 27001 does not require every organization to implement all 93 controls.
The controls selected must be appropriate for the organization’s risks, obligations, and operating environment.
Organizations may also identify necessary controls that are not explicitly listed in Annex A.
How to Create Your ISO 27001 Statement of Applicability
The following six steps provide a practical approach to developing your SoA.
Step 1: Establish Your ISMS Scope and Risk Treatment Decisions
Before preparing the Statement of Applicability, your organization should have a clear understanding of its ISMS scope and information security risks.
Start by reviewing:
- The defined scope of your ISMS.
- Information security risk assessment results.
- Risk treatment decisions and planned activities.
- Applicable legal, regulatory, and contractual obligations.
- Relevant business and information security requirements.
These inputs help determine which controls are necessary.
For example, an organization operating primarily in the cloud may have different physical security responsibilities than one operating its own data center.
However, relying on a cloud service provider does not automatically make physical security controls irrelevant. The organization may still need to address those risks through supplier management, contractual requirements, and other appropriate controls.
Practical tip: Develop your SoA from your risk treatment decisions rather than selecting controls based solely on what seems easy to implement.
Step 2: Identify Necessary Information Security Controls
Once your risk treatment decisions are established, identify the controls needed to address the organization’s information security risks.
ISO 27001 requires organizations to determine the necessary controls and compare them with Annex A to verify that no necessary controls have been overlooked.
This is an important distinction.
Annex A is a reference set, not necessarily the complete list of controls your organization may need.
For each control, consider:
- Which risks or requirements does this control address?
- Is the control necessary within our ISMS scope?
- Are there legal, contractual, or business requirements supporting its inclusion?
- Is the control implemented internally, provided by a third party, or supported through shared responsibilities?
- Have we identified necessary controls beyond those listed in Annex A?
The outcome should be a defensible selection of controls based on the organization’s actual needs.
Step 3: Determine Applicability and Document Justifications
For each Annex A control, determine whether it is applicable to your organization.
Your SoA should clearly identify the applicable controls and document the justification for including them.
For controls excluded from Annex A, provide an appropriate explanation.
Consider the following illustrative examples.
Example 1: Applicable Control
Control A.5.1 — Policies for Information Security
Applicability: Yes
Justification: Information security policies are necessary to establish management direction, define security expectations, and support consistent information security practices throughout the organization.
Example 2: Potentially Excluded Control
Control A.7.4 — Physical Security Monitoring
Applicability: No, subject to the organization’s risk assessment and ISMS scope.
Illustrative justification: The organization operates without facilities or physical environments under its direct control that require monitoring under this control. Relevant physical security risks associated with outsourced facilities are addressed through established supplier arrangements and other selected controls.
This second example is not a recommendation to exclude A.7.4. It illustrates the type of reasoning an organization might document if its assessment supports that decision.
Exclusions should never be based solely on convenience, implementation cost, or a desire to reduce the number of controls.
Common mistake: Marking a control as not applicable simply because it has not yet been implemented.
Applicability and implementation status are different decisions. A control can be necessary even when the organization has not implemented it.
Step 4: Document Control Implementation Status
After identifying the necessary controls, record whether they have been implemented.
ISO 27001 requires the SoA to indicate whether necessary controls are implemented.
Many organizations find it useful to track implementation using more detailed internal statuses, such as:
| Implementation Status | Meaning |
|---|---|
| Non-Existent | The control has not been implemented. |
| Partial | The control has been implemented to some extent but is not fully established. |
| Implemented | The control has been implemented. |
These categories are practical management options, not implementation-status labels prescribed by ISO 27001.
For example, an organization may have an incident management procedure but may not yet have established all the supporting activities needed to operate it consistently.
The organization could classify the relevant control as partially implemented while it completes the necessary improvements.
The SoA should accurately reflect the organization’s current implementation, not its intended future state.
Where controls remain incomplete, the organization should manage the outstanding activities through its risk treatment and implementation planning processes.
Step 5: Review and Approve the Statement of Applicability
Before finalizing the SoA, review it with the appropriate stakeholders.
Depending on the organization, these may include:
- The ISMS manager or information security lead.
- Information security risk owners.
- Relevant control owners.
- Business or process owners.
- Management responsible for ISMS oversight.
The review should verify that:
- Necessary controls have been identified.
- The Annex A comparison has been completed.
- Inclusion and exclusion justifications are reasonable.
- Implementation statuses are accurate.
- The SoA aligns with risk treatment decisions and supporting documentation.
Formal approval arrangements should follow the organization’s established ISMS governance and document-control requirements.
Although ISO 27001 does not prescribe a universal SoA approval workflow, a documented review and approval process can strengthen accountability.
Step 6: Maintain and Update Your SoA
Your Statement of Applicability should not become a document that is prepared once for certification and then forgotten.
Information security risks, technologies, business activities, and regulatory obligations change over time.
Your organization should review the SoA when relevant changes occur, such as:
- Significant changes to the ISMS scope.
- New or materially changed information security risks.
- Changes to risk treatment decisions.
- Implementation of new technologies or business processes.
- Changes to legal, regulatory, or contractual obligations.
- Significant control changes or assessment findings.
Periodic review is also a useful practice, even when no major changes have occurred.
Maintaining an accurate SoA helps ensure that the organization’s documented control decisions continue to reflect its actual information security environment.
Download a Free ISO 27001:2022 Statement of Applicability Template
You don’t need to build your Statement of Applicability spreadsheet from scratch.
GRCPod offers a free Statement of Applicability+ template designed to help organizations document and maintain their ISO 27001:2022 control decisions.
The editable workbook includes:
- All 93 Annex A controls, with identifiers, titles, and descriptions.
- Applicability tracking and example justifications.
- Control implementation status.
- Optional conformity assessment fields.
- Optional control maturity scoring.
- CIA objective tracking.
- Date of last assessment.
- A document-control record and maturity-level reference.
The template is available in Microsoft Excel and Google Sheets formats and includes a companion guide explaining how to use it.
[DOWNLOAD THE FREE STATEMENT OF APPLICABILITY+ TEMPLATE]
The template provides a starting point and must be customized to reflect your organization’s risk treatment decisions and control requirements.
Common Statement of Applicability Mistakes to Avoid
Even organizations with established information security programs can encounter problems when preparing or maintaining an SoA.
Here are five common mistakes worth avoiding.
1. Treating Annex A as a Mandatory Implementation Checklist
Not every Annex A control must be implemented by every organization.
The organization must determine necessary controls through its risk treatment process and document its control decisions appropriately.
2. Excluding Controls That Have Not Been Implemented
A control that has not yet been implemented may still be necessary.
Record the control as applicable and accurately document its implementation status rather than excluding it to conceal an implementation gap.
3. Using Generic Justifications Without Reviewing Them
Template justifications can help organizations get started, but they should not replace organization-specific reasoning.
Your justifications should reflect actual risks, requirements, and control decisions.
4. Maintaining an SoA That Conflicts With the Risk Treatment Plan
The SoA and risk treatment plan serve different purposes, but they should be consistent.
If a control is necessary to treat a risk, the organization’s documentation should not contradict that decision.
5. Failing to Update the SoA After Significant Changes
An outdated SoA can create confusion during management reviews, internal audits, and certification assessments.
Establish responsibility for maintaining the document and reviewing it when relevant changes occur.
Beyond Applicability: Tracking Control Conformity and Maturity
Although ISO 27001 defines the required contents of the Statement of Applicability, organizations may choose to use the document for additional control management activities.
For example, GRCPod’s Statement of Applicability+ includes optional fields for tracking:
Control conformity: Whether an assessment found that a control meets the applicable requirements or assessment criteria.
Control maturity: How consistently and effectively the control is established, operated, measured, and improved.
CIA objectives: Whether a control supports confidentiality, integrity, availability, or a combination of these objectives.
Assessment dates: When the control was last evaluated.
These fields can provide additional visibility into the organization’s control environment.
However, they should not be confused with mandatory SoA requirements or ISO 27001 certification scores.
A control may be implemented but have an assessment finding. Similarly, a control may be implemented without having reached a high level of maturity.
Keeping these concepts separate can help organizations identify improvement opportunities without misrepresenting implementation status.
Frequently Asked Questions
Is a Statement of Applicability mandatory for ISO 27001?
Yes. ISO/IEC 27001:2022 Clause 6.1.3(d) requires organizations to produce a Statement of Applicability containing the necessary controls, inclusion justifications, implementation information, and justifications for excluding Annex A controls.
Do all 93 Annex A controls have to be applicable?
No. Organizations must determine which controls are necessary based on their risk treatment decisions and requirements.
Any exclusions from Annex A must be justified.
Can an organization include controls that are not in Annex A?
Yes. Organizations may identify necessary information security controls beyond the Annex A reference set.
The SoA should include the necessary controls identified through the organization’s risk treatment process.
How often should a Statement of Applicability be reviewed?
ISO 27001 does not establish a universal annual review frequency specifically for the SoA.
Organizations should maintain it as their risk treatment and control decisions change. Establishing a periodic review schedule is also a sensible management practice.
Is the Statement of Applicability the same as a risk treatment plan?
No.
The risk treatment plan describes how the organization intends to address identified information security risks.
The Statement of Applicability documents the necessary controls, their inclusion justifications, whether they are implemented, and justifications for excluding Annex A controls.
The two documents should be consistent.
Final Thoughts
Creating an ISO 27001 Statement of Applicability is not simply an exercise in documenting 93 controls.
It requires understanding your organization’s information security risks, determining which controls are necessary, documenting the reasons for those decisions, and maintaining an accurate record of implementation.
A well-developed SoA supports informed risk management, consistent control oversight, and more effective ISMS governance.
Start with your risk treatment decisions, document your reasoning, and keep the SoA current as your organization evolves.
Ready to create yours?
[GET THE FREE ISO 27001 STATEMENT OF APPLICABILITY+ TEMPLATE]
