Skip to main content
Cyber Risk Council
Category: Security Policies & Standards

Statement of Applicability (SoA)

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

A Statement of Applicability (SoA) is a required document in the ISO 27001 information security management system standard that lists the security controls an organization has considered, indicates which ones it applies, and explains why any are excluded. It serves as the connecting document between an organization's risk assessment and how it decides to treat those risks. Organizations pursuing ISO 27001 certification are typically required to produce and maintain this document.

Formal definition

The SoA is a mandatory ISO 27001 document that enumerates the Annex A controls (93 controls in the current version referenced in the evidence), records the implementation status of each (implemented or excluded), and provides justification for inclusion or exclusion. It functions as the primary link between the outputs of risk assessment and the risk treatment decisions within an Information Security Management System (ISMS), demonstrating how selected controls map to identified risks. In practice, a virtual CISO may support the development and maintenance of the SoA as part of ISO 27001 readiness work, but producing an accurate SoA depends on client cooperation, organizational context, and completed risk assessment activities; the SoA itself supports certification readiness and does not, on its own, constitute or guarantee certification, which is determined by an accredited certification body.

Why it matters

The Statement of Applicability is often described as the central document of an ISO 27001 Information Security Management System because it is where risk decisions become visible and auditable. It connects the outputs of an organization's risk assessment to the specific controls chosen to treat those risks, and it records which Annex A controls are applied, which are excluded, and the reasoning behind each decision. Without a coherent SoA, an ISMS can appear to be a collection of disconnected policies rather than a deliberate, risk-driven program, which is precisely what an accredited certification body will scrutinize.

For organizations pursuing ISO 27001 certification, the SoA is a mandatory document, not an optional artifact. It gives auditors, leadership, and other stakeholders a single reference point to understand how the organization has interpreted its risk landscape and what it has decided to do about it. Because the justifications for inclusion and exclusion are recorded, the SoA also creates accountability: a decision to exclude a control must be explained rather than left implicit, which discourages gaps from being quietly ignored.

It is important to be precise about what the SoA does and does not accomplish. Producing an SoA supports certification readiness; it does not, on its own, constitute or guarantee certification, which is determined by an accredited certification body. Its value also depends heavily on the quality of the underlying risk assessment and on organizational cooperation. An SoA built on an incomplete or superficial risk assessment will document decisions that may not withstand audit scrutiny, so the document should be treated as the output of sound governance work rather than a box-checking exercise completed in isolation.

Who it's relevant to

Organizations pursuing ISO 27001 certification
For any organization planning to pursue ISO 27001 certification, the SoA is a mandatory document. It is one of the artifacts an accredited certification body will expect to review, and its clarity and consistency with the underlying risk assessment can shape how smoothly an audit proceeds. Leadership should understand that the SoA reflects governance decisions and that legal and organizational accountability for those decisions typically remains with the client organization and its officers.
Security and compliance leaders managing an ISMS
Those responsible for operating an Information Security Management System use the SoA as a working reference that links identified risks to selected controls and documents any exclusions with justification. Because it is intended to be maintained over time, it is most useful to leaders who treat it as an ongoing governance record rather than a one-time deliverable. Its accuracy depends on a completed and credible risk assessment.
Virtual CISOs supporting ISO 27001 readiness
A virtual CISO may support the development and maintenance of the SoA as part of ISO 27001 readiness work, providing strategy, governance, and program-level guidance. This support depends on client cooperation, organizational context, and completed risk assessment activities. It is worth being clear that this readiness work supports certification but does not by itself constitute or guarantee certification, and the vCISO generally advises and directs rather than assuming accountability for security decisions.
Buyers evaluating vCISO or advisory engagements
Organizations engaging a virtual, fractional, or advisory CISO for ISO 27001 support should understand where SoA development fits in scope. Producing an SoA is governance and program work that flows from a risk assessment, not hands-on operational tool administration, and its quality depends on stakeholder access and organizational maturity. Buyers should confirm what is included in a given engagement and recognize that certification itself is determined by an accredited certification body.

Inside SoA

Control Reference and Set
A listing of the controls under consideration, typically drawn from the ISO/IEC 27001 Annex A control set (or another defined reference), each identified so it can be traced back to the source framework.
Applicability Determination
An explicit statement of whether each control is applicable or not applicable to the organization's information security management system, reflecting decisions made during risk treatment.
Justification for Inclusion
The rationale for why each applicable control has been selected, often tied to risk assessment results, contractual or legal obligations, or business requirements.
Justification for Exclusion
The reasoning for why a control has been deemed not applicable, which is important for demonstrating that exclusions were deliberate rather than overlooked.
Implementation Status
An indication of whether each applicable control is currently implemented, partially implemented, or planned, which may vary depending on how the organization structures its documentation.

