The Statement of Applicability: Why 60% of Organizations Get This Critical ISO 27001 Document Wrong

The auditor opened our Statement of Applicability, spent about ninety seconds reviewing it, and said “We need to talk about your control exclusions.” I knew we were in trouble.

This was about five years ago, consulting for a healthcare software company going through their first ISO 27001 certification. They’d spent months building their ISMS, documented everything, implemented controls across the board. But their Statement of Applicability was a disaster, and it was about to derail their entire audit.

The Statement of Applicability – usually called the SoA – is one of the most critical documents in your ISO 27001 certification, and somehow it’s also one of the most misunderstood. I’ve reviewed probably a hundred SoAs over the years, and I’d estimate that 60% of them have fundamental problems that will cause issues during certification.

Let’s talk about what this document actually is, why it matters so much, and the three mistakes that keep sinking audits.

**What the Statement of Applicability Actually Is**

The SoA is essentially your organization’s declaration of which Annex A controls you’re implementing and why. Annex A of ISO 27001:2022 contains 93 security controls organized into four themes. Your job is to go through each one and state whether it’s applicable to your organization or not.

If it’s applicable, you need to explain how you’re implementing it. If it’s not applicable, you need to justify why you’re excluding it.

Sounds straightforward. It’s not.

The SoA is required by Clause 6.1.3 of ISO 27001, which focuses on information security risk treatment. The standard explicitly requires you to produce a Statement of Applicability that includes the necessary controls and justification for inclusions (whether they’re implemented or not) and justification for exclusions.

This document serves several purposes. First, it’s the bridge between your risk assessment and your actual security controls. Your SoA should flow logically from the risks you identified. Second, it’s a quick reference for auditors to understand your security posture without reading through 25 separate policy documents. Third, it becomes your roadmap for implementation – it’s hard to forget about a control when it’s explicitly listed in your SoA.

The problem is that most organizations treat the SoA as a checkbox exercise rather than a strategic document. They either mark everything as applicable (even when it’s not) to avoid justifying exclusions, or they exclude half the controls with lazy justifications that auditors will never accept.

**Mistake #1: Excluding Controls Without Valid Justification**

This is the most common problem I see, and it’s what tripped up that healthcare software company.

Organizations look at the 93 Annex A controls and think “We’re a small company, we don’t need all of these.” So they start marking controls as “not applicable” without really thinking through whether that’s defensible.

Here’s a real example from an SoA I reviewed last year. The organization had marked Control 5.7 (Threat Intelligence) as not applicable with the justification: “We are a small organization and don’t have resources for threat intelligence.”

That’s not a valid justification. The control isn’t asking you to build a threat intelligence team or subscribe to expensive threat feeds. It’s asking you to have some mechanism for staying informed about relevant security threats. That could be as simple as monitoring vendor security bulletins, subscribing to CISA alerts, or following industry security news.

The size of your organization or your resource constraints don’t make a control not applicable. Those factors might affect how you implement the control, but they rarely justify complete exclusion.

Valid justifications for exclusion are actually pretty narrow. A control is not applicable when:

The control addresses a risk that genuinely doesn’t exist in your environment. For example, if you don’t have any physical offices (fully remote company), you might reasonably exclude some of the physical security controls. If you don’t store any payment card data, some PCI-related controls might not apply.

The control is already fully addressed by another control you’ve implemented. This is called “covered elsewhere” and needs to be documented clearly. For instance, if your general access control policy fully addresses the requirements of a specific access-related control, you might reference that.

Your regulatory or contractual obligations prohibit the control. This is rare, but it happens. For example, certain data retention controls might conflict with legal requirements to preserve data.

Here’s what’s not a valid justification: “We don’t want to do this,” “This seems expensive,” “We’ll implement this later,” or “We’re too small for this control.”

When the auditor reviewed that healthcare company’s SoA, they’d excluded 23 controls. Of those 23, maybe 3 had legitimate justifications. The other 20 were variations of “we’re small” or “not a priority right now.” The auditor made them go back and either implement those controls or provide real justifications. It added six weeks to their certification timeline.

