Last Updated on September 30, 2025 by Melissa Lazaro

Introduction

Whenever I help organizations prepare for ISO/IEC 27001:2022, one document always sparks the same question: “What exactly should we put in the Statement of Applicability?”

Most teams know the SoA is mandatory, but they either treat it as a copy-paste of Annex A or they under-document it. Both approaches cause problems. A bloated SoA looks fake, while a vague one leaves gaps auditors will jump on.

Here’s the reality: the SoA is not just a checklist. It’s the bridge that links your risk treatment plan to the controls in Annex A. It tells the auditor, in one place, which controls you’ve adopted, which ones you haven’t, and why.

To make it simple, here’s how I explain the difference between Annex A and the SoA to clients:

In this guide, I’ll walk you through the requirements for the SoA under ISO/IEC 27001:2022, show you the structure of an effective SoA, provide a sample extract, and explain how to maintain it so it always matches your ISMS in practice.

By the end, you’ll not only understand what the SoA is—you’ll know how to write one that auditors respect and your team can actually use.

What is the Statement of Applicability (SoA)?

The Statement of Applicability (SoA) is one of the core documents required by ISO/IEC 27001:2022. It’s not optional. Its job is to show how your organization has addressed the Annex A controls, based on your risk assessment and treatment plan.

Think of it as the map of your ISMS: it lists every Annex A control, marks which ones you’ve applied, which ones you haven’t, and explains why. More importantly, it links those decisions back to real risks and treatments.

A good SoA makes it easy for an auditor to trace the story:

• Here’s the risk.

• Here’s the treatment decision.

• Here are the controls we applied (or excluded) to handle it.

Common Pitfall

One of the biggest mistakes I see is companies copying Annex A word for word into their SoA without customization. On paper, it looks like they’ve implemented every control. But when the auditor asks, “Show me how A.8.12 (Data Leakage Prevention) is applied here,” the team has no evidence. That mismatch almost always leads to findings.

Real Example: A SaaS provider I worked with had a 30-page SoA that claimed all 93 controls were implemented. During audit, they were asked to show how they applied secure physical entry controls (A.7.1). Problem: they were a fully remote company with no office. The result? Nonconformity for a “fictional” SoA. After we tailored it properly, auditors were satisfied with exclusions backed by clear justification.

Key Point: The SoA isn’t just a list—it’s a decision log that proves your ISMS is risk-based and tailored to your business.

ISO/IEC 27001:2022 Requirements for the SoA (Clause 6.1.3 d)

The 2022 version of ISO/IEC 27001 makes the Statement of Applicability mandatory under Clause 6.1.3 d. The clause is short, but it carries a lot of weight in audits. In practice, it demands that your SoA does three things:

1. List all controls from Annex A.

2. Indicate whether each control is included or excluded.

3. Provide justification for inclusion or exclusion.

4. Reference how each included control is implemented.

Here’s a breakdown in plain language:

Why This Matters

Auditors use the SoA as a roadmap to test your ISMS. If your SoA says “Control A.8.3 is included and implemented,” they’ll expect to see a corresponding policy, procedure, or technical measure. If you exclude a control, they’ll look closely at your justification to make sure it makes sense in your business context.

In other words, the SoA is both a compliance requirement and a credibility test. A strong SoA makes audits smoother; a sloppy one invites findings.

Structure of an Effective SoA

A strong Statement of Applicability (SoA) is more than a simple checklist of controls. It’s a structured document that:

• Lists every Annex A control from ISO/IEC 27001:2022.

• States whether it’s included or excluded.

• Explains the justification for that decision.

• Provides a reference to how each included control is actually implemented in your ISMS.

In my experience, organizations that keep the SoA simple and structured have fewer audit findings. Auditors don’t want essays; they want a table they can scan quickly.

Essential Fields in an SoA

Sample SoA Structure

---

Key Point: Your SoA should be easy to read, easy to justify, and easy to audit. If someone outside your team can’t follow it, it’s too complex.

Example: SoA Entries (Sample Extract)

It’s one thing to know what fields the Statement of Applicability should contain, but it helps to see a realistic example. The SoA is not about copying Annex A into a spreadsheet—it’s about tailoring the list of 93 controls in ISO/IEC 27001:2022 to your business context and risks.

Let’s break it down. Each entry in the SoA should clearly show:

1. The control ID and name (so the auditor can trace it back to Annex A).

2. Whether it’s included or excluded.

3. The justification. This is where most organizations fail. A vague “Not applicable” isn’t enough; you need to explain why.

4. Implementation reference to the actual document, procedure, or technical control in your ISMS.

Common Pitfall:

I once saw a company list “Excluded” for A.5.29 Information Security in Supplier Agreements with the justification: “We don’t use suppliers.” The problem? They were using AWS and Microsoft 365. The auditor flagged it immediately. The lesson: if you exclude a control, make sure the justification is grounded in your real operations.

Sample Extract from an SoA

Here’s how three different types of controls might look in practice:

Why This Example Works

• Balance: It shows both included and excluded controls, each with a strong justification.

• Clarity: Implementation references are specific (policy names, version numbers, procedures), so auditors know exactly where to look.

• Contextual Fit: Decisions are tied to the organization’s reality—a remote company won’t have physical entry controls, but will need DLP.

Key Point: The SoA isn’t meant to be long-winded, but it has to be credible, traceable, and tailored. Auditors should be able to look at each entry and immediately understand your decision.

How to Maintain and Update the SoA

Creating the Statement of Applicability once and filing it away is one of the fastest ways to run into trouble at your next audit. The SoA is not static—it’s a living document. It must reflect your current risks, treatment decisions, and implemented controls.

Why Maintenance Matters

• Auditor expectation: Auditors always check that your SoA matches reality. If the SoA says you’ve implemented A.8.10 (Email Security) but you can’t demonstrate evidence, that’s a nonconformity.

• Business change: New technologies, outsourcing, or regulatory shifts change which controls are relevant. The SoA must keep pace.

• Risk evolution: Risks don’t stay the same. A risk you once accepted may grow in significance, requiring controls to be added.

Review Frequency

At a minimum, the SoA should be reviewed annually, but in practice, updates often happen sooner.

Assigning Ownership

• Primary Owner: The ISMS Manager, CISO, or equivalent should be responsible for maintaining the SoA.

• Risk Owners’ Role: Each risk owner should confirm that the controls listed in the SoA remain valid for their area.

• Approval: Updates should be logged and approved by top management during the management review.

Real Example

A fintech I worked with failed its surveillance audit because its SoA listed A.5.30 Supplier Security Requirements as “Excluded.” In reality, they had signed two new vendor contracts handling customer data. The justification was outdated, and the auditor raised a major nonconformity. After fixing it, they built SoA review into their quarterly governance process to avoid surprises.

Key Point: Your SoA is only as strong as its last update. Treat it as a working document, with clear ownership and defined review triggers, so it always mirrors your actual ISMS.

Common Audit Findings on the SoA

Even organizations that put effort into their Statement of Applicability often run into the same issues during audits. The SoA is a high-visibility document—if it doesn’t align with reality, auditors notice immediately.

1. Outdated SoA

• Finding: The SoA listed old controls and didn’t reflect changes in systems or suppliers.

• Example: A company had moved from on-prem servers to AWS but their SoA still included physical server room controls. The auditor flagged it as a nonconformity for outdated documentation.

• How to Avoid: Review and update the SoA at least annually, and whenever significant business or technology changes occur.

2. Controls Included Without Evidence

• Finding: Controls were marked as “Included,” but no procedures, policies, or technical evidence existed.

• Example: An SoA marked A.8.11 Secure Authentication as implemented, but MFA hadn’t been rolled out yet. The auditor noted a major nonconformity for misleading implementation claims.

• How to Avoid: Only mark a control as “Included” once you have real evidence—policy documents, configuration screenshots, logs, or training records.

3. Weak Justifications for Exclusions

• Finding: Excluded controls had generic justifications like “Not applicable” without context.

• Example: A SaaS provider excluded A.7.4 Physical Entry Controls with no explanation. The auditor challenged it until management clarified they had no offices.

• How to Avoid: Always provide business-focused reasons for exclusions, e.g., “Organization operates remotely with no owned facilities.”

4. SoA Not Linked to the Risk Treatment Plan

• Finding: Risks were identified and treatments documented, but the SoA didn’t reflect the controls chosen.

• Example: A healthcare company listed phishing as a top risk, treated it with staff training, but never updated the SoA to include A.6.3 Awareness and Training. This inconsistency was raised as a minor nonconformity.

• How to Avoid: Keep your SoA and risk treatment plan aligned. They should tell the same story from different angles.

5. Over-Complex SoA

• Finding: The SoA was so detailed (20+ pages of narrative) that auditors couldn’t quickly trace controls to risks.

• Example: A bank had written full essays for each control, making the document unwieldy. The auditor requested a simplified version.

• How to Avoid: Use a table format with concise justifications and references. Clarity beats volume every time.

Recap Table

Key Point: The SoA is often the first document auditors review. If it’s inaccurate, inconsistent, or outdated, it sets a negative tone for the entire audit. Keeping it simple, current, and evidence-based is the best way to avoid findings.

FAQs (Strengthen Trust & Address User Intent)

Q1. Does the SoA need to include all Annex A controls?

Yes. Every one of the 93 controls in Annex A (ISO/IEC 27001:2022) must appear in your SoA. Even if a control doesn’t apply, you still need to list it and provide a justification for exclusion. Skipping controls is one of the most common audit mistakes.

Q2. How detailed should the justifications be?

Justifications should be short and business-focused. A sentence or two is usually enough. For example:

• “Excluded – no physical offices; workforce is 100% remote.”

• “Included – required to mitigate phishing risk identified in risk assessment.”
  Avoid vague notes like “not relevant”—auditors want context.

Q3. What format should I use for the SoA?

Most organizations use Excel or Google Sheets because it’s simple to update and easy for auditors to review. Larger organizations sometimes use GRC (Governance, Risk, Compliance) tools, but clarity is more important than software. A well-structured table is always acceptable.

Conclusion (Reaffirm Authority & Prompt Action)

The Statement of Applicability (SoA) is more than just an ISO/IEC 27001:2022 requirement—it’s the backbone of your ISMS. Done right, it shows auditors exactly how your organization selected and applied controls based on real risks. Done poorly, it creates confusion, gaps, and nonconformities.

To recap:

• The SoA must cover all 93 Annex A controls with clear inclusion or exclusion.

• Every decision needs a business-focused justification.

• It must link directly to your risk treatment plan and reflect current practice.

• Keeping it simple, structured, and updated is the easiest way to avoid audit findings.

In my experience, organizations that treat the SoA as a living decision log—not just a spreadsheet for auditors—end up with smoother audits and a more effective ISMS overall.

Next Step: Start by reviewing your SoA against your current risk treatment plan. Update justifications, add missing references, and confirm ownership. If you’re building one from scratch, use a ready-to-customize SoA template and tailor it to your business context. It saves time and ensures you meet the exact requirements of ISO/IEC 27001:2022.