How to write an ISO 27001 Statement of Applicability: A step-by-step guide

The ISO 27001 Statement of Applicability (SoA) is one of the most critical documents in your path to ISO 27001 certification, and one of the first things auditors look at. It defines which Annex A controls apply to your organization, why certain controls are included or excluded, and how they are implemented within your ISMS. 

Get it right, and your certification process moves with clarity and confidence. Get it wrong, and everything from your risk treatment rationale to your control coverage comes under scrutiny.

A well-structured SoA guides auditors efficiently through your control landscape. A messy or incomplete one turns your audit into a discovery exercise nobody wants.

In this guide, we’ll show you a straightforward process for creating and maintaining your ISO 27001 Statement of Applicability.

Summary overview:

• The ISO 27001 Statement of Applicability (SoA) is a mandatory document under clause 6.1.3(d) that records all 93 Annex A controls, their applicability, justification, and implementation status within your ISMS.
• A well-structured SoA is one of the first documents auditors examine during ISO 27001 certification, making accuracy, traceability, and management sign-off non-negotiable.
• This guide covers everything you need to build an audit-ready SoA: what to include, how to write it step by step, common mistakes to avoid, and a complete checklist.

What is an ISO 27001 Statement of Applicability?

Quick definition: The ISO 27001 Statement of Applicability (SoA) is a mandatory document required by clause 6.1.3(d) of ISO 27001:2022. It lists all 93 Annex A controls, states whether each is applicable to your organization, provides justification for inclusion or exclusion, and describes how applicable controls are implemented.

The Statement of Applicability is your organization’s master control inventory. Required under clause 6.1.3(d) of ISO 27001:2022, it acts as the definitive record of the state of all 93 controls in Annex A. 

For every control, you must clearly state whether it applies to your organization, provide solid justification for including or excluding it, and explain exactly how it has been implemented where applicable.

ISO 27001 does not require you to implement all 93 controls. What it does require is that every inclusion and exclusion be justified based on your risk assessment and business context.

Mandatory requirements for the SoA:

• Must be formally documented
• Requires explicit management approval
• Must systematically cover all 93 Annex A controls without exception
• Should be maintained under version control
• Must be updated whenever your risk environment or business context changes

What does an SoA document include?

A complete iso 27001 SoA document covers the following for each control:

• Annex A control reference: The control number and name as listed in ISO 27001:2022 Annex A
• Applicability status: Whether the control is applicable or not applicable to your organization
• Inclusion/exclusion justification: The documented rationale for why a control has been included or excluded
• Implementation status: Whether the control is planned, in progress, or fully implemented
• Risk linkage: The specific risks or risk treatment decisions the control addresses
• Evidence references: Pointers to policies, procedures, or records that demonstrate implementation
• Control owner: The individual or team responsible for implementing and maintaining the control

Why the ISO 27001 SoA is critical for certification

Download Scrut’s auditor-ready SoA template

The ISO 27001 SoA acts as the bridge between your risk assessment, Annex A controls, audit readiness, and ISMS implementation.

1. Link risks directly to controls

Without a clear connection between identified risks and chosen controls, you risk implementing measures that don’t address your real threats or overlooking gaps altogether. The SoA prompts you to document exactly how each control mitigates specific risks, ensuring your risk treatment plan stays laser-focused on what truly matters.

2. Accelerate and simplify audits

Auditors need to verify dozens of controls quickly. A well-structured SoA serves as a one-stop reference that shows which controls you’ve implemented (and why), cutting down on audit back-and-forth, reducing surprises, and speeding up certification or surveillance reviews.

3. Prove compliance with confidence

Legal and contractual obligations can carry hefty fines or lost business if ignored. By capturing every externally driven control in your SoA and explaining its justification, the document helps you pair evidence and implementation. This helps you prove to regulators, customers, and partners that you’ve met all your mandatory requirements, avoiding penalties and reputational damage.

4. Offer a snapshot of your security posture

