Skip to main content
Bureau of AI
Category: Management System Governance

Statement of Applicability Documentation

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

A Statement of Applicability is a document used in information security management that lists the security controls an organization has considered and explains which ones apply to it and which do not, along with the reasoning for each decision. It is a central document in the ISO 27001 standard for information security management systems, where it is commonly described as a required part of certification. In practice, it serves as a record showing which controls the organization has chosen to implement and why others were left out.

Formal definition

Within the ISO/IEC 27001 Information Security Management System (ISMS) framework, the Statement of Applicability (SoA) is a document that enumerates the assessable information security controls (commonly the controls listed in Annex A) and records, for each, whether it is included or excluded, together with the justification for that determination. According to the evidence, one source characterizes it as a mandatory document covering the full set of Annex A controls; because control counts and Annex structure differ across editions (for example, the 2022 revision), practitioners should confirm the applicable version rather than assume a fixed number. The SoA is frequently identified as one of the core documents required for ISO 27001 certification, functioning as the auditable link between an organization's risk assessment and its implemented control set. Note: this evidence packet addresses the SoA specifically as an ISO 27001 ISMS artifact and does not establish its use, definition, or requirement status under other frameworks (such as AI-specific standards or model risk management guidance).

Why it matters

The Statement of Applicability sits at the heart of an ISO/IEC 27001 Information Security Management System because it is the auditable record that connects an organization's risk assessment to the specific controls it has chosen to implement or exclude. Without it, an auditor cannot readily verify that control decisions were made deliberately and with justification rather than left to chance. For this reason, several sources describe the SoA as one of the core documents required for ISO 27001 certification, and one source characterizes it as a mandatory document covering the full set of Annex A controls.

The document matters most as evidence of reasoned decision-making. Because it requires the organization to state, for each assessable control, whether the control applies and why, the SoA forces explicit accountability for both inclusions and exclusions. This makes it a focal point during certification and surveillance audits, where the justifications recorded in the SoA can be tested against the underlying risk assessment and the controls actually operating in the environment.

A common pitfall is treating the SoA as a static checklist rather than a living document tied to risk. Control counts and Annex structure differ across editions of the standard—for example, one source references 93 Annex A controls—so practitioners should confirm the applicable version and control set rather than assume a fixed number. This evidence addresses the SoA specifically as an ISO 27001 ISMS artifact; it does not establish the document's meaning or requirement status under other frameworks, such as AI-specific standards or model risk management guidance.

Who it's relevant to

Information Security and Compliance Officers
Those responsible for establishing or maintaining an ISO 27001 ISMS rely on the SoA as a core, often-described-as-mandatory document. They own the process of listing the assessable controls, recording inclusion and exclusion decisions, and documenting the justification for each based on the organization's risk assessment.
Auditors and Certification Assessors
Because the SoA is identified as one of the core documents required for ISO 27001 certification, auditors use it to verify that control decisions were deliberate and justified. They test the recorded justifications against the risk assessment and the controls operating in the environment.
Risk Management Practitioners
Practitioners connecting risk assessment outputs to control decisions use the SoA as the traceable link between identified risks and the implemented control set. They should confirm the applicable edition of the standard, since control counts and Annex structure differ across versions rather than being fixed.
Professionals Working Across Frameworks
Those applying multiple standards should note that this evidence addresses the SoA specifically as an ISO 27001 ISMS artifact. It does not establish the document's use, definition, or requirement status under other frameworks such as AI-specific standards or model risk management guidance, and the concept should not be assumed to transfer without confirmation.

Inside SoA

Control Inclusion and Exclusion Register
A structured listing of the controls considered for the management system, indicating for each whether it is applicable or excluded. In the context of ISO/IEC 42001, a Statement of Applicability (SoA) typically maps controls from the standard's annex against the organization's AI management system scope. The register is the core function of the document.
Justification for Each Determination
A recorded rationale explaining why each control is included or excluded. Exclusions in particular are expected to carry a documented reason so that auditors and reviewers can assess whether the decision is defensible relative to the organization's identified risks and obligations.
Implementation Status
An indication of whether an applicable control is implemented, partially implemented, or planned. This distinguishes a control being deemed relevant from the control actually being operational, which is a distinction practitioners should preserve.
Linkage to Risk Assessment and Treatment
References connecting each control decision to the underlying risk assessment or risk treatment outputs, showing that inclusion and exclusion choices are traceable to identified risks rather than made in isolation.
Scope Reference
A statement or cross-reference identifying the boundaries of the management system to which the applicability determinations apply, since a control's relevance is meaningful only relative to a defined scope.
Version and Ownership Metadata
Document control information such as version, approval, and ownership, so the SoA can be maintained as a living record that is reviewed and updated as the system and its risk profile change.