**Mistake #2: Weak Implementation Descriptions**

The flip side of over-excluding is marking everything as applicable but then providing useless descriptions of how you’re implementing the controls.

Your SoA needs to include implementation information for applicable controls. This doesn’t have to be exhaustive – you’re not rewriting your policies in the SoA. But it needs to be specific enough that an auditor understands what you’re actually doing.

Bad implementation description: “We have implemented appropriate access controls to ensure security.”

This tells the auditor nothing. What access controls? How are they implemented? Where are they documented? This is the kind of vague statement that makes auditors dig deeper and start asking uncomfortable questions.

Better implementation description: “User access is managed through role-based access controls in our Identity Management system. Access requests follow our documented Access Control Policy (POL-005). Access reviews are conducted quarterly by system owners per section 4.2 of the policy.”

This gives the auditor specific information. They know where to look for the policy, they understand the basic approach, and they know how you’re maintaining ongoing compliance.

The description should answer three questions: What control are you implementing? How are you implementing it? Where is it documented?

You don’t need paragraphs of detail. Two to three sentences is usually sufficient. But those sentences need to contain actual information, not generic security platitudes.

I’ve seen SoAs where every single control had essentially the same description: “Implemented according to organizational policy.” That’s not helpful to anyone. It suggests the person writing the SoA didn’t actually understand the controls or how the organization was addressing them.

**Mistake #3: Misalignment With Your Risk Assessment**

This is the sophisticated mistake that catches organizations who think they’ve done everything right.

Your Statement of Applicability should flow from your risk assessment. The controls you implement should address the risks you identified. If your risk assessment says “unauthorized access to customer data” is a major risk, your SoA better show robust implementation of access controls, authentication controls, and monitoring controls.

Where this breaks down is when organizations treat the risk assessment and the SoA as separate exercises done by different people at different times. The risk assessment happens in month three. The SoA gets written in month seven. Nobody checks whether they’re aligned.

The result is an SoA that implements controls for risks you didn’t identify, or fails to implement controls for risks you did identify. Auditors spot this immediately because they’re reviewing both documents and looking for that logical flow.

I worked with a financial services company whose risk assessment identified third-party vendor risk as one of their top three concerns. Their SoA marked the supplier relationship controls (Annex A 5.19 through 5.23) as “low priority” with minimal implementation. The auditor asked the obvious question: “Your risk assessment says vendor risk is critical, but your SoA suggests you’re barely addressing it. Which one is accurate?”

They couldn’t give a good answer because the documents had been created independently without reconciliation. They had to go back, redo the supplier controls, update the SoA, and resubmit. Another month of delay.

The fix for this is straightforward: when you’re creating your SoA, have your risk assessment open next to you. For each control, ask yourself whether it addresses a risk you identified. If it does, that control is probably applicable and should be implemented. If your risk assessment doesn’t show any risks that the control addresses, you need to think carefully about whether it’s truly not applicable or whether your risk assessment missed something.

**The “We’ll Implement Everything” Trap**

Some organizations, trying to avoid the justification problem, decide to just mark all 93 controls as applicable and implement everything. This seems safe. It’s actually problematic.

First, implementing controls you don’t need is a waste of resources. If you’re a software company with no physical inventory, implementing detailed controls for physical asset tracking doesn’t add value. It just creates documentation burden and things to maintain that don’t improve your security posture.

Second, auditors get suspicious when they see 100% control implementation, especially for smaller organizations. It suggests you didn’t actually do a thoughtful risk-based analysis. You just checked all the boxes to avoid making decisions.

Third, and this is the practical issue, you’re committing to maintain all those controls through surveillance audits. That means evidence, documentation, and ongoing compliance for controls that aren’t relevant to your business. It’s sustainable for about six months. Then things start falling apart because your team can’t keep up with the overhead.