Common questions

Answers to the questions practitioners most commonly ask about SoA.

Is the Statement of Applicability just a list of the controls we've implemented?
No, that is a common misconception. The SoA is not simply an inventory of implemented controls. It documents all controls considered (typically the full control set from a framework such as ISO 27001 Annex A), states which are applicable and which are excluded, gives the justification for each inclusion or exclusion, and indicates implementation status. A control can be listed as applicable but not yet fully implemented, and controls may be excluded with documented rationale. Treating it as only a checklist of what is done misses its core purpose as a reasoned, auditable record of decisions.
Does having a completed SoA mean we are ISO 27001 certified?
No. The SoA is a mandatory document within an ISO 27001 information security management system, but producing one does not confer certification. Certification requires a successful audit by an accredited certification body assessing the whole management system, of which the SoA is one input. A virtual CISO engagement can support readiness by helping develop and maintain the SoA, but preparing the document is distinct from achieving certification. Confusing the artifact with the outcome is an error an experienced auditor would correct.
Who should own and maintain the SoA within our organization?
Ownership typically sits with the party accountable for the information security management system, often a security leader or governance function, with input from control owners across the business. A virtual CISO frequently advises on and helps draft or review the SoA, but accountability for its accuracy and for the underlying security decisions generally remains with the client organization and its officers. Because the SoA references controls owned by different teams, maintenance usually depends on cooperation across stakeholders rather than a single individual working in isolation.
How often should the SoA be reviewed and updated?
Practice varies by provider and organization, but the SoA is generally treated as a living document rather than a one-time deliverable. It is often reviewed when there are material changes such as a shift in scope, new risks identified during risk assessment, changes to controls, organizational restructuring, or in preparation for audits and surveillance activities. Many engagements also align SoA review with the periodic risk assessment and management review cycles of the management system. The appropriate cadence depends on organizational maturity and the pace of change in the environment.
How does the SoA relate to the risk assessment and risk treatment plan?
The SoA is typically the output that connects risk decisions to controls. In many implementations, the risk assessment identifies risks, the risk treatment plan decides how each will be addressed, and the SoA records which controls are applicable as a result, along with justifications for inclusion or exclusion and their implementation status. Because of this dependency, an SoA developed without a corresponding risk assessment often lacks defensible justification. Ensuring these documents remain consistent is a common area where a virtual CISO provides governance guidance.
What should the justification for excluding a control actually contain?
Exclusions generally need a documented, defensible rationale rather than a blanket statement. Justifications often reference why the control does not apply given the defined scope, the nature of the organization's activities, or the results of the risk assessment. The reasoning should be specific enough to withstand scrutiny from an auditor, who will typically question exclusions that appear to sidestep relevant risks. The strength of these justifications depends on a clearly defined scope and a completed risk assessment, and getting them right is often where advisory input from a security leader adds value.

Common misconceptions

A Statement of Applicability is a technical configuration document that describes how security tools are set up.
The SoA is a governance and documentation artifact that records which controls apply and why, along with their justification and status. It is a management-level record supporting the information security management system, not a technical build or configuration guide. A virtual CISO typically advises on and helps shape this governance document rather than performing hands-on tool administration.
Completing a Statement of Applicability means the organization is certified or automatically compliant with ISO/IEC 27001.
The SoA is one required element supporting an ISO/IEC 27001 management system, but its existence does not by itself confer certification. Certification is granted by an accredited certification body following an audit. A vCISO engagement can support readiness and help prepare the SoA, but it does not guarantee certification or a specific audit outcome.
A virtual CISO who prepares the SoA assumes accountability for the security control decisions it records.
A vCISO typically advises on and helps draft the SoA and its justifications, but legal and organizational accountability for the control decisions generally remains with the client organization and its officers unless a contract specifies otherwise. The document reflects management's decisions, which the client is responsible for approving.

Best practices

Tie each control's inclusion or exclusion justification directly to documented risk assessment and risk treatment results so the SoA remains traceable and defensible during review.
Record justifications for exclusions with the same rigor as inclusions, so that not-applicable determinations are clearly deliberate rather than appearing to be oversights.
Keep the SoA aligned with the current control reference set and update it as the risk environment, business requirements, or contractual and legal obligations change.
Clarify engagement scope up front regarding whether the vCISO is drafting, advising on, or reviewing the SoA, and confirm that final approval and accountability rest with the client's designated officers.
Distinguish clearly between preparing the SoA to support certification readiness and asserting that certification has been achieved, and communicate this distinction to stakeholders.
Recognize that the quality and completeness of the SoA depend on organizational maturity, stakeholder cooperation, and access to accurate risk and implementation-status information.