Skip to main content
Digital Compliance Bureau
Promotional banner for the pentest readiness checklist
Category: Governance & Controls

Statement of Applicability

Also known as: SoA, ISO 27001 Statement of Applicability, SOA
Simply put

A Statement of Applicability (SoA) is a core document used when building an information security management system under the ISO/IEC 27001 standard. It records which security controls an organization has decided are relevant, which it has excluded, and the reasoning behind each decision. Note that ISO/IEC 27001 is a voluntary standard rather than a law, though organizations may be required to follow it by contract or as a step toward certification.

Formal definition

The Statement of Applicability (SoA) is a mandatory document within an ISO/IEC 27001 Information Security Management System (ISMS) that identifies the information security controls selected by the organization, justifies their inclusion or exclusion, and links them to the results of risk treatment decisions. It functions as a central reference mapping applicable controls to the organization's security posture and is generally required for those pursuing ISO/IEC 27001 certification. The SoA reflects a voluntary or contractual obligation under the standard rather than a statutory requirement, and its specific content and format depend on the version of ISO/IEC 27001 in force (for example, the controls set in the 2022 revision); readers should verify requirements against the current official ISO/IEC text and applicable certification scheme.

Why it matters

The Statement of Applicability sits at the heart of an ISO/IEC 27001 Information Security Management System because it is where an organization's abstract risk decisions become a documented, auditable record. Rather than simply asserting that controls are in place, the SoA obliges the organization to state explicitly which controls it has selected, which it has excluded, and the justification for each choice. For anyone pursuing ISO/IEC 27001 certification, this is a mandatory document, and certification auditors typically use it as a primary reference point when checking whether the ISMS as described matches the controls actually implemented.

The SoA matters because it links risk treatment decisions to concrete controls in a single traceable place. Gaps, unsupported exclusions, or inconsistencies between the SoA and operational reality are among the issues an auditor is likely to scrutinize. Because ISO/IEC 27001 is a voluntary standard rather than a statutory requirement, the obligation to maintain an SoA generally arises from the pursuit of certification or from contractual commitments to customers or partners, not from law. Organizations should treat it as a living document that reflects their current security posture rather than a one-time compliance artifact.

Readers should note that the specific control set an SoA references depends on the version of ISO/IEC 27001 in force, and the standard is periodically revised. The content, expected format, and the way certification bodies assess an SoA can therefore change over time, and requirements should be verified against the current official ISO/IEC text and the applicable certification scheme rather than assumed to be fixed.

Who it's relevant to

Information security managers and ISMS owners
Those responsible for building and maintaining an ISO/IEC 27001 ISMS rely on the SoA to document control selection, justify inclusions and exclusions, and keep the record aligned with risk treatment decisions. For them it is a mandatory, living document rather than a one-off deliverable.
Certification auditors and assessors
Auditors evaluating an organization against ISO/IEC 27001 typically use the SoA as a primary reference to check that the controls described match those actually implemented. Note the distinction between assessment against the standard and formal certification, which is granted by an accredited certification body.
Compliance and risk officers
Professionals managing an organization's compliance posture use the SoA to demonstrate a traceable link between identified risks and the controls chosen to address them. This is particularly relevant where ISO/IEC 27001 alignment is a contractual commitment to customers or partners rather than a legal obligation.
Vendors and organizations pursuing certification
Any organization planning to pursue ISO/IEC 27001 certification must develop an SoA, as it is a mandatory step. Vendors seeking to reassure clients of their security practices often prepare an SoA as part of demonstrating a mature, documented approach to information security.

Inside SoA

List of Applicable Controls
An enumeration of the controls the organization has determined to be relevant to its information security management system, typically drawn from the reference control set in ISO/IEC 27001 Annex A. Note that the current version of the standard should be consulted, as the control set has been revised over time.
Inclusion and Exclusion Decisions
For each control, a clear indication of whether it is applicable and included or excluded, together with the justification for that decision. Exclusions must be reasoned rather than arbitrary.
Justification for Inclusion or Exclusion
The rationale linking each control decision to risk assessment outcomes, legal, regulatory, or contractual requirements, and business needs. This traceability is central to the document's purpose.
Implementation Status
An indication of whether each applicable control is implemented, partially implemented, or planned, providing a snapshot of the current state of the control environment.
Reference to Risk Treatment
A connection between selected controls and the risk treatment plan and risk assessment results, showing how the chosen controls address identified risks.

Common questions

Answers to the questions practitioners most commonly ask about SoA.

