What is the Statement of Applicability for ISO 27001?

The Statement of Applicability (SoA) is one of the most critical and most misunderstood documents in your Information Security Management System (ISMS). Get it wrong, and you risk failing your certification audit. Get it right, and it becomes the strategic backbone of your entire ISO 27001 programme. This guide covers everything you need to know.

What Is the Statement of Applicability?

The Statement of Applicability (SoA) is a mandatory document required under ISO 27001, the international standard for Information Security Management Systems. At its core, the SoA is a formal declaration that identifies which of the security controls listed in Annex A of ISO 27001 apply to your organisation and, critically, which ones do not, along with documented justifications for every single decision.

Think of the SoA as the bridge between your information security risk assessment and the actual controls you deploy to manage those risks. It tells auditors, stakeholders, and certification bodies exactly how your organisation approaches information security: what you've implemented, what you haven't, and why every choice was made.

Quick Answer: The Statement of Applicability is a document that lists all ISO 27001 Annex A controls, states whether each control is applicable, provides a justification for that decision, and confirms the implementation status of each applicable control.

Without a complete and compliant SoA, your organisation cannot obtain ISO 27001 certification. It is one of the few documents explicitly required by the standard itself — specifically under Clause 6.1.3(d).

Why the Statement of Applicability Is Critical for ISO 27001 Certification

The SoA serves several vital functions in your ISO 27001 journey. It is not merely a bureaucratic checkbox; it is a living, strategic document that underpins your ISMS's entire security posture.

It Is an Explicit Certification Requirement

ISO 27001 Clause 6.1.3 requires organisations to produce an SoA as part of their information security risk treatment process. Certification auditors will review your SoA in detail during both Stage 1 (documentation review) and Stage 2 (implementation review) audits. A poorly structured or incomplete SoA is one of the top reasons organisations receive major nonconformities during certification.

It Demonstrates Risk-Based Thinking

The SoA shows that your organisation hasn't simply ticked boxes but has made deliberate, risk-informed decisions about which controls are relevant to your specific context — your industry, size, threat landscape, legal obligations, and business objectives. This is at the heart of what ISO 27001 demands.

It Provides Accountability and Traceability

Every inclusion or exclusion in the SoA must be traceable back to your risk assessment results, legal or regulatory requirements, or contractual obligations. This traceability is essential during audits and during internal reviews of your ISMS.

It Guides Implementation Efforts

Your security teams use the SoA as a roadmap. By documenting not just which controls apply but also their implementation status, the SoA helps programme managers track progress, allocate resources, and report to leadership on the real-world state of the ISMS.

What Must the Statement of Applicability Include?

ISO 27001 Clause 6.1.3 specifies that the SoA must contain, at a minimum, four elements for each control in Annex A.

First, it must list all necessary controls for every Annex A control considered during the risk treatment process. In ISO 27001:2022, this means all 93 controls must be evaluated without exception.

Second, it must include a justification for inclusion, a clear explanation of why each applicable control has been selected, linked to specific risks, legal obligations, or contractual requirements.

Third, it must record whether each control is implemented and the current implementation status of each applicable control, typically expressed as Implemented, Partially Implemented, Planned, or Not Yet Implemented.

Fourth, it must provide a justification for any exclusionsand a documented rationale for each control deemed not applicable. These exclusions must be defensible; auditors scrutinise them carefully.

Many organisations also include additional columns for practical management — such as control owner, policy or procedure reference, review date, and evidence location. While not mandated by the standard, these additions significantly enhance the document's operational value.

Understanding ISO 27001 Annex A Controls (2022 Update)

ISO 27001 was significantly updated in 2022. The revised standard reorganised Annex A from 114 controls across 14 domains (in the 2013 version) into 93 controls across four themes. If your organisation was certified under the 2013 standard, updating your SoA to reflect this restructuring is essential, as the transition deadline has passed.

