When an organization pursues ISO 27001 certification, it must produce one document before the auditor can evaluate anything else. That document is the ISO 27001 Statement of Applicability. Without it, the certification process cannot proceed. With a weak version of it, the certification process frequently stalls.

The ISO 27001 Statement of Applicability is the document that defines which of the 93 Annex A security controls apply to an organization's Information Security Management System, which do not, and why those decisions were made. It is mandatory under Clause 6.1.3 of the standard, and it serves as the auditor's primary reference point throughout both Stage 1 document review and Stage 2 evidence testing.

Most organizations understand that the SOA must exist. Fewer understand what makes one defensible. A document that simply marks controls as applicable or not applicable, without tracing those decisions to a completed risk assessment and documented business context, does not meet the standard's intent — and experienced auditors identify this quickly.

This guide explains what the ISO 27001 Statement of Applicability requires, what it must contain, how to structure inclusions and exclusions that auditors will accept, and how business leaders can ensure the document reflects genuine governance rather than a compliance exercise.

Schedule a Meeting with CertPro
TL;DR

Concern

Many organizations treat the ISO 27001 Statement of Applicability as a documentation formality — a spreadsheet populated during implementation and filed away until the next audit. This approach consistently produces SOA documents that fail Stage 1 review, require significant remediation, or result in audit findings related to insufficient justification, missing risk linkages, or outdated control status. The SOA is the central argument of the ISMS, and it must be treated as one.

Overview

The ISO 27001 Statement of Applicability must address all 93 Annex A controls, document whether each is applicable or excluded, provide specific justification for each decision, record the implementation status of applicable controls, and reference supporting policies or procedures where they exist. Under ISO 27001:2022, the controls are organized into four categories: Organizational, People, Physical, and Technological. The document must be reviewed at least annually and updated whenever the organization's risk profile, operations, or control environment changes materially.

Solution

The ISO 27001 Statement of Applicability should be built after — not during — the risk assessment and risk treatment planning process. Justifications for inclusion must trace directly to identified risks. Justifications for exclusion must be specific, credible, and free of cost or convenience rationales. When the SOA is built and maintained as a living governance document rather than a one-time artifact, it accelerates certification audits, strengthens the ISMS, and provides a credible reference for customers, auditors, and enterprise buyers.

What Is the ISO 27001 Statement of Applicability and Why It Matters

The Statement of Applicability ISO 27001 requires is not simply a list of controls an organization has decided to implement. It is a formal governance document that records why each security control was selected or excluded from the ISMS. Clause 6.1.3(d) of the ISO 27001 standard explicitly requires organizations to produce this document as part of their risk treatment process — it cannot be substituted by a risk register, a policy library, or an auditor's interview with management.

The ISO 27001 Statement of Applicability serves four distinct purposes within the ISMS. First, it records the outcome of the risk treatment process, showing which controls were selected in response to which identified risks. Second, it documents the organization's considered decision to exclude controls from Annex A where those controls are not relevant, along with the specific reason for that exclusion. Third, it provides the auditor with a traceable map of the organization's security posture — the document they use to follow controls to evidence during certification testing. Fourth, it functions as an ongoing governance reference for internal stakeholders, customers, and external assurance programs.

The ISO 27001 SOA is also a legally significant document in the context of the certification. The version number and date on the SOA must match the version referenced on the ISO 27001 certificate itself. When a customer or enterprise buyer requests the SOA as part of vendor due diligence, they expect to see a document whose version aligns with the current certificate period — and any mismatch creates questions about whether the ISMS is actively maintained.

The SOA in Context: Where It Sits Within the ISMS

The Statement of Applicability ISO 27001 certification requires is produced after the risk assessment and risk treatment plan are complete. Organizations that begin building the SOA before finishing those steps typically produce a document that looks comprehensive on paper but fails under scrutiny because the control selections cannot be traced to documented risks. The SOA is the output of a governance process — it cannot be produced before that process has run.

What the SOA Document Must Contain

The SOA document requirements under ISO 27001:2022 are defined in Clause 6.1.3. A compliant SOA document must include four mandatory elements for every Annex A control. First, a declaration of whether the control is applicable to the organization. Second, a justification for the inclusion of controls that are applicable, tracing the selection to identified risks, legal obligations, contractual requirements, or recognized best practice. Third, the current implementation status of each applicable control, distinguishing between controls that are fully implemented, partially implemented, or planned. Fourth, a justification for the exclusion of controls from Annex A that are determined not to be applicable, with specific and credible reasons.

