An ISO 27001 Statement of Applicability, commonly called an SoA, is an important document within an Information Security Management System. It records the security controls an organisation considers necessary and explains the decisions behind those controls.
For organisations preparing for certification, ISO Consultancy Oman can help connect the risk assessment, risk treatment decisions, Annex A controls and supporting evidence. This guide explains what an SoA contains, how to prepare it, how to justify control decisions and what auditors look for during certification.
What Is a Statement of Applicability in ISO 27001?
A Statement of Applicability is a documented record of the information security controls an organisation considers necessary for its ISMS. It shows which controls apply, why they are needed, their implementation status and why certain Annex A controls may not apply.
The SoA gives management, employees and auditors a clear view of the organisation’s control decisions. It connects security risks with the measures selected to address them. It also provides a central reference for understanding the security controls within the defined ISMS scope. Instead of viewing controls separately, the organisation can show how its security arrangements support identified risks and requirements. A well prepared SoA also makes certification work easier because the organisation can show the reasoning behind its control decisions.
What Must an ISO 27001 Statement of Applicability Contain?
The standard requires specific information, but organisations can choose a practical format that suits their ISMS. The important point is that the document clearly records control decisions and their reasoning.
Necessary information security controls
The SoA should identify the controls that the organisation considers necessary to address its information security risks and other applicable requirements.
These controls are not limited to Annex A. An organisation can develop or adopt additional controls when its risks, legal obligations, contractual commitments or business needs require them.
Justification for including each necessary control
Every necessary control should have a clear reason for inclusion. The explanation can be connected to an identified risk, a legal requirement, a contractual obligation or another relevant business requirement.
Justification for excluding Annex A controls
An Annex A control can be excluded when it is genuinely not necessary for the organisation’s circumstances and defined ISMS scope.
How to record additional controls outside Annex A
An organisation may therefore have internal controls or other security measures outside Annex A. Identify these controls in the SoA when they form part of the necessary control framework.
How the SoA Connects Risk Assessment, Risk Treatment and Annex A
The strongest SoAs follow a clear chain from risk identification to implementation. Control selection should not begin with simply ticking boxes in Annex A.
Start with information security risks
The organisation first identifies relevant information, assets, processes, threats, vulnerabilities and potential consequences within the ISMS scope.
The risk assessment then helps determine which risks require treatment and what level of protection is appropriate.
Turn risk treatment decisions into controls
Once risks have been assessed, the organisation determines how those risks will be treated. The selected treatment may require one or several security controls.
This creates a direct relationship between the risk and the control used to address it. The SoA documents that relationship.
Use Annex A as a reference control set
The 2022 version of ISO 27001 includes 93 Annex A controls. These controls provide a reference point for reviewing the security measures relevant to the ISMS.
Organisations should not automatically implement every control simply because it appears in Annex A. Applicability should be determined according to the organisation’s circumstances and risk treatment decisions.
Map necessary controls back to Annex A
The organisation can compare its necessary controls with the Annex A reference controls. This helps demonstrate that Annex A has been considered during the control selection process.
The necessary control does not have to use exactly the same wording as an Annex A control. What matters is that the control decision is clear and properly documented.
What Columns Should an ISO 27001 SoA Include?
There is no requirement to use one fixed spreadsheet design. However, a practical SoA should make important control information easy to understand and verify.
| SoA column | What to record |
| Control reference | Annex A reference or internal control ID |
| Control name or description | Relevant control description |
| Applicable? | Yes or No |
| Inclusion justification | Risk, legal, contractual or business reason |
| Exclusion justification | Specific reason for exclusion |
| Implementation status | Current implementation position |
| Implementation reference | Policy, procedure, system or process |
| Evidence reference | Available audit evidence |
| Risk reference | Related risk or treatment decision |
| Control owner | Responsible person or function |
This structure gives auditors a clear path from a control decision to supporting documentation. It also helps management monitor the progress of implementation.
For organisations working with ISO Consultancy Oman, a structured SoA can make it easier to identify missing justifications, unclear ownership and evidence gaps before an external audit.
How to Create an ISO 27001 Statement of Applicability Step by Step
The SoA should be developed as part of the ISMS process rather than treated as a separate spreadsheet created at the end.
1. Define the ISMS scope
Start by establishing exactly what the ISMS covers. This can include locations, departments, processes, systems, information and relevant third parties. Control applicability depends heavily on the scope. A control relating to an activity outside the defined scope may have a different applicability position from one affecting an activity within the scope.
2. Complete the information security risk assessment
Identify and evaluate the information security risks affecting the defined scope. The organisation should understand its risks before deciding which controls are necessary. Starting with controls and then trying to find risks to support them can create weak documentation.
3. Define the risk treatment plan
Determine how identified risks will be treated and record the selected treatment decisions. Where treatment requires security measures, those measures become part of the control selection process.
4. Identify the necessary controls
Select the controls needed to address the organisation’s risks and applicable requirements. At this stage, consider internal requirements, legal obligations, contractual commitments and business needs alongside the risk assessment.
5. Compare necessary controls against Annex A
Review all 93 Annex A controls and compare them with the controls already identified. This process can identify controls that are already covered, controls requiring additional action, controls outside Annex A and controls that genuinely do not apply.
6. Write the inclusion and exclusion justifications
Record why each necessary control is included and why any Annex A control is excluded. The explanation should connect to the organisation’s actual risks, requirements, scope or circumstances.
7. Record implementation status
Show the real implementation position for each control. Planned work should remain clearly different from controls that are operating.
8. Link the SoA to policies and evidence
Identify the documents, systems and records that support implementation. Examples include policies, procedures, access reviews, logs, contracts, training records and system configurations.
9. Review and approve the SoA
The completed SoA should be reviewed by appropriate management and controlled as part of the ISMS documentation. Regular review also helps ensure that the document remains consistent with changes to risks, systems and business activities.
How to Justify an Excluded Annex A Control
Exclusions often receive attention during audits because they can reveal gaps between the SoA and the actual business environment. An Annex A control may be excluded when it is not necessary for the organisation’s actual circumstances and defined ISMS scope.
The organisation should be able to explain why the control does not address a relevant risk or requirement.
What Auditors Check in an ISO 27001 Statement of Applicability
An auditor is not only interested in seeing a completed spreadsheet. The auditor may also examine whether the decisions documented in the SoA match the wider ISMS.
Does the SoA match the risk assessment?
The identified risks should logically support the selected controls. Large risks with no corresponding treatment or control may attract questions.
Does the SoA match the risk treatment plan?
The risk treatment plan and SoA should tell a consistent story. Treatment decisions should not contradict control applicability or implementation information.
Are all Annex A controls addressed?
There should be no unexplained gaps in the organisation’s consideration of Annex A controls.
Are exclusions supported by real business circumstances?
Auditors may challenge exclusions that appear generic or inconsistent with the organisation’s actual activities.
Does implementation status match reality?
If the SoA says a control is implemented, the organisation should be able to demonstrate that it operates in practice.
Are the SoA and ISMS documents consistent?
Check consistency across the ISMS scope, risk register, risk treatment plan, policies, procedures and internal audit findings.
Common ISO 27001 SoA Mistakes That Create Audit Problems
Several simple mistakes can weaken an otherwise well-organised SoA.
Treating the SoA as an Annex A checklist
Ticking 93 boxes does not demonstrate that control selection was based on the organisation’s risks and requirements.
Using “Not applicable” without an explanation
Unsupported exclusions provide little evidence that the applicability decision was properly considered.
Copying a generic SoA template without adapting it
A template may contain controls, assumptions or justifications that do not match the organisation’s actual activities.
Selecting controls without linking them to risks
This can create a gap between the risk assessment, treatment plan and SoA.
Showing controls as implemented when they are only planned
This can lead to evidence problems during certification because auditors may expect proof of operation.
Ignoring controls outside Annex A
Necessary controls can exist outside the Annex A reference set, so organisations should not limit their review to the 93 controls.
When Should You Update the ISO 27001 Statement of Applicability?
The SoA should remain current as the ISMS changes.
Update after changes to the risk assessment
New or changed risks can affect control applicability and treatment decisions.
Update after adding or removing systems and processes
Changes to systems, processes or scope can change which controls are necessary.
Update after major supplier or outsourcing changes
A new supplier or outsourcing arrangement can introduce different information security risks and responsibilities.
Update after new legal or contractual requirements
New obligations may require additional controls or changes to existing decisions.
Update after incidents and corrective actions
Security incidents can reveal weaknesses that require changes to risk treatment and control selection.
Update after internal and external audits
Audit findings may lead to changes in controls, implementation status or supporting evidence.
Review it as part of the ISMS improvement cycle
The SoA should function as living ISMS documentation rather than a document prepared only before certification.
ISO 27001 SoA vs Risk Register vs Risk Treatment Plan
These documents have different purposes but should work together.
| Document | Main purpose |
| Risk Register | Records identified information security risks |
| Risk Treatment Plan | Records how selected risks will be treated |
| Statement of Applicability | Records necessary controls, inclusion and exclusion decisions and implementation status |
| Policies and Procedures | Explain how controls are governed and operated |
| Evidence | Demonstrates that controls are operating |
Can You Use an ISO 27001 SoA Template?
A template can save time when organising the SoA, but it should be adapted to the organisation’s actual circumstances.
What a template can help you organise
A useful template can provide space for:
- 93 Annex A controls
- Applicability
- Justifications
- Implementation status
- Control owners
- Evidence
- Risk references
Why a template cannot decide control applicability for you
Every organisation has a different scope, risk profile, technology environment and set of obligations.
A generic justification copied into an SoA may not accurately describe the organisation’s circumstances and can create inconsistencies during an audit.
What to check before using a 2022 SoA template
Check that the template includes:
- The correct 2022 Annex A structure
- All 93 controls
- Four control themes
- Space for additional necessary controls
- Inclusion and exclusion justifications
- Implementation status
- Document control information
Need Help Preparing Your ISO 27001 Statement of Applicability?
Preparing an audit-ready SoA requires clear control decisions, accurate risk links and suitable evidence. ISO Consultancy Oman can support organisations with the practical work involved in reviewing and documenting their ISMS controls.
For assistance with control applicability, risk treatment and SoA preparation, contact our team to discuss your requirements.
Email: info@finsoulnetwork.com
Conclusion
A Statement of Applicability is more than a list of Annex A controls. It shows how an organisation has considered its information security risks, selected necessary controls, justified its decisions and monitored implementation.
A strong SoA should remain consistent with the risk assessment, risk treatment plan, ISMS scope and available evidence. Organisations preparing for certification can work with ISO Consultancy Oman to strengthen their SoA and maintain clear documentation as their security environment changes.
Frequently Asked Questions
Is the Statement of Applicability mandatory under ISO 27001?
Yes. The SoA is a required part of an ISO 27001 compliant ISMS. It documents necessary controls and the organisation’s decisions concerning control applicability.
How many controls are in the ISO 27001:2022 SoA?
The ISO 27001:2022 Annex A reference set contains 93 controls grouped into four themes: organisational, people, physical and technological controls.
Do all 93 Annex A controls need to be implemented?
No. Organisations must consider the Annex A controls, but they do not automatically have to implement every control. Applicability depends on the organisation’s circumstances, risks and requirements.
Can an organisation exclude Annex A controls?
Yes. A control can be excluded when it is genuinely not necessary. The organisation should provide a clear justification that reflects its actual scope and circumstances.
What should be included in an ISO 27001 SoA?
The SoA should identify necessary controls, explain inclusion decisions, justify applicable exclusions, record implementation status and provide enough information to understand the control decisions and their relationship with the ISMS.