Is the Statement of Applicability the same thing as a risk assessment or risk treatment plan?
No. These are distinct documents that work together within an ISO/IEC 27001 information security management system. A risk assessment identifies and analyzes risks, and a risk treatment plan describes how identified risks will be addressed, including timelines and responsibilities. The Statement of Applicability (SoA) is the document that lists the controls the organization has determined to be applicable, states whether each is included or excluded, and provides justification for those decisions. The SoA generally draws on the outputs of the risk assessment and treatment process, but it is not a substitute for them. Readers should verify the specific documentation requirements against the current text of ISO/IEC 27001.
Does having a Statement of Applicability mean an organization is certified to ISO/IEC 27001?
No. The SoA is a required document within an ISO/IEC 27001 management system, but its existence does not by itself confer certification. ISO/IEC 27001 is a voluntary standard, and certification against it is achieved through an audit conducted by an accredited certification body, not by the organization producing documents on its own. The SoA is one of the artifacts a certification auditor would typically examine, but compliance with the standard and formal certification are separate matters. Certification schemes and standard versions change over time, so verify current requirements against the authoritative source.
What information does a Statement of Applicability generally need to contain?
An SoA typically identifies each control the organization has considered, indicates whether the control is applicable or has been excluded, records the justification for inclusion or exclusion, and notes the implementation status of applicable controls. The precise content and format are not rigidly prescribed, so organizations often adapt the structure to their context. Because documentation expectations can shift between versions of the standard, confirm the current requirements against the latest official text of ISO/IEC 27001.
How should an organization justify excluding a control in its Statement of Applicability?
Exclusions should generally be supported by a clear, documented rationale that connects the decision to the organization's risk assessment, scope, and business context. For example, a control may be excluded where it is not relevant to the defined scope of the management system. The justification should be specific enough to withstand scrutiny during an audit rather than stated in generic terms. Because the appropriateness of any exclusion is fact-specific and depends on the organization's circumstances, applying this to a particular situation requires professional judgment.
How often should the Statement of Applicability be reviewed or updated?
The SoA is generally treated as a living document that should be kept current as the organization's risk profile, scope, controls, or environment change. In most cases it is reviewed during periodic management reviews, following significant changes, and in connection with audit cycles. There is no single universal frequency that applies to all organizations; the review cadence typically aligns with the organization's broader management system processes. Verify any specific expectations against the current standard and your certification body's requirements.
Who within an organization is typically responsible for maintaining the Statement of Applicability?
Responsibility commonly sits with the individuals or team accountable for the information security management system, such as an information security manager or an ISMS owner, often working with control owners across the business. Because the SoA reflects decisions about applicable controls and their justification, its maintenance generally requires input from those who understand both the risk assessment outputs and the operational implementation of controls. The specific allocation of roles depends on organizational structure and should be defined within the management system itself.

Common misconceptions

A Statement of Applicability is itself a certification or proof of compliance.
The Statement of Applicability is a documented artifact of an ISO/IEC 27001-based information security management system, not a certificate. Certification, where pursued, is issued by an accredited certification body following an audit; the SoA is one of the documents that supports, but does not constitute, that outcome. ISO/IEC 27001 is a voluntary standard unless made mandatory by contract or law.
The Statement of Applicability must include every control in the reference set as implemented.
Controls may be excluded where a documented justification supports the exclusion. What the standard generally expects is a reasoned decision and justification for each control, not blanket inclusion. Exclusions should be tied to risk assessment results and applicable requirements.
Once produced, the Statement of Applicability is a static, one-time document.
The SoA is intended to reflect the current state of control selection and implementation, which changes as risks, business context, and the standard itself evolve. It generally requires periodic review and updating, and readers should verify content against the latest risk assessment and the current version of the standard.

Best practices

Maintain clear traceability between each control decision and the underlying risk assessment and risk treatment plan, so that inclusions and exclusions can be justified during an audit or assessment.
Document a specific justification for every exclusion rather than leaving controls unaddressed, referencing the relevant risk, legal, regulatory, or contractual basis.
Record implementation status for each applicable control and keep it current, distinguishing between implemented, partially implemented, and planned controls.
Review and update the Statement of Applicability periodically and after significant changes to risks, business context, or the applicable version of the standard.
Confirm that the control set referenced aligns with the current version of ISO/IEC 27001, as the reference controls have been revised over time.
Treat the Statement of Applicability as an internal management artifact and involve appropriate risk, security, and business stakeholders, seeking professional judgment for application to specific circumstances.
Digital advertisement promoting the whitepaper “The State of Application Security in Modern Software,” showing the cover f the whitepaper and text highlighting AppSec risks, AI code threats, API vulnerabilities, and a button to download the whitepaper.