The ISO 27001 SOA must address all 93 Annex A controls from the 2022 version of the standard. These controls are organized into four thematic categories, each reflecting a distinct dimension of information security governance:

  • Annex A.5 Organizational (37 controls): Covers policy frameworks, roles and responsibilities, asset management, access control governance, supplier relationships, incident management, and business continuity planning.
  • Annex A.6 People (8 controls): Addresses how employees and contractors interact with information assets, including pre-employment screening, security awareness training, remote working policies, and responsibilities upon termination.
  • Annex A.7 Physical (14 controls): Governs the protection of physical environments, entry controls, equipment security, and the management of physical media — applicable to organizations with office locations, data centers, or physical infrastructure in scope.
  • Annex A.8 Technological (34 controls): Covers user endpoint management, privileged access management, application security, cryptographic controls, vulnerability management, logging, monitoring, and web filtering.

A well-structured SOA document also includes supporting elements that strengthen its usability and audit defensibility: a version history tracking all changes with dates and approvers; a reference column linking each applicable control to the policy, procedure, or technical documentation that governs its implementation; a control owner field identifying the individual responsible for each applicable control's operation; and a management approval record confirming the document has been reviewed and authorized. The ISO 27001 Statement of Applicability should be treated as a confidential governance document given the sensitivity of the control environment it describes.

What the SOA Is Not

The SOA is not a risk register, though it draws from one. It is not a policy library, though it references one. It is not a controls checklist that can be populated by reviewing templates from other organizations. The ISO 27001 Statement of Applicability must reflect the organization's specific context, risk assessment outcomes, and operational environment. Each of the 93 controls must be evaluated against these factors individually. A document that applies another organization's exclusion justifications to a different business is a document that will fail at Stage 1.

How the ISO 27001 Statement of Applicability Connects to the ISMS

The ISO 27001 Statement of Applicability sits at the intersection of three critical ISMS components: the risk assessment, the risk treatment plan, and the implemented security controls. This connection — often described by auditors as the golden thread — is what distinguishes a credible ISMS from a documentation exercise. The risk assessment identifies threats and vulnerabilities. The risk treatment plan decides how each risk will be addressed. The SOA records which Annex A controls were selected to implement those treatment decisions, and why.

Inclusion Justifications: Tracing Controls to Risks

Every control marked as applicable in the SOA must have an inclusion justification that is specific and traceable. Acceptable reasons for inclusion include the need to address a specific identified risk, a legal or regulatory obligation that requires the control, a contractual commitment to a customer or business partner, or a recognized best practice that the organization has independently determined to be relevant. Vague justifications such as "required for security" or "industry standard" do not satisfy the ISO 27001 Statement of Applicability requirements under Clause 6.1.3 and will draw auditor attention to whether the risk assessment process was genuinely conducted.

Exclusion Justifications: What Auditors Will Accept and What They Will Not

Every control marked as not applicable must have an exclusion justification that is specific, credible, and connected to the organization's actual context. Acceptable exclusion reasons include: the risk the control addresses does not exist in the organization's environment; the control applies to a process or asset that is outside the defined ISMS scope; a complementary control from another source already addresses the same risk more effectively; or the activity the control covers is not performed by the organization. Unacceptable exclusion justifications — those auditors consistently reject — include cost, resource constraints, lack of time, "no one has asked for it," or any justification that effectively amounts to a decision to accept the risk without documenting that decision in the risk register.

When an exclusion is granted because a particular activity is not performed by the organization, the ISO 27001 Statement of Applicability must be consistent with the ISMS scope document and the system description. If the SOA excludes physical security controls on the basis that the organization is fully cloud-based, the ISMS scope must confirm that no physical infrastructure is in scope. Contradictions between the SOA and the scope document are among the most common Stage 1 findings.

ISO 27001 Statement of Applicability Example: Inclusion, Exclusion, and What to Avoid

ISO 27001 Statement of Applicability Example: Inclusion, Exclusion, and What to Avoid
ISO 27001 Statement of Applicability Example: Inclusion, Exclusion, and What to Avoid