The four themes in ISO 27001:Organisational Controls comprise 37 controls, including policies, roles and responsibilities, supplier relationships, and incident management. People Controls covers 8 controls addressing screening, terms of employment, awareness, and training. Physical Controls covers 14 controls relating to physical security perimeters, equipment security, and secure areas. Technological Controls covers 34 controls, including access control, cryptography, malware protection, logging, and vulnerability management.

The 2022 update also introduced 11 new controls, including threat intelligence, information security for cloud services, ICT readiness for business continuity, and data masking, that organisations must now evaluate and address in their SoA.

⚠️ Transition Alert: If your organisation was certified to ISO 27001:2013, your SoA must be updated to reflect the restructured Annex A controls in ISO 27001:2022. The transition period ended in October 2025.

How to Write Your Statement of Applicability: A Step-by-Step Guide

Building a compliant, audit-ready SoA doesn't have to be overwhelming. The following seven steps will help you develop a document that satisfies your certification auditor and genuinely serves your organisation's security programme.

Step 1: Complete Your Information Security Risk Assessment

Before writing a single line of your SoA, you must have completed a risk assessment. Your SoA must reference specific risks that drive the selection of controls. Identify all your information assets, threats, vulnerabilities, and the likelihood and impact of each risk scenario. This output becomes the primary justification engine for your entire SoA.

Step 2: Identify All Legal, Regulatory, and Contractual Requirements

Beyond risk, certain controls may be mandated by law — such as GDPR, NIS2, or sector-specific regulations or by contracts with clients or partners. Compile a full legal register and cross-reference it with the Annex A controls. These obligations become mandatory justifications for specific control inclusions.

Step 3: Evaluate Every Annex A Control Individually

Go through all 93 Annex A controls individually. For each control, ask: "Is this control relevant to our organisation, our risks, our legal obligations, or our contractual requirements?" Document your determination, applicable or not applicable, along with the reasoning behind it.

Step 4: Document Justifications for Every Decision

This is where many organisations fall short. Every "applicable" decision must link back to at least one risk, legal requirement, or contractual obligation. Every "not applicable" decision must explain why the control is genuinely irrelevant — not merely inconvenient to implement. Vague justifications like "not relevant to our business" will not satisfy an auditor.

Step 5: Record Implementation Status for Applicable Controls

For every control marked as applicable, document its current implementation status using consistent terminology, for example: Implemented, Partially Implemented, Planned (with a target date), or Not Yet Implemented. This gives your programme a clear action register and demonstrates your roadmap to auditors.

Step 6: Link Controls to Policy and Procedure Documentation

For each applicable control, reference the policy, procedure, or technical measure that demonstrates it has been implemented. This traceability turns your SoA from a standalone spreadsheet into the hub of your entire ISMS documentation ecosystem.

Step 7: Review, Approve, and Maintain the SoA

Your SoA must be approved by management and reviewed regularly, particularly when your risk landscape changes, when new systems or processes are introduced, or after a security incident. Treat it as a living document, not a one-time exercise. Version control is essential.

Common Mistakes to Avoid When Writing Your SoA

Having reviewed hundreds of SoA documents, DSALTA's compliance experts have identified the most frequent errors that lead to audit nonconformities or genuine security gaps.

Weak or generic exclusion justifications are among the most common issues. Saying a control is "not applicable" without a specific, documented rationale is a red flag for auditors. Every exclusion needs a defensible reason grounded in your organisation's actual context.

A disconnection from the risk assessment is another major problem. The SoA should flow directly from your risk assessment output. If the two documents don't clearly connect, auditors will question the validity of your entire risk treatment process.

Many organisations also treat the SoA as a static document — created for initial certification and never revisited. The standard requires it to reflect your current ISMS state at all times.

Other common errors include incomplete coverage (every Annex A control must be addressed), failing to update the SoA to the 2022 restructuring, and letting implementation status fall out of sync with reality. Auditors verify implementation status against actual evidence, not aspirational plans.

SoA vs. Risk Treatment Plan: Understanding the Difference

The Risk Treatment Plan (RTP) and the Statement of Applicability are closely related but serve distinct purposes — and both are required by ISO 27001.

