How to build a defensible ISO 27001 Statement of Applicability

The Statement of Applicability (SoA) is a mandatory ISO 27001 document that lists all Annex A controls, states whether each control is applicable to your ISMS, and provides justification for inclusion or exclusion. It sits at the intersection of your risk assessment, risk treatment plan, and control implementation evidence.

Certification auditors use the SoA as their primary roadmap during Stage 2 and surveillance audits. They sample controls marked as applicable and verify that implementation evidence exists and operates effectively. They also scrutinize excluded controls to confirm that exclusions are justified by risk assessment outcomes rather than convenience or incomplete implementation.

A weak SoA creates audit friction: auditors expand sampling scope, question exclusion rationale, and may raise findings when controls marked as implemented lack supporting evidence. GRC teams that invest time in a precise, risk-linked SoA reduce audit duration and findings risk.

Each control entry in the SoA should include, at minimum: the Annex A control identifier and title, whether the control is applicable (yes or no), the implementation status (implemented, partially implemented, planned, or not applicable), a reference to the risk or risks the control treats, and justification for exclusion where the control is marked not applicable.

Implementation status should reflect reality, not aspiration. Marking a control as implemented when evidence is incomplete creates findings during audit fieldwork. If a control is planned with a target date, document the remediation plan and track progress in your corrective action process.

Cross-reference each applicable control to supporting policies, procedures, and evidence artifacts. This cross-reference enables auditors to navigate from the SoA to implementation proof efficiently and helps control owners understand their responsibilities.

• Control identifier and title from ISO 27001:2022 Annex A
• Applicability determination (yes/no) linked to risk assessment
• Implementation status with honest assessment of current state
• Exclusion justification referencing specific risk treatment decisions
• Cross-reference to policies, procedures, and evidence artifacts

ISO 27001 requires that control selection be the output of a risk treatment process, not an arbitrary checklist exercise. Your risk assessment should identify information security risks within ISMS scope, evaluate them using a defined methodology, and produce a risk treatment plan that specifies which Annex A controls address each risk.

The SoA should trace back to this risk treatment plan. For each applicable control, reference the risk ID or risk description it mitigates. For each excluded control, explain why the associated risks are accepted, transferred, or not present in your environment.

Auditors frequently test this linkage by selecting a risk from your risk register and asking which controls treat it, or by selecting an excluded control and asking why the associated risk does not apply. GRC teams should rehearse these traceability questions before Stage 2.

Excluding Annex A controls is permitted when risk assessment demonstrates that the associated risks are not relevant to your ISMS scope. Common defensible exclusions include physical security controls for fully remote organizations with no corporate office, or media handling controls when no removable media is used in scoped systems.

Weak exclusions cite cost, effort, or lack of priority as rationale. These justifications fail audit scrutiny because ISO 27001 requires risk-based decisions, not resource-based ones. If a risk exists and you choose not to implement the corresponding control, document explicit risk acceptance with management approval.

When excluding controls, consider whether compensating controls address the underlying risk through alternative means. If your organization excludes A.7.4 (physical security monitoring) because you have no office, but hosts infrastructure in a certified data center, reference the data center provider's physical security controls in your exclusion justification.

ISO 27001:2022 reorganized Annex A into four themes: organizational controls (A.5), people controls (A.6), physical controls (A.7), and technological controls (A.8). GRC teams updating legacy SoA documents should remap controls to the 2022 structure before engaging a certification body for the current standard.

Organizational controls (A.5) cover policies, roles, supplier relationships, and threat intelligence. These controls often require cross-functional ownership and are evaluated through document review and management interviews rather than technical testing.

Technological controls (A.8) cover access management, encryption, secure development, and logging. Evidence for these controls is typically technical: configuration screenshots, log samples, scan reports, and change tickets. Your SoA should indicate the evidence type expected for each control category so owners prepare appropriately.

The SoA is not a static pre-certification document. ISO 27001 requires continual improvement, which means updating the SoA when scope changes, new services launch, vendors are onboarded, or risk assessments identify new threats.

Establish a trigger-based review process. SoA updates should occur when: a new product or service enters ISMS scope, a significant vendor is added or removed, a risk assessment is refreshed, an incident reveals control gaps, or regulatory requirements change. Document the review date and changes in a revision history.

During surveillance audits, auditors compare the current SoA to the previous audit version and focus on changes. GRC teams should prepare change summaries explaining new controls, modified exclusions, and the risk assessment inputs that drove each change.

Many GRC teams begin with certification body SoA templates or ISO 27001 toolkit spreadsheets. These provide structure but should be customized to reflect your organization's actual risk profile and implementation status. Copying a template with all controls marked applicable signals to auditors that no genuine risk assessment occurred.

Formatting mistakes that create audit friction include: missing exclusion justifications, inconsistent control identifiers between the SoA and evidence library, implementation statuses that contradict evidence on file, and SoA versions that do not match the ISMS documentation set provided to auditors.

AuditOak generates SoA-aligned control checklists from your scoping inputs and tracks implementation status with human-verified evidence against each Annex A control. When you update a control status in one framework, cross-framework mappings surface related controls in SOC 2 and GDPR programs for confirmation.