An ISO 27001 statement of applicability example illustrates the difference between justifications that hold up under audit scrutiny and those that do not. The following examples reflect the quality standard auditors apply during ISO 27001 certification reviews.

  • Inclusion Justification

    The risk assessment identified unauthorized access to administrative accounts as a high-severity risk (Risk ID R-014). This control directly addresses that risk by requiring elevated access requests to follow a formal approval process, use of just-in-time provisioning, and logging of all privileged session activity. Implementation status: Fully implemented. Reference: Privileged Access Management Policy v2.3 and the Identity and Access Management Procedure.

  • Exclusion Justification

    The organization operates entirely in a cloud environment. No physical servers, data centers, or office-based processing infrastructure are in scope for this ISMS. Physical security is the responsibility of the IaaS provider, confirmed through their current ISO 27001 certificate (AWS Certification Reference AW-2026-ISO-001). This exclusion is consistent with the ISMS Scope Document v3.1.

  • Poor Justification: What to Avoid

    A poor justification in an ISO 27001 Statement of Applicability is marking a control as "Not Applicable" simply because the organization does not have time to implement it. This is not a valid reason. Lack of time or resources does not make a control inapplicable. An auditor will expect the related risk to be formally assessed and addressed. The Statement of Applicability should always reflect risk-based decisions, not implementation delays.

  • Implementation Status: Avoiding Mismatches

    Another frequent issue visible in any ISO 27001 statement of applicability example review is the mismatch between declared implementation status and actual operational reality. An SOA that lists a control as fully implemented when the supporting policy does not exist, or when the procedure is a draft not yet approved by management, will fail the Stage 2 evidence test. The implementation status column must reflect the control's actual operating state at the time of the audit — not the intended state after a future project is completed.

How Auditors Use the SOA During ISO 27001 Certification

During an ISO 27001 certification audit, the ISO 27001 Statement of Applicability is the first substantive document the auditor examines — and it shapes the entire audit that follows. The auditor uses it as a map: it tells them which controls the organization claims to have implemented, what justification exists for each decision, and where the evidence of implementation should be found.

Stage 1: Document Review

At Stage 1, the ISO 27001 SOA is reviewed for completeness and consistency. The auditor verifies that all 93 Annex A controls are addressed, that inclusion justifications trace to the risk assessment, that exclusion justifications are specific and credible, and that the document is approved by management and version-controlled. Stage 1 findings related to the SOA — such as generic justifications, missing controls, or inconsistency with the scope document — must be resolved before Stage 2 can proceed. In practice, a weak SOA discovered at Stage 1 often signals deeper gaps in the risk assessment and ISMS design.

Stage 2: Evidence Testing

At Stage 2, the auditor uses the ISO 27001 Statement of Applicability as the reference against which evidence is tested. For every control marked as applicable and implemented, the auditor will request evidence that the control is operating as described. If the SOA references a policy document, that document must exist, be current, and reflect actual practice. If the SOA indicates a technical control is implemented, the auditor will test whether it operates consistently across the systems in scope. The ISO 27001 Statement of Applicability is, in this sense, a set of commitments that the organization makes to the auditor — and the Stage 2 audit tests whether those commitments have been kept.

Ongoing Surveillance Audits

After certification is achieved, the ISO 27001 Statement of Applicability remains central to surveillance audits conducted annually and to the recertification audit every three years. If the SOA has not been updated to reflect changes in the organization's operations, risk environment, or control implementation since the previous audit, the auditor will identify this as a failure of continual improvement. A SOA that is identical to the version from two years ago — without documented review and confirmation that no changes were warranted — does not demonstrate active ISMS governance.

Maintaining the SOA: Best Practices for Business Leaders

