Your Guide to the ISO 27001 Statement of Applicability

The ISO 27001 Statement of Applicability (SoA) is the single most important document in your Information Security Management System (ISMS). It's a mandatory record that lists all 93 security controls from Annex A and explains why each one is either applied or excluded from your security program. Think of it as the strategic glue connecting your identified risks to your real-world security measures.

What Is an ISO 27001 Statement of Applicability

Many people mistakenly view the Statement of Applicability as just another compliance checklist. In reality, it’s the definitive bridge between your risk assessment and the security controls you actually implement. While Annex A gives you the what—the full menu of 93 possible controls—the SoA documents the why.

Think of it this way: Annex A is a complete catalog of building materials and techniques you could use to construct a house. It includes everything from reinforced concrete foundations to decorative window shutters. You’d never use every single item.

Instead, your architect creates a detailed blueprint—your SoA—that specifies exactly which materials are needed based on your home’s design, local climate, and building codes. This blueprint justifies using a heavy-duty foundation because you live in an earthquake-prone area, while also explaining why you’re skipping the hurricane shutters. Your SoA does the same thing for your information security program. It documents the deliberate, risk-based decisions you made for every single Annex A control.

Key Takeaway: The Statement of Applicability is a mandatory ISO 27001 document. You must list every Annex A control and justify its inclusion or exclusion. Simply ignoring a control or failing to explain your reasoning is a common and major audit failure.

To build a solid SoA, you need to include a few fundamental pieces of information. These elements work together to create a document that is clear, comprehensive, and ready for your auditor's review.

The table below breaks down the essential components that make a functional and compliant Statement of Applicability.

Core Components of the Statement of Applicability

By including these five components, you create a powerful document that not only meets ISO 27001 requirements but also serves as a central dashboard for managing your entire security program.

Why Your SoA Is the Heart of Your ISO 27001 Audit

When an auditor arrives to review your Information Security Management System (ISMS), there's one document they'll zero in on almost immediately: the ISO 27001 Statement of Applicability. More than any other piece of documentation, the SoA is the central pillar of your certification audit. It’s the one document that connects your risk assessment directly to the security controls you've put in place.

I like to think of it as the blueprints for a new building. Your auditor is the building inspector. They aren't just there to see a pile of materials (your tools and policies); they want to see the detailed plans proving that every decision was deliberate, meets code, and results in a safe, sound structure. Your SoA is those blueprints.

It’s your chance to show the auditor that you've moved past a simple checklist mentality. A strong SoA proves your security program is a mature, risk-based system built specifically for your organization's unique needs.

The SoA as Your Audit Roadmap

From an auditor’s perspective, the SoA is the roadmap for the entire engagement. It’s often the very first thing they dive into because it tells them exactly what to look for and where to find it.

A well-organized Statement of Applicability does three things exceptionally well:

• Guides the Auditor: It points them straight to the relevant policies, procedures, and evidence for every single control you've implemented.
• Justifies Exclusions: It gives a clear, business-focused reason why certain Annex A controls don’t apply to you, which heads off a lot of unnecessary questions.
• Demonstrates Understanding: It proves you genuinely grasp your own risk landscape and how the ISO 27001 framework helps you manage it.

An experienced auditor can tell if a Statement of Applicability is weak within minutes. If your justifications for excluding controls are vague or if you've simply forgotten to address all 93 controls, it immediately signals that there are likely bigger problems in your ISMS. This can put your entire audit in jeopardy before it even gets started.

A major red flag for any auditor is a mismatch between your SoA and your risk assessment. If you claim to have implemented a control for a risk that doesn't even appear in your risk register, it completely undermines the credibility of your program. For more hands-on advice on navigating the audit process, check out our guide to preparing for ISO 27001 audits.

Proving Your Security Story

Ultimately, the SoA is where you formally declare your security posture. It’s not just a spreadsheet; it’s a story about the conscious decisions you’ve made to protect your company's information. Each line item is a chapter in that story.

For example, stating that control A.8.28 ("Secure coding") is not applicable because you don’t develop any software in-house is a clear, defensible position. On the other hand, showing that control A.5.16 ("Identity management") is implemented and then linking it directly to your User Access Control Policy gives the auditor concrete proof of your diligence.

Without this central document connecting the dots, an auditor just sees a collection of disconnected activities. The SoA is what gives your security efforts structure, integrity, and a clear purpose.

How to Build Your Statement of Applicability

