A Statement of Applicability (SoA) is a key document within an ISO 27001 Information Security Management System (ISMS) that records which information security controls are relevant to an organisation, whether they have been implemented, and why particular controls are included or excluded. It creates a clear link between information security risks, risk treatment decisions, and the controls used to manage those risks.
For organisations preparing for ISO 27001 certification or maintaining an existing ISMS, the Statement of Applicability provides an important summary of the security control environment. It allows auditors, management, and control owners to understand which controls apply, how they support the organisation’s risk treatment approach, and whether implementation remains aligned with current business, technology, and security requirements.
Why the Statement of Applicability Is Important
The Statement of Applicability is important because ISO 27001 does not require every organisation to implement every security control in exactly the same way. Controls should be selected according to the organisation’s risks, legal requirements, contractual obligations, operating environment, and information security objectives.
The SoA documents those decisions.
Key benefits of a Statement of Applicability include:
- Providing a clear record of applicable security controls
- Explaining why particular controls are included
- Documenting justified control exclusions
- Linking controls to information security risks
- Supporting ISO 27001 certification and surveillance audits
- Giving management visibility of the control environment
- Helping control owners understand their responsibilities
- Supporting consistent implementation of security measures
- Improving audit and evidence readiness
- Making changes to the ISMS easier to track
- Supporting continuous improvement of information security
- Providing a concise overview of risk treatment decisions
The Statement of Applicability also helps prevent an ISO 27001 programme from becoming a generic checklist exercise.
A business should not implement controls simply because they appear in a standard. It should understand why the control is relevant, what risk or requirement it addresses, and how it operates within the organisation.
For example, a security control may be applicable because the organisation processes sensitive client information, relies heavily on cloud infrastructure, or has contractual obligations requiring specific safeguards.
The SoA provides a structured place to document this reasoning.
How a Statement of Applicability Works
The Statement of Applicability is normally developed after the organisation has completed its information security risk assessment and determined how identified risks will be treated.
Risk assessment identifies what could go wrong and how serious the consequences could be. Risk treatment determines what the organisation will do about those risks. The SoA then records which controls support those decisions.
A typical Statement of Applicability process includes:
- Define the scope of the Information Security Management System.
- Identify information security risks.
- Assess the likelihood and impact of those risks.
- Determine appropriate risk treatment options.
- Review relevant ISO 27001 controls.
- Decide which controls are applicable.
- Document the justification for inclusion.
- Record any exclusions and explain why they are not applicable.
- Document the implementation status of each control.
- Assign ownership where appropriate.
- Maintain supporting evidence.
- Review the SoA when risks, technology, or business requirements change.
The organisation should also consider controls that may be required by legislation, regulations, client contracts, or other security standards.
This is important because the controls selected through risk treatment may not be the only controls the business needs.
For example, an organisation may determine that a particular control is required because of a customer contract even if the risk assessment alone would not have made it a priority.
The SoA should reflect the full security context of the organisation.
What a Statement of Applicability Contains
The exact format of a Statement of Applicability can vary, but it should provide enough information to explain the organisation’s control decisions clearly.
Control Reference
The SoA normally identifies each relevant ISO 27001 control using the appropriate control reference and title.
This makes it easier to connect the document with the standard, internal policies, risk treatment records, and audit evidence.
Applicability
Each control should normally be marked as applicable or not applicable.
A control is considered applicable when it is required to address identified risks, fulfil legal or contractual obligations, support security objectives, or satisfy another relevant requirement.
Justification for Inclusion
Applicable controls should have a clear reason for being included.
The justification may relate to:
- Information security risk
- Regulatory requirements
- Legal obligations
- Client contracts
- Internal security policy
- Business continuity requirements
- Supplier risk
- Operational resilience
- Industry expectations
The justification should be meaningful rather than simply stating that the control is required by ISO 27001.
Justification for Exclusion
If a control is considered not applicable, the organisation should explain why.
The exclusion should be reasonable and consistent with the ISMS scope and risk assessment.
A control should not be excluded simply because implementation is difficult or expensive. If the underlying risk or requirement exists, the organisation may still need an appropriate control.
Implementation Status
The Statement of Applicability should indicate whether each applicable control has been implemented.
Possible statuses may include:
- Implemented
- Partially implemented
- Planned
- Under review
- Not implemented
The terminology can vary, but it should provide an accurate picture of the current control environment.
Supporting Documentation
Many organisations also include references to supporting evidence or documentation, such as:
- Security policies
- Procedures
- Technical standards
- Risk treatment plans
- System configurations
- Access reviews
- Security reports
- Training records
- Supplier assessments
- Test results
This can make the SoA more useful during audits and internal reviews.
Common Statement of Applicability Challenges
The Statement of Applicability may appear straightforward, but organisations often encounter problems when building or maintaining it.
One common mistake is treating the SoA as a document that needs to be completed only to satisfy the certification auditor.
That approach can result in generic explanations, outdated implementation statuses, and weak links between controls and actual business risks.
Common Statement of Applicability challenges include:
- Controls selected without clear links to risk
- Generic justifications for control inclusion
- Weak or unsupported exclusion decisions
- Implementation status that is no longer accurate
- Controls marked as implemented without evidence
- Poor alignment between the SoA and risk treatment plan
- Inconsistent control naming across documents
- Unclear control ownership
- Policies that do not match the stated implementation
- Technology changes not reflected in the SoA
- Supplier changes not considered
- New legal or contractual requirements being missed
- The SoA being reviewed only before an audit
- Excessive focus on documentation rather than control effectiveness
A particularly important risk is marking a control as implemented when only part of the requirement has been addressed.
For example, an organisation may state that access control is implemented because it uses Multi-Factor Authentication. However, effective access management may also depend on joiner-mover-leaver processes, privileged access restrictions, periodic reviews, and account monitoring.
The SoA should reflect the real maturity of the control rather than an overly optimistic status.
Another challenge is maintaining consistency.
If the risk treatment plan says a control is required, but the Statement of Applicability marks it as excluded, the organisation needs to resolve the contradiction. Similar inconsistencies may appear between policies, technical configurations, audit evidence, and the SoA.
Best Practices for a Statement of Applicability
A good Statement of Applicability should be accurate, evidence-led, understandable, and actively maintained as part of the ISMS.
Best practices include:
- Building the SoA from the organisation’s risk assessment
- Keeping it aligned with the risk treatment plan
- Reviewing every relevant ISO 27001 control
- Writing clear and specific inclusion justifications
- Documenting exclusions carefully
- Avoiding unnecessary control exclusions
- Recording realistic implementation status
- Assigning ownership for applicable controls
- Linking controls to relevant policies and procedures
- Maintaining evidence of control implementation
- Reviewing the SoA after significant technology changes
- Updating it when suppliers or business processes change
- Reviewing legal and contractual requirements
- Checking consistency with audit findings
- Updating the SoA after remediation work
- Reviewing the document as part of normal ISMS governance
Organisations should also consider control effectiveness, not simply implementation status.
A control may be technically implemented but still perform poorly.
For example, backup procedures may exist and backup software may be configured, but if restoration has never been tested, the organisation may not have strong evidence that the control achieves its intended outcome.
Similarly, a vulnerability management control may be marked as implemented because regular scans occur. If critical vulnerabilities remain unresolved for long periods, the control may require improvement.
The SoA should therefore be supported by ongoing monitoring, testing, evidence review, and remediation.
It should also change as the organisation changes.
A new cloud platform, acquisition, regulatory obligation, supplier relationship, or business service can create new risks and make previously excluded controls relevant.
Maintaining the Statement of Applicability continuously helps ensure that it remains an accurate reflection of the current security environment rather than a historical certification document.
Conclusion: Why the Statement of Applicability Matters
The Statement of Applicability is one of the most important documents within an ISO 27001 Information Security Management System because it explains how the organisation has translated security risks and requirements into specific controls.
For organisations preparing for certification or maintaining an existing ISMS, the SoA provides auditors and management with a clear view of which controls apply, why they were selected, how they have been implemented, and where exclusions have been justified.
Its value depends on accuracy and continuous maintenance. Risks, systems, suppliers, and business requirements change over time, so the Statement of Applicability should evolve with them. When it remains aligned with risk treatment, supporting evidence, and real control performance, the SoA becomes more than an audit document. It becomes a practical record of how the organisation manages information security in a structured and accountable way.