A good SoA for a typical mid-size organization usually has 75-85 of the 93 controls marked as applicable. The excluded ones should have clear, legitimate justifications. The implemented ones should have specific descriptions that connect to your policies and procedures.

If you’re at 93 out of 93, you probably haven’t thought hard enough about applicability. If you’re at 60 out of 93, you’re probably over-excluding and need to reconsider some of your justifications.

**The Cross-Reference Problem**

Your SoA also needs to reference where each control is documented and implemented. This is usually done through a cross-reference to specific policies, procedures, or system configurations.

Most organizations handle this poorly. They either provide no cross-references at all, or they provide generic references that aren’t helpful.

Unhelpful: “See Information Security Policy”

Better: “See Access Control Policy (POL-003), Section 4.2; implemented via Active Directory group policies”

The cross-reference should be specific enough that someone could actually find the relevant documentation without searching through your entire policy library.

This is also where you catch misalignments. If you’re marking a control as implemented but you can’t identify where it’s documented, that’s a red flag. Either you haven’t actually implemented it, or your documentation is incomplete. Both are problems that need to be fixed before the audit.

**The Living Document Myth**

Organizations often treat the SoA as a static document that gets created once for certification and then sits untouched until the next audit. This is wrong.

Your SoA should be reviewed and updated at least annually, and whenever there are significant changes to your business, technology environment, or risk landscape. New risks emerge. New controls become applicable. Controls that were applicable might become irrelevant as your business changes.

If you’re still using the same SoA three years later with zero updates, you’re doing it wrong. Your business has changed. Your technology has changed. Your SoA should reflect that.

During surveillance audits, auditors will often ask whether the SoA has been reviewed and updated. If you haven’t touched it since certification, that’s a minor finding waiting to happen. If you have updated it, you need evidence of that review – meeting minutes, documented decisions, version control showing the updates.

This is another area where having templates and frameworks helps. When you’re starting from well-structured templates, updating your SoA to reflect changes is much easier than if you’re trying to maintain custom-built documentation.

**Getting It Right**

Creating a good Statement of Applicability isn’t complicated, but it does require thought and attention to detail.

Go through each Annex A control individually. Don’t batch them. Don’t assume a category of controls is all applicable or all not applicable. Evaluate each one against your specific environment and risks.

For each control, ask three questions: Does this address a risk in my environment? Am I already doing something that satisfies this control? Can I implement this control in a way that’s sustainable for my organization?

If the answer to question one is “no” and you’re certain about it, the control might not be applicable. Document why the risk doesn’t exist in your environment.

If the answer to question two is “yes,” describe what you’re doing and where it’s documented.

If the answer to question three is “no,” you probably need to rethink either your implementation approach or your business model, because ISO 27001 controls are designed to be achievable for organizations of any size.

Write clear, specific descriptions. Reference actual policies by name and section number. Be honest about implementation status – if you’re implementing a control but it’s not yet complete, say so and document your timeline.

Review the completed SoA against your risk assessment. Make sure the controls you’re implementing actually address your identified risks. Make sure you’re not missing controls for significant risks.

Have someone who wasn’t involved in writing it review it for clarity. If they can’t understand what controls you’re implementing and why, an auditor won’t either.

Your Statement of Applicability is not just another ISO 27001 document. It’s the core of your ISMS. It shows auditors, customers, and partners what security controls you’ve committed to implementing. A poorly constructed SoA will cause problems during certification and create ongoing compliance headaches.

The good news is that this is a solved problem. The structure of a compliant SoA is well-established. The Annex A controls are clearly defined. You don’t need to figure this out from scratch.

Our ISO 27001 policy package includes a complete Statement of Applicability template with all 93 Annex A controls already mapped out. It includes example justifications for common exclusions, implementation description templates, and cross-references to the included policies. You can customize it for your specific environment in a few hours instead of spending weeks trying to build it yourself.

Check it out at [CyberPolicyPro.com](http://CyberPolicyPro.com). Get your SoA right the first time and avoid the mistakes that derail audits.