Common questions

Answers to the questions practitioners most commonly ask about SoA.

Is a Statement of Applicability the same thing as an AI governance policy or risk register?
No. As commonly used in management-system standards such as ISO/IEC 42001, a Statement of Applicability is a specific document that records which controls from a reference set are applicable to the organization, the justification for inclusion or exclusion, and their implementation status. It is not itself a governance policy (which sets organizational direction and accountability) nor a risk register (which catalogs identified risks and their treatment). Professionals frequently blur these because the documents cross-reference one another, but they serve distinct functions and should not be treated as interchangeable.
Does completing a Statement of Applicability mean an organization is compliant or certified?
Not on its own. The document records decisions about which controls apply and their justification; it does not by itself demonstrate that those controls are operating effectively, nor does it confer certification. Certification, where applicable, typically involves independent assessment against the relevant standard. The Statement of Applicability is an input to and evidence within such processes rather than proof of compliance, and its scope is limited to documenting applicability decisions rather than verifying outcomes.
Who is typically responsible for maintaining the Statement of Applicability?
Responsibility varies by organization and is not fixed by any single standard. In many implementations, ownership sits with a function accountable for the management system as a whole, drawing on input from control owners across relevant business and technical areas. Under a lines-of-defense model, the first line often provides implementation detail while a second-line function may coordinate and review the document, but organizations should assign ownership explicitly rather than assume a default.
How often should a Statement of Applicability be reviewed or updated?
Review frequency is generally driven by the pace of change in scope, risks, controls, and the reference framework rather than by a universally mandated interval. Common triggers include changes to the systems or processes in scope, adoption or retirement of controls, findings from audits or assessments, and revisions to the underlying standard. Many organizations also conduct periodic reviews on a defined cycle, but the appropriate cadence should be set to the organization's context.
What should a justification for excluding a control typically contain?
Exclusion justifications are commonly expected to explain why a control is not applicable to the defined scope, rather than simply stating that it is out of scope. A justification typically references the reasoning, such as the absence of the relevant activity, asset, or risk within scope. The level of detail expected can vary by framework and by assessor, so organizations should confirm expectations against the specific standard and, where relevant, the certification body they are working with.
How does the Statement of Applicability relate to other governance and risk documentation?
It typically sits alongside, and cross-references, documents such as policies, risk assessments, risk treatment plans, and control implementation evidence. The Statement of Applicability records applicability and justification decisions, while those linked documents carry the underlying risk analysis and the operational detail. Maintaining clear traceability between them helps avoid inconsistencies, but the boundaries between these documents differ across organizations and frameworks and should be defined explicitly rather than assumed.

Common misconceptions

A Statement of Applicability is the same as an AI governance policy or overall risk management framework.
The SoA is a specific bridging artifact that records which controls apply and why; it does not itself constitute the organization's governance structures or its risk identification, measurement, and monitoring processes. It typically references those broader efforts rather than replacing them, and the distinction between governance structures and risk management activities still holds.
Marking a control as applicable in the SoA means the control is already in place and effective.
Applicability and implementation are separate. A control can be deemed applicable while remaining planned or only partially implemented. The SoA commonly records implementation status precisely because relevance does not equal operational effectiveness, and documenting a control does not by itself reduce risk.
A Statement of Applicability is a universally required document across all AI regulatory frameworks.
The SoA is most closely associated with management-system standards such as ISO/IEC 42001, which is a voluntary standard rather than binding law. Other instruments and frameworks address AI oversight differently and do not necessarily use or require this specific artifact, so its role should not be assumed to be interchangeable across regimes.

Best practices

Record an explicit justification for every control determination, giving particular attention to exclusions so that each decision is defensible and traceable during review or audit.
Maintain a clear cross-reference between each control decision and the underlying risk assessment and risk treatment outputs, so applicability choices remain grounded in identified risks rather than made in isolation.
Track implementation status separately from applicability, distinguishing controls that are deemed relevant from those that are actually operational.
Anchor the document to a clearly stated management-system scope, since a control's relevance is only meaningful relative to defined boundaries.
Treat the Statement of Applicability as a living document with version control and defined ownership, updating it as the system, its scope, or its risk profile changes.
Avoid presenting the Statement of Applicability as a substitute for broader governance policies or risk management processes; use it as a reference point that links to those efforts.