Executives, board members, and non-technical stakeholders need a concise view of your security posture. The SoA provides that high-level summary, listing controls, statuses, and rationales, so leadership can grasp risks and investments at a glance, make informed decisions, and prioritize resources effectively.

5. Keep your ISMS agile and current

Information security isn’t static. New threats emerge, business processes evolve, and technology shifts. Treating the SoA as a living document, with scheduled reviews and updates, keeps your ISMS aligned to current realities, helps identify outdated or missing controls, and embeds a culture of ongoing enhancement.

6. Unify teams around security objectives

Security touches IT, legal, HR, operations, and more. The SoA creates a single source of truth for all departments, clarifying who owns what controls and why. This shared reference breaks down silos, fosters accountability, and ensures everyone speaks the same language when it comes to risk management.

7. Strengthen stakeholder trust

Customers, partners, and investors want to see that you take security seriously. A transparent, well-documented SoA demonstrates due diligence, maturity, and commitment, transforming your certification from a checkbox exercise into a visible badge of trust that can win business and strengthen relationships.

What should an ISO 27001 SoA document include?

A complete statement of applicability ISO 27001 document captures the following for each of the 93 Annex A controls:

The SoA document is not a free-form document. Auditors expect a consistent, traceable structure covering all 93 Annex A controls. Weak justifications and incomplete implementation details are among the most common audit findings.

ISO 27001 SoA template

Building your SoA from scratch takes time and leaves room for gaps. 

ISO 27001 Annex A controls: What goes into your SoA

Your ISO 27001 Statement of Applicability must evaluate all 93 Annex A controls based on your organization’s risk profile and business context.

ISO 27001:2022 Annex A outlines 93 distinct security controls. While this is a significant drop from the 2013 version’s 114 controls, the intent and scope of these controls have not changed. When you treat risks (as mentioned in clause 6.1.3), you have to document the controls you chose from Annex A. Do note that you can select controls based on your company’s needs, and it is not mandatory to implement all controls.

The controls fall into four main categories that build your Statement of Applicability:

1. Organizational controls

This largest category features 37 controls (numbered 5.1 to 5.37). These controls are the foundation of your information security framework. They include policies, procedures, and structural elements. Your organization’s approach to data protection takes shape through these measures. The controls handle everything from security policies to management duties. These elements build the core of your security position.

2. People controls

Eight controls (numbered 6.1 to 6.8) make up this category, which puts people first. These measures guide staff interactions with sensitive data. Security awareness training, screening processes, and employment terms are part of these controls. Remote work guidelines and confidentiality agreements play a vital role in today's scattered work setup.

3. Physical controls

Fourteen controls (numbered 7.1 to 7.14) protect your physical assets. They set up secure zones with proper entry limits and shield against environmental risks. The controls defend your information processing facilities from unauthorized access, damage, and interference.

4. Technological controls

Thirty-four controls (numbered 8.1 to 8.34) focus on digital security. They cover areas like network security, encryption, malware defense, data masking, and managing technical vulnerabilities. Given the pace at which attack surfaces expand, these controls tend to require the most active upkeep within your SoA.

Your ISO 27001 Statement of Applicability should include a review of all 93 controls based on your organization’s needs and risk profile.

ISO 27001 SoA: 2013 vs 2022, what changed?

If your organization is certified under ISO 27001:2013, your existing SoA will need more than a cosmetic update during migration. The 2022 revision restructured and reduced the control set in ways that directly affect how your SoA is built.

The most visible change is the reduction from 114 controls across 14 domains to 93 controls organized into 4 categories: organizational, people, physical, and technological. This consolidation eliminated redundancy, but it also introduced 11 new controls that did not exist in the 2013 version, including:

• Threat intelligence
• Data masking
• Web filtering
• Cloud security

These additions reflect how the threat landscape has shifted since 2013. Organizations that previously had no obligation to address cloud security or web filtering now need to evaluate these controls and justify their inclusion or exclusion in the updated SoA.

For teams migrating from the 2013 standard, a line-by-line reassessment of the existing SoA is required. Controls that were merged, renamed, or restructured cannot simply be carried over. Each must be re-evaluated against your current risk profile and documented accordingly before the updated SoA is submitted for audit.