The RTP describes how identified risks will be treated. It focuses on specific risks and the actions taken to address them, and its primary audience is risk owners and security programme managers. It is governed by Clause 6.1.3(e).

The SoA, by contrast, declares which Annex A controls are applicable and why. It covers all 93 controls regardless of whether they are driven by risk, legal obligations, or contractual requirements. It must also include documented exclusions, something the RTP does not. Its primary audience is certification auditors, management, and compliance teams. It is governed by Clause 6.1.3(d).

The SoA draws upon the outputs of the risk assessment and the RTP, but it is broader in scope. Together, these two documents form the cornerstone of your ISO 27001 compliance documentation.

How DSALTA Automates Your ISO 27001 Statement of Applicability

Creating and maintaining a compliant SoA is time-consuming and detail-intensive, especially as organisations scale, add new systems, expand into new markets, or respond to evolving threats. This is where DSALTA's AI-powered compliance platform delivers transformational value.

AI-Driven Risk-to-Control Mapping

DSALTA's platform automatically maps your risk assessment outputs to relevant Annex A controls, dramatically reducing the manual effort required to build your initial SoA. The AI engine understands the relationships between risk scenarios and control objectives, suggesting applicable controls and flagging potential gaps in your control selection.

Pre-Built SoA Templates Aligned to ISO 27001:2022

Start with DSALTA's fully structured SoA templates, already aligned to the 93 controls in ISO 27001:2022. Each control comes with guidance notes, example justifications, and prompts for implementation evidence — accelerating your team's work while ensuring nothing is missed.

Real-Time Implementation Tracking

As your team implements controls, DSALTA automatically updates the implementation status across your SoA. No more manually updating spreadsheets — your SoA reflects the live state of your ISMS at all times, giving you an always-audit-ready posture.

Justification Quality Checks

DSALTA's compliance AI reviews the quality of your justifications, flagging entries that are too vague, lack supporting risk evidence, or fail to include references to legal obligations. This built-in quality control layer significantly reduces the risk of nonconformities during certification audits.

Seamless Transition from ISO 27001:2013 to 2022

If you're transitioning from the older standard, DSALTA provides an automated mapping tool that cross-references your existing 2013-based SoA with the new 2022 control structure, identifying gaps and guiding your update process from start to finish.

Frequently Asked Questions About the ISO 27001 Statement of Applicability

Is the Statement of Applicability mandatory for ISO 27001? Yes. The SoA is a mandatory documented requirement under ISO 27001 Clause 6.1.3(d). Without a compliant SoA, your organisation cannot achieve ISO 27001 certification.

What is the difference between an SoA and a risk treatment plan? The Risk Treatment Plan describes how identified risks will be treated. The SoA documents, which Annex A controls, are selected or excluded, and the justification for each decision is provided. It draws on the RTP but is a separate, broader document covering all 93 Annex A controls.

How many controls are in ISO 27001 Annex A (2022)? ISO 27001:2022 Annex A contains 93 controls across four themes: Organisational (37), People (8), Physical (14), and Technological (34). This is a reduction from the 114 controls in the 2013 version.

Can I exclude controls from my ISO 27001 SoA? Yes, but exclusions must be clearly justified. You can only exclude a control if no applicable risk, legal obligation, or contractual requirement necessitates it. All exclusions must be documented with a specific, defensible rationale.

How often should the SoA be updated? At least annually, and whenever there are significant changes to your organisation — new systems, processes, threat intelligence, legal requirements, or following a security incident. Treat it as a living document that always reflects your current ISMS state.

What format should the Statement of Applicability be in? ISO 27001 does not mandate a specific format. Most organisations use a spreadsheet or table document. What matters is that it contains all required elements: the controls considered, justifications for inclusion and exclusion, and implementation status for all applicable controls.

DSALTA is an AI compliance platform helping organisations achieve and maintain ISO 27001 certification faster, with less manual effort and greater confidence. Learn more at dsalta.com.