The ISO 27001 Statement of Applicability is not a document that organizations complete once and revisit only when an audit is approaching. ISO 27001 requires continual improvement of the ISMS, and the SOA must reflect that improvement.

  • Review the SOA at Least Annually — and Define Trigger-Based Reviews

    An annual management review should include a formal SOA review that evaluates whether the current control selections still address the risk profile, whether any controls have changed implementation status, and whether any changes to operations, technology, or the regulatory environment affect applicability decisions. Beyond the annual cycle, trigger-based reviews should be initiated whenever the organization acquires a new business unit, launches a new product, migrates to a new infrastructure environment, or changes its data handling practices materially.

  • Maintain Version Control With an Approval Audit Trail

    Every change to the SOA must be documented with the date of the change, the nature of the change, the reason for the change, and the name of the individual who authorized it. The SOA version number must be updated with each substantive revision, and the current version must always be accessible to the audit team. When the ISO 27001 certificate is renewed, confirm that the certificate reference matches the current SOA version.

  • Assign Control Owners Who Are Operationally Accountable

    Each applicable control in the SOA should have a named owner who is responsible for its implementation and ongoing operation. Control ownership should not be concentrated in the information security team alone — access controls are owned by IT, HR screening procedures are owned by Human Resources, supplier security requirements are owned by procurement. Distributed ownership reflects operational accountability and distributes the governance load appropriately across the organization.

  • Never Substitute Template Exclusions for Genuine Assessment

    One of the most consequential quality failures in SOA documents is the copy-paste exclusion — where an organization applies another company's exclusion justifications to its own SOA without verifying that the underlying conditions are the same. Every exclusion must reflect the organization's actual context as documented in its scope document and risk assessment. An exclusion that cannot be verified against these supporting documents will not survive Stage 1 scrutiny. The ISO 27001 Statement of Applicability must be specific to the organization it describes.

Conclusion

The ISO 27001 Statement of Applicability is a key audit document that demonstrates how an organization has translated its risk assessment into documented control decisions. When supported by objective evidence and maintained as the ISMS evolves, it provides a clear record of information security governance. When it is incomplete, outdated, or unsupported by risk assessment records, it commonly results in audit findings.

Organizations preparing for ISO 27001 certification should evaluate their Statement of Applicability against the same criteria used during an audit. It should align with documented risk assessment and risk treatment decisions, justify every Annex A control decision, and accurately reflect the organization's current control environment.

At CertPro, the Statement of Applicability is evaluated during both Stage 1 and Stage 2 of the ISO 27001 certification audit. Auditors assess its conformity with ISO/IEC 27001:2022 requirements and verify that documented control decisions are supported by objective evidence through interviews, observation, document and record review, and sampling where appropriate. Certification is issued by an IAF-accredited certification body upon successful completion of the audit.

Frequently Asked Questions
The ISO 27001 Statement of Applicability is mandatory. Clause 6.1.3(d) of the ISO 27001 standard explicitly requires organizations to produce this document as part of the risk treatment process. It lists all 93 Annex A controls, documents whether each is applicable or excluded, provides specific justifications for each decision, and records the implementation status of applicable controls. Without it, ISO 27001 certification cannot be achieved.
The SOA document must include four elements for every Annex A control: a declaration of applicability or exclusion, a justification for inclusion that traces to identified risks or obligations, the implementation status of each applicable control, and a justification for exclusion where controls are not applied. Supporting elements that strengthen audit defensibility include a version history, a reference column linking each control to supporting documentation, control owner identification, and evidence of management approval.
Valid exclusion justifications must be specific and connected to the organization's actual context. Acceptable reasons include that the risk the control addresses does not exist in the organization's environment, that the control applies to activities or assets outside the defined ISMS scope, or that another control already addresses the same risk more effectively. Cost, resource constraints, and lack of internal priority are not acceptable exclusion justifications and will be rejected by auditors. The ISO 27001 Statement of Applicability must record genuine governance decisions, not implementation deferrals.
The ISO 27001 SOA is the output of the risk assessment and risk treatment planning process. It cannot be produced credibly before those processes are complete. The risk assessment identifies threats, vulnerabilities, and risk levels. The risk treatment plan decides how each risk will be addressed. The SOA records which Annex A controls were selected to implement those treatment decisions. Auditors trace this connection explicitly during certification — they expect to be able to follow a specific risk from the risk register through the treatment plan to its corresponding control in the SOA.
A strong ISO 27001 statement of applicability example shows control decisions that are specific and traceable. For included controls, the justification references a specific risk ID from the risk register, names the treatment decision that led to the control selection, and identifies the policy or technical measure that implements it. For excluded controls, the justification explains precisely why the risk does not apply to this organization — for example, referencing a cloud-only infrastructure when excluding physical server security controls, and confirming that this aligns with the documented ISMS scope.
The SOA must be reviewed at least annually as part of the ISO 27001 management review process. Beyond the annual review, the document should be updated whenever material changes occur in the organization's operations, technology environment, risk profile, or regulatory obligations. Changes that affect which controls are applicable — such as adding cloud infrastructure, acquiring a subsidiary, or expanding into regulated markets — require a review and update of the SOA before the next surveillance audit. The ISO 27001 Statement of Applicability version must always reflect the organization's current ISMS state.