How to write an ISO 27001 Statement of Applicability: Step-by-step

The SoA does not exist in isolation. Each step below connects directly to your broader ISO 27001 implementation, from risk assessment through to management sign-off. 

1. Understand ISO 27001 requirements and controls

You need to be familiar with ISO 27001 standards to begin your SoA work. Study the 93 controls in Annex A and ISO 27002, which give detailed implementation guidance. This foundation helps align your security measures with international standards, strengthening your overall protection against data breaches. You’ll need to identify which controls apply to your organization’s specific context. These controls will then form the backbone of your SoA.

2. Conduct a risk assessment

The ISO 27001 risk assessment starts by identifying and cataloging all valuable assets, including data, hardware, software, and processes. Next, assess the threats and vulnerabilities linked to these assets, and prioritize them based on likelihood and potential impact. This method enables you to tailor security measures to your organization’s unique needs. The result is a security posture that’s both effective and resilient.

3. Complete the risk treatment plan

The risk treatment plan documents your response strategies after risk identification. This tactical document outlines the actions needed to address identified security risks. You must decide to avoid, accept, reduce, or transfer each risk. Ideally, your plan should list the security controls to be implemented, the responsible parties, implementation timelines, and resource needs. External auditors review this document closely during ISO 27001 certification audits.

4. Select the applicable controls

The next step is to determine which Annex A controls apply to your organization. Map each identified risk to the relevant controls selected through your risk treatment process.

Document your rationale if you exclude any controls. Note that not all controls may match your security objectives. For example, why spend $50,000 on advanced DLP software to prevent a risk that might cost $5,000 annually? 

Risk acceptance also applies when the likelihood or impact is genuinely low. A small SaaS company with 10 employees probably doesn’t require enterprise-grade physical security controls, such as biometric access systems and security guards. The threat exists, but it’s not proportional to your business size or risk profile.

A solid justification for exclusions shows careful assessment rather than oversight.

5. Finalize and approve the SoA

The last step is to compile your findings into the formal SoA document. ISO 27001 requires the implementation status (planned, in progress, or implemented) for each control. Get stakeholders from relevant departments to review, provide feedback, and refine the document. Management’s formal approval demonstrates its commitment to your security framework and prepares you for the ISO 27001 certification process.

6. Review and update the SoA regularly

As per clause 9.3 of ISO 27001, organizations review the SoA at least annually. However, organizations must review the SoA whenever significant changes occur, such as new risks emerging, company restructuring, or security incidents that expose gaps in their defenses.

To simplify: Ensure your SoA still reflects reality and actually protects what matters most to your business.

ISO 27001 SoA writing best practices

Building a defensible SoA is as much about discipline as it is about documentation. A few practices that separate audit-ready SoAs from ones that invite follow-up questions:

• Keep exclusions specific: A justification like “not applicable to our business” will not hold up under scrutiny. Reference the specific risk assessment finding or business context that drives the exclusion.
• Link controls to risks: Every applicable control should trace back to at least one risk in your risk treatment plan. If the linkage is missing, auditors will ask why the control exists.
• Maintain version history: Your SoA should carry a version number, change log, and approval date. This tells auditors the document is actively managed, not filed and forgotten.
• Review after major changes: New vendors, infrastructure migrations, product launches, and acquisitions can all shift your control requirements. Treat each as a trigger for SoA review.
• Keep implementation notes audit-ready: Brief, vague notes like “in place” are not sufficient. Describe how the control is implemented, who owns it, and where evidence can be found.
• Ensure management approval: An SoA without a documented sign-off from senior management is non-compliant. This is a mandatory requirement under clause 6.1.3(d), not an optional formality.

Common mistakes to avoid when creating your SoA

Even experienced teams make avoidable errors when building or updating their SoA. These are the ones auditors flag most often:

• Vague exclusions: Excluding a control without a specific, risk-grounded justification is one of the fastest ways to stall a certification audit. Each exclusion needs to be traceable to your risk assessment or a documented business rationale.
• Missing risk linkage: Controls that float in your SoA without a connection to identified risks suggest the document was built in isolation from your risk treatment process. Auditors will probe this gap.
• Treating the SoA as static: An SoA written once and never revisited is a liability. Your threat environment, business scope, and technology stack change. Your SoA must keep pace.
• Missing sign-offs: An SoA without management approval is non-compliant, regardless of how thorough the content is. Build the sign-off step into your process, not as an afterthought.
• Blank implementation statuses: Leaving implementation status fields empty or marking everything as “implemented” without supporting evidence are both red flags. Be accurate, even if some controls are still in progress.

ISO 27001 SoA vs. risk treatment plan and other key documents

Organizations often confuse the ISO 27001 Statement of Applicability with the risk treatment plan or ISMS scope document. While these documents work together, they serve distinct functions within your ISMS.

How Scrut helps you achieve ISO 27001 compliance

Building and maintaining a compliant ISO 27001 Statement of Applicability manually is time-consuming and error-prone. Scrut is an AI-powered compliance platform that operationalizes continuous compliance and security, helping organizations achieve and maintain ISO 27001 certification without the operational overhead of managing it manually.

• Structured implementation from day one. Scrut provides a structured implementation plan with ISO 27001-aligned controls and automated tests. You can define your ISMS scope, policies, and security objectives using auditor-vetted, customizable templates, so your documentation is built to certification standards from the start.
• Automated evidence collection. Scrut integrates with your cloud infrastructure, application stack, and security toolkit to automatically track ISO 27001 control status and collect evidence continuously. With 100+ integrations, evidence gathering happens in the background without manual effort.
• Centralized control management. Scrut maps your controls directly to ISO 27001 clauses and Annex A, giving you a single dashboard to implement, monitor, and track compliance status in real time. Compliance gaps are detected automatically, with real-time alerts and task management to assign ownership, track remediation progress, and close gaps before your next audit.
• Audit workspace for seamless collaboration. Scrut’s shared audit workspace lets you invite internal auditors and external ISO 27001 assessors to review evidence, monitor progress, and log findings, with every change tracked in real time throughout the certification process.
• Multi-framework support. Controls and audit evidence can be reused across all 62 supported frameworks, minimizing duplication and reducing compliance effort across the board.
• Continuous monitoring beyond certification. Scrut’s continuous monitoring keeps your ISMS compliant over time, with reports available on demand for management reviews and external audits.

Ready to simplify your path to ISO 27001 certification? See Scrut in action. Book a demo

FAQs

‍

What is a statement of applicability in ISO 27001?

The ISO 27001 Statement of Applicability is a mandatory document required under clause 6.1.3(d). It lists all 93 Annex A controls, records whether each is applicable to your organization, provides justification for inclusion or exclusion, and captures the implementation status of every applicable control.

What is the statement of applicability ISO 27001 used for?

The SoA serves as the primary reference document during an ISO 27001 audit. It shows auditors how your organization has addressed information security risks through Annex A controls, and demonstrates that every inclusion and exclusion decision is grounded in your risk assessment.

Is the SoA the same as the ISO 27001 SoA document?

Yes. Statement of Applicability (SoA) and SoA document all refer to the same mandatory ISO 27001 artifact. The terms are used interchangeably across audit and compliance contexts.

Do you have to implement all 93 Annex A controls?

No. ISO 27001 does not require all 93 controls to be implemented. Controls that are not relevant to your organization’s risk profile or business context can be excluded, provided each exclusion is formally documented and justified.

How often should the SoA be reviewed?

Clause 9.3 of ISO 27001 requires the SoA to be reviewed at planned intervals, typically at least annually. It should also be reviewed following significant changes to your organization’s risk environment, business scope, or technology infrastructure.

What happens if your SoA is incomplete during an audit?

An incomplete SoA is one of the most common causes of audit nonconformities. Missing justifications for excluded controls, blank implementation statuses, or controls that cannot be traced back to your risk treatment plan will typically result in findings that delay or block certification.

‍