Let's be honest, building your first Statement of Applicability can feel daunting. But it's not about inventing something from scratch. Think of it as methodically logging the decisions you've already made during your risk assessment, creating a clear, auditable trail for every single security control.

Your starting point is always the same: ISO 27001:2022 Annex A. This is your master checklist, containing all 93 potential security controls. You absolutely must address every last one of them. Forgetting even one is a classic, and entirely preventable, reason for failing an audit.

The SoA is the critical bridge connecting your risk assessment to the final audit. It's where your risk treatment strategy gets translated into a concrete, verifiable security program.

As you can see, the SoA isn’t just paperwork. It’s the central document that proves you've done your homework.

Reviewing and Deciding on Each Control

With your list of 93 controls in hand, the real work begins. You'll go through them one by one, comparing each against your risk assessment report and your organization's unique needs. This isn't a job for one person locked in a room; you'll need to talk to department heads from IT, HR, legal, and operations to get the full picture.

For every control in Annex A, you simply need to answer one question: "Do we need this control to address one of our identified risks, or to meet a legal, regulatory, or customer requirement?"

• If you answer "Yes," the control is applicable. You'll then note its implementation status—is it fully in place, partially done, or on the roadmap?
• If you answer "No," the control is not applicable. This is where you must write a solid justification explaining why you're excluding it.

This justification is everything. Your auditor will absolutely zero in on your reasons for excluding controls. A vague excuse like "not relevant" or "too expensive" is a major red flag and will almost certainly result in a non-conformity.

Crafting Strong Justifications

Your justifications tell the story of your information security program. They show an auditor that your decisions were thoughtful and risk-based, not just arbitrary choices. A powerful justification ties the control—or lack thereof—directly to how your business operates.

Let's look at a couple of real-world examples.

Weak Justification (Exclusion):

• Control: A.8.28 - Secure coding
• Justification: "Not applicable to our business." (This is useless. It tells the auditor nothing.)

Strong Justification (Exclusion):

• Control: A.8.28 - Secure coding
• Justification: "This control is not applicable because our company does not develop any software in-house. All our business applications are commercial off-the-shelf (COTS) solutions managed by their respective vendors."

The same logic applies when you include a control.

Strong Justification (Inclusion):

• Control: A.5.16 - Identity management
• Justification: "Applicable and implemented. This control directly mitigates risks R-012 (Unauthorized Access to Customer Data) and R-015 (Privilege Escalation) from our risk assessment. Our implementation is detailed in the 'User Access Control Policy v2.1'."

This level of detail shows you have a mature and well-connected security system. Running an initial gap analysis can seriously accelerate this process by showing you where you already have evidence and which controls need more work. If you're new to this, our guide on how to conduct an effective ISO 27001 gap assessment is a great place to start.

Finally, for every single control you mark as "applicable" and "implemented," you must point to the evidence. This could be a link to a policy document, a procedure, a screenshot of a system setting, or a record of employee training. Linking your evidence turns the SoA into a practical roadmap for your auditor, making their job easier and your audit much smoother.

Structuring and Documenting Your SoA with Examples

Alright, let's move from theory to action. How do you actually build a Statement of Applicability? The most straightforward and universally accepted method is a simple table or spreadsheet. Don't overcomplicate it.

This format is your friend. It helps you, your team, and—most importantly—your auditor quickly see every decision you've made about the 93 Annex A controls. Think of it as the central dashboard for your security controls, where each row represents a control and the columns tell its story. An auditor should be able to glance at any row and instantly get the full picture: what the control is, if you’re using it, why you made that choice, and where to find the proof.

The Essential Columns for Your SoA

To create a solid, audit-proof SoA, you need a few key columns. These aren't just suggestions; they are the core components that demonstrate your due diligence. Skipping one is like leaving a required field blank on a form—it creates gaps and invites uncomfortable questions from your auditor.

For every single Annex A control, your SoA must include:

• Control Reference: The unique ID from Annex A, like A.5.1 or A.8.28. This is your checklist to ensure you haven't missed any of the 93 controls.
• Control Description: The official title from the standard, such as "Policies for information security" or "Secure coding."
• Applicability (Yes/No): A simple, direct "Yes" or "No." There's no room for ambiguity here.
• Justification: A short, clear reason for your "Yes" or "No" decision. This is where you directly connect the control back to your risk assessment or business needs.
• Implementation Status: The control's current state. Common statuses are "Implemented," "Partially Implemented," or "Not Started." Be honest.
• Link to Evidence: A direct reference or, even better, a hyperlink to the policy, procedure, record, or system setting that proves the control is working.

