ISO 27001 Statement of Applicability: Complete Creation Guide

Understanding the Statement of Applicability

The Statement of Applicability (SoA) is arguably the most critical single document in ISO 27001 certification. This document lists all Annex A controls, identifies which are applicable to your organization, justifies any exclusions, and documents implementation status for each applicable control.

ISO 27001 clause 6.1.3 explicitly requires the SoA to contain all controls identified through risk assessment processes, justification for selections, and current implementation status. During certification audits, the SoA becomes the roadmap auditors use to verify your implementation.

SoA Structure and Components

Control Inventory

The SoA must inventory all 93 Annex A controls organized by theme. The 2022 revision organizes controls into four themes: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). Each control has a unique identifier (A.5.1, A.8.2, etc.) and title.

For each control, your SoA must indicate whether it’s applicable and, if so, its implementation status. Applicable controls are those required to address assessed risks. Inapplicable controls are those not needed based on your risk assessment and business context.

Applicability Justification

For each control deemed inapplicable, document your justification. Common justifications include: control addresses a risk not present in your environment, alternative controls achieve the same objective, control doesn’t apply to your business model, or control is redundant with other implemented controls.

Justifications must be specific and defensible. “Not applicable” without explanation is insufficient. “Not applicable—we don’t manufacture physical products” for control A.7.9 (equipment siting and protection) provides adequate justification.

Implementation Documentation

For each applicable control, document its implementation. Implementation documentation should reference specific policies, procedures, technical configurations, or process descriptions. Where controls are implemented through multiple measures, document each implementation reference.

Implementation documentation provides the evidence trail auditors follow during certification audits. Clear, specific documentation makes audit preparation more efficient and reduces findings.

Creating Your SoA: Step-by-Step Process

Step 1: Complete Risk Assessment

Your SoA flows from risk assessment results. Before creating the SoA, ensure you’ve completed systematic risk assessment following documented methodologies. Risk assessment identifies which risks require treatment and guides control selection.

Use our readiness simulator to estimate the effort required to establish robust risk assessment processes if they’re not already in place.

Step 2: Map Controls to Risks

For each assessed risk requiring treatment, identify Annex A controls that could address it. Some risks map to multiple controls. Some controls address multiple risks. Document these mappings to support your SoA entries.

For example, unauthorized access risks might map to controls A.5.15 (access control), A.8.2 (privileged access rights), and A.8.5 (secure authentication). Malware risks might map to A.8.19 (installation of software on operational systems) and A.12.2 (malware protection).

Step 3: Determine Applicability

Determine applicability for each Annex A control. Controls are applicable if they address assessed risks, are required by regulations or contracts, support your security objectives, or represent industry best practices for your business model.

Controls are inapplicable if they address risks not present in your environment, don’t support your security objectives, or are redundant with other implemented controls. Be conservative with inapplicability determinations—certifiers may challenge excessive exclusions.

Step 4: Document Implementation Status

For applicable controls, document implementation status using categories such as: implemented, planned, partially implemented, or not applicable. For each implemented control, reference specific policies, procedures, or technical configurations that implement it.

Implementation references might include “See Access Control Policy SEC-001”, “Implemented through MFA requirement in identity management system”, or “Documented in Incident Response Procedure IRP-02”.

Step 5: Obtain Management Approval

The SoA requires management approval as part of overall ISMS approval. Present the SoA to management for review and formal approval. Document approval through signatures, approval emails, or meeting minutes.

Management approval of the SoA demonstrates organizational commitment and provides authority for implementation activities. It’s a critical audit finding if the SoA lacks appropriate approval.

Control Selection Principles

Risk-Driven Selection

Control selection must be risk-driven. Select controls that address your highest-priority, highest-risk threats. Avoid implementing controls simply because they seem like good ideas or are popular in the industry.

When auditors review your SoA, they should see logical connections between your assessed risks and selected controls. Random or inexplicable control selections raise questions about your risk assessment quality.

Control Coverage

Ensure selected controls provide comprehensive coverage across your threat landscape. Address organizational, people, physical, and technological control themes. Address prevention, detection, response, and recovery functions.

Gap analysis often reveals over-investment in certain areas (often technical controls) and under-investment in others (often training or process controls). Balanced control implementation provides more effective security.

Justified Exclusions

Every excluded control requires justification. Document specific reasons why each control doesn’t apply to your environment. Vague or generic justifications invite auditor challenges.

If you exclude many controls in a particular area, be prepared to explain why that area doesn’t apply to your organization. For example, excluding all physical security controls when you have offices and data centers would be difficult to justify.

SoA Documentation Best Practices

Clear Reference Systems

Use clear, consistent reference systems for linking SoA entries to specific documentation. Reference codes like “SEC-001” or “IRP-02” help auditors locate implementation evidence efficiently.

Maintain a document register cross-referencing these codes to actual documents. This register becomes valuable as your documentation grows and changes over time.

Implementation Details

Provide enough implementation detail to satisfy auditors without creating maintenance burdens. “See Access Control Policy” is better than “Implemented through access controls.” “Implemented through Azure AD MFA requirement” is better than “Implemented through technical controls.”

Details should enable auditors to locate and examine implementation evidence quickly. Clear details reduce audit duration and findings.

Status Tracking

Track implementation status throughout your implementation project. Update the SoA as controls move from planned to partially implemented to fully implemented. Status tracking demonstrates progress and identifies remaining work.

Implementation status becomes particularly important if your certification spans multiple phases or if you’re pursuing staged certification for different organizational units.

Common SoA Mistakes

Copying from Templates

Copying SoA entries from templates or other organizations is a common mistake. Templates rarely match your specific risk profile, business model, or environment. Auditors quickly identify generic SoAs that don’t reflect organizational context.

Start with control lists but customize applicability determinations and implementation documentation to reflect your organization. Your SoA should tell your organization’s security story, not someone else’s.

Over-Specifying Implementation

Documenting every technical detail creates maintenance burdens. When implementations change, you must update the SoA. Document at the appropriate level—procedures rather than specific configurations, policies rather than specific technical settings.

Balance detail needs with maintenance practicality. You want enough detail to satisfy auditors without creating constant update requirements.

Insufficient Justification

Vague justifications for inapplicable controls invite auditor challenges. “Not applicable” without explanation is insufficient. “Not applicable to our environment” is barely better. Specific, contextual justifications are required.

Good justification example: “A.12.3 (backup) not applicable—all data processed in cloud environment with provider-managed backup and redundancy.” This explains why the control doesn’t apply specifically to your environment.

Neglecting Updates

The SoA is a living document. As risks change, implementations evolve, and business conditions shift, the SoA should be updated. Neglecting updates creates discrepancies between documented status and actual implementation.

Establish quarterly SoA reviews to verify alignment with current implementation. Update entries as new controls are added or existing implementations change.

SoA as Implementation Roadmap

Beyond audit requirements, the SoA serves as your implementation roadmap. Use it to track progress, identify gaps, prioritize activities, and communicate status to stakeholders.

Organizations pursuing staged certification can use the SoA to define phases. Phase 1 might implement critical controls addressing high-risk areas. Phase 2 might extend coverage to lower-risk areas or more comprehensive implementations.

SoA Tools and Templates

Many organizations use spreadsheets for SoA management initially. Spreadsheets provide flexibility and accessibility but become difficult to maintain as documentation grows and multiple people need updates.

Dedicated GRC tools offer advantages for larger organizations including version control, workflow automation, linkage to other compliance requirements, and reporting capabilities. Evaluate tools based on your organization’s size, complexity, and resources.

Regardless of tools, focus on content quality rather than presentation. A simple spreadsheet with accurate, well-documented entries serves certification purposes better than sophisticated tools with incomplete or generic content.

Use our readiness simulator to estimate the resources needed for comprehensive SoA development and implementation.

Continue exploring our guides on security policy development and documentation best practices for deeper implementation guidance.

Browse all guides and articles for comprehensive ISO 27001 implementation coverage.