Putting these columns in place creates a complete record that’s easy to manage and completely transparent. Without them, your ISO 27001 statement of applicability just won't have the depth needed to pass an audit. For a closer look at all the controls, our article covering the complete ISO 27001 controls list is a great resource.

Example Statement of Applicability Entries

Seeing how it's done is the best way to learn. The table below shows how you might document two different controls—one you've chosen to implement and another you've decided to exclude. Pay close attention to the justification column; this is where you tell the story behind your decision.

As you can see, the SoA isn't just a dry list. It’s a narrative document that explains why your security program is structured the way it is. Every decision is grounded in your specific business needs and risk profile, which is exactly what an auditor wants to see.

Of all the documents in an ISO 27001 audit, the Statement of Applicability is the one that gets the most intense scrutiny. I've seen auditors find holes in a weak SoA in minutes, and those small mistakes can quickly escalate into non-conformities that jeopardize the entire certification.

The good news is that most of these errors are easy to sidestep once you know what to look for. The biggest mistake organizations make is treating the SoA like a bureaucratic checkbox exercise they rush through at the end. It's not just paperwork; it’s the core document that connects your risks to your controls.

Mismatched Documents and Vague Justifications

One of the first things an auditor will do is cross-reference your SoA with your risk assessment. This is where things often fall apart. If you claim a control is implemented to treat a risk, that risk better be clearly identified in your risk register. Any mismatch between these documents is an immediate red flag that suggests your ISMS is just a paper exercise.

Another major tripwire is how you justify excluding controls. This is a big one.

Simply writing "Not applicable" or "Too expensive" is the fastest way to get an auditor to start digging deeper. A proper justification needs to be a clear business reason that explains why the risk that control addresses doesn't exist in your company.

Think of it this way. You're not making an excuse; you're presenting a logical conclusion.

• Weak Justification: "We don't need this."
• Strong Justification: "Control A.8.28 (Secure coding) is excluded because our organization does not engage in any internal software development. All business applications are commercial off-the-shelf (COTS) products."

See the difference? The second one shows you’ve actually thought about it and understand your own environment.

Incomplete or Static Documentation

Your Statement of Applicability has to account for all 93 controls in Annex A. You can't just skip the ones you aren't using. The whole purpose of the document is to prove you've methodically considered every single one and made a deliberate choice for each.

It's also a mistake to think of the SoA as a "one-and-done" project. Your information security management system (ISMS) is a living thing, constantly adapting to new threats and business changes. Your SoA must be a living document that keeps pace.

Common Documentation Failures:

• No Version Control: If your SoA has no version history, it looks like you threw it together last week just for the audit. Always use clear versioning (like v1.0, v1.1, v2.0) and include a change log to demonstrate ongoing management.
• Dead-End Links: An SoA that just claims a control is "implemented" is useless without proof. For every single implemented control, you must link to the specific evidence—the policy, the procedure, or the technical report that proves it's in place and working.
• Stale Information: Did you roll out a new cloud service? Change a key process? Your SoA needs to reflect that. An outdated SoA tells an auditor that your entire ISMS is probably being neglected.

When you avoid these common pitfalls, your ISO 27001 Statement of Applicability goes from being a potential liability to your strongest asset in an audit. It becomes the clear, logical story of your security program, showing an auditor that every decision is intentional, justified, and grounded in a real understanding of your organization's risks.

Keeping Your SoA Current and Audit-Ready

One of the biggest mistakes I see companies make is treating their ISO 27001 statement of applicability as a one-and-done document. They work hard to get it finished for the initial certification, then file it away. But your SoA isn’t a trophy for the wall; it's a living document that has to change as your business changes.

Think of it like the maintenance log for a commercial airplane. You don't just check it once a year. It's reviewed constantly because conditions change, parts wear out, and new information comes to light. Your SoA needs that same level of regular attention to stay accurate and, more importantly, useful.

Showing up to an audit with an outdated SoA is a huge red flag. It immediately signals to the auditor that your entire Information Security Management System (ISMS) is probably gathering dust, too. It’s not a great first impression.

Triggers for SoA Review and Updates

Your Statement of Applicability has to keep pace with your organization, and certain events should automatically trigger a review. If you wait for your annual internal audit, you're waiting too long. Significant security gaps can open up much faster than that.

You should be pulling out your SoA for an immediate update whenever these things happen:

• You adopt new technology. Rolling out a new cloud platform, CRM, or any major software almost always changes which Annex A controls apply to your business.
• Your business processes change. If you launch a new product, expand into a different country, or alter how you handle customer data, your risks and controls need a fresh look.
• The threat landscape shifts. When a new type of cyberattack becomes prominent, you might need to implement controls you previously decided were out of scope.
• Your organization restructures. A merger, acquisition, or even just a major internal team shuffle can completely change your risk profile and who is responsible for which control.

An auditor can spot a stale SoA from a mile away. If your document makes no mention of the big cloud migration you completed six months ago, they know your ISMS processes are broken. Keeping it current isn't just good practice—it's essential for holding onto your certification.

Trying to manually track how all these business changes affect 93 different controls is a nightmare. It’s incredibly easy for your documentation to fall out of sync with what’s actually happening on the ground, leading to a last-minute panic before an audit and a high risk of non-conformities.

Using Automation to Stay Continuously Audit-Ready

This is where having the right tools makes all the difference. Instead of relying on a frantic, manual review once a year, you can use automation to keep your documentation and your real-world evidence aligned all the time.

For instance, some modern GRC platforms can monitor your collection of policies, procedures, and system configurations. When someone updates a document or adds a new one, the system can flag potential conflicts with your Statement of Applicability.

Imagine your IT team updates the User Access Control Policy. A smart system could automatically prompt you to review control A.5.16 (Identity management) in your SoA, just to confirm your justification and evidence links are still correct. This turns SoA maintenance from a painful annual project into a simple, ongoing background task.

By taking this approach, your ISO 27001 statement of applicability becomes a consistently accurate picture of your security posture. You're not just "ready" for the audit—you're always ready.

Frequently Asked Questions About the SoA

As you start piecing together your ISO 27001 Statement of Applicability, a few practical questions always seem to pop up. It's completely normal. Let's walk through some of the most common ones we hear, so you can move forward with confidence.

How Many Controls Do I Have to Implement?

There’s no magic number here. While you absolutely must review all 93 Annex A controls, the number you end up implementing is driven entirely by your own risk assessment and business needs.

A small software startup will have a very different control set than a multinational bank. The key isn't the quantity of controls you implement; it's the quality of your justification. For every single one of those 93 controls, you need a clear, logical reason for your decision—whether you're including it or excluding it. An auditor is far more interested in seeing your thought process than a specific count.

What Is the Difference Between the SoA and the Risk Treatment Plan?

This is easily the most common point of confusion, but it's simpler than it sounds. Think of it this way:

• The Risk Treatment Plan (RTP) is your action plan. It zeroes in on the specific risks you've decided to treat and details how you're going to fix them. It’s essentially a project plan for reducing your highest-priority risks.
• The Statement of Applicability (SoA) is your official declaration. It's a comprehensive document that lists all 93 Annex A controls and states your organization's position on each one, regardless of whether it's linked to a specific, high-priority risk.

The RTP answers the question, "How are we fixing our biggest problems?" The SoA, on the other hand, answers, "What is our formal stance on every control in the Annex A catalog?" They are two sides of the same coin, and you need both.

Can I Use a Template for My Statement of Applicability?

Yes, and you absolutely should! Using a template for the structure of your SoA is a best practice. It ensures all the required columns are there (control ID, justification, implementation status, etc.) and presents the information in a clean, consistent way that auditors appreciate.

But here’s the critical part: the content must be 100% yours. Copying and pasting justifications from a template or another company is a fatal flaw. An auditor will spot that a mile away, and it instantly undermines the credibility of your entire ISMS. The whole point of the SoA is to prove you've done the work of analyzing your own unique environment.

How Often Should I Update My SoA?

Your Statement of Applicability is a living document, not a "set it and forget it" task. At a minimum, it must be reviewed and formally signed off on at least annually.

More importantly, you should update it any time there's a significant change in your business. This could be anything from launching a new product, migrating to a new cloud platform, onboarding a major vendor, or even adapting to new threats you've observed in your industry. An outdated SoA is a major red flag for an auditor because it suggests your entire security management system has fallen out of sync with your business reality.

Stop wasting time manually digging for evidence and cross-referencing documents. AI Gap Analysis automates the tedious work of creating your Statement of Applicability by reading all your policies and procedures, mapping them to Annex A controls, and highlighting gaps instantly. Get started with your first AI-powered analysis today at https://ai-gap-analysis.com.