ISO 27001 Statement of Applicability (SoA): Creation and Management

I still remember the moment during my first ISO 27001 audit when the lead auditor asked to see our Statement of Applicability. I confidently handed over a 47-page document that my team had spent three months creating. She flipped through it, raised an eyebrow, and said something that changed how I approach compliance forever:

"This is comprehensive. But can anyone actually use it?"

That question hit me like a freight train. We'd created a document that checked all the boxes but served no practical purpose. It was a compliance artifact, not a living tool. Over the next fifteen years, I've helped over 60 organizations create SoAs that actually work—documents that guide security decisions, survive audits, and evolve with the business.

Let me show you how to do it right.

What Is a Statement of Applicability (And Why Most People Get It Wrong)

The Statement of Applicability is your organization's declaration of which ISO 27001 Annex A controls you've implemented, which ones you haven't, and—critically—why you made those decisions.

Think of it as your security program's constitution. It's the single document that explains your entire approach to information security.

Here's the official definition: The SoA is a mandatory documented information requirement in ISO 27001 that lists all controls from Annex A, states whether they're applicable or not, documents the justification for inclusion or exclusion, and shows whether they're already implemented.

But here's what nobody tells you: the SoA isn't really for the auditors. It's for you.

"A great Statement of Applicability is a roadmap that shows where you are, where you're going, and why you chose that particular journey."

The Four Critical Elements Every SoA Must Have

After reviewing hundreds of SoAs, I've found that effective ones always include these four elements:

I learned the hard way that missing any of these elements will either fail your audit or—worse—create a document that provides zero value to your organization.

The Painful Truth About ISO 27001 Annex A Controls

ISO 27001:2022 contains 93 controls across four themes (Organizational, People, Physical, and Technological). The 2013 version had 114 controls across 14 domains. If you're updating from the old standard, you've got work to do.

Let me break down what you're dealing with:

ISO 27001:2022 Control Structure

Here's a reality check from my experience: most organizations will find 85-92% of controls applicable. If you're marking more than 15% as "not applicable," you're either in a very unique situation, or you're trying to cut corners.

I once audited a financial services company that marked 28 controls as not applicable. Their justification? "We're a small company." That's not a justification—it's an excuse. Size doesn't exempt you from access control or incident management. They failed their certification audit spectacularly.

Creating Your SoA: The Method That Actually Works

Let me walk you through the process I've refined over fifteen years and dozens of successful certifications.

Phase 1: Scoping and Context (Weeks 1-2)

Before you touch a single control, you need to understand your organization's context. I've seen companies waste months creating SoAs for the wrong scope.

Critical questions to answer:

1. What's in scope for your ISMS?

   • Which locations?

   • Which departments?

   • Which systems and data?

   • Which processes?

2. What are your business objectives?

   • Growth plans

   • Market positioning

   • Customer requirements

   • Regulatory obligations

3. What's your risk appetite?

   • How much risk can you accept?

   • What are your critical assets?

   • What are your biggest threats?

I worked with a healthcare SaaS company in 2022 that initially scoped their entire organization—12 locations, 400 employees. After context analysis, we narrowed it to their production environment and customer data handling processes. They achieved certification in 8 months instead of 18, and with one-third the cost.

"Scope creep kills compliance projects. Start focused, prove success, then expand. Don't try to boil the ocean on day one."

Phase 2: Risk Assessment Integration (Weeks 3-5)

Here's where most people mess up: they treat the SoA as separate from risk assessment. The SoA should be driven by your risk assessment results.

Here's my process:

Step 1: Conduct Your Risk Assessment

• Identify assets and their value

• Identify threats and vulnerabilities

• Assess likelihood and impact

• Determine risk levels

Step 2: Map Risks to Controls

• Which controls mitigate which risks?

• Are there risks requiring multiple controls?

• Are there controls addressing risks outside your top priorities?

Step 3: Make Applicability Decisions

• If a control mitigates a high or medium risk → Applicable

• If a control is legally/contractually required → Applicable

• If a control addresses only low risks and isn't required → Consider excluding (carefully)

Let me show you a real example. I worked with a fully remote company with no physical offices. Here's how they handled Physical Controls:

Notice the specificity? That's what auditors want to see. Not "we don't have offices," but "we're fully remote, here's where our infrastructure lives, and here's how we handle the remaining physical risks."

Phase 3: Control-by-Control Analysis (Weeks 6-10)

This is where the rubber meets the road. You need to go through every single control and make a decision.

Here's my template for control analysis:

Control Analysis Framework

For each control, document:

1. Control Description - What does the control require?

2. Current State - What are we doing today?

3. Gap Analysis - What's missing?

4. Risk Context - What risks does this address?

5. Business Context - How does this align with business needs?

6. Decision - Applicable or Not?

7. Justification - Why did we make this decision?

8. Implementation Plan - If applicable, how/when will we implement?

Let me show you real examples from organizations I've worked with:

Example 1: Access Control (Technological Control 5.15 - Access Control)

Example 2: Equipment Maintenance (Physical Control 7.13)

Notice the difference in detail? The applicable control has a complete implementation plan. The non-applicable control has a thorough explanation of why it doesn't apply and what addresses the underlying risk instead.

The Justification Trap: What Auditors Actually Look For

I've seen auditors reject SoAs because of poor justifications more than any other reason. Let me show you what works and what doesn't.

Bad Justifications (That Will Fail Your Audit)

Good Justifications (That Pass Audits)

"A justification should tell a story: Here's what the control is trying to achieve, here's our situation, here's why the control doesn't apply to us, and here's how we're managing the underlying risk anyway."

Implementation Status: The Timeline That Actually Works

Once you've determined a control is applicable, you need to show implementation status. Here's how I categorize it:

Implementation Status Levels

Here's a reality check from 15 years of experience: For certification, you need 100% of applicable controls either fully implemented or partially implemented with a credible remediation plan.

You cannot certify with "not implemented" controls unless they're genuinely not applicable.

The Implementation Roadmap I Use

When working with clients, I create a visual roadmap that shows implementation status and timeline:

Sample Implementation Dashboard (Q1 2025 - Q4 2025)

This gives leadership a clear picture of progress and helps prioritize resources.

The Living Document: Managing Your SoA Over Time

Here's where most organizations fail: they treat the SoA as a one-time deliverable. They spend months creating it, pass their audit, then put it on a shelf and forget about it.

Your SoA should be reviewed and updated at least quarterly, and definitely whenever:

• Your organization's scope changes (new locations, services, or systems)

• You conduct a risk assessment and identify new risks

• Your business model evolves significantly

• Regulatory requirements change

• Technology infrastructure changes substantially

• Audit findings require control modifications

The Quarterly Review Process That Works

I implement this process with every client:

Quarter 1 (January-March): Deep Review

• Full risk assessment review

• Complete SoA review against current state

• Update implementation status for all controls

• Identify gaps and create remediation plans

• Budget planning for next 12 months

Quarter 2 (April-June): Implementation Focus

• Progress check on remediation plans

• Update status for controls under implementation

• Review any business changes affecting scope

• Prepare for mid-year management review

Quarter 3 (July-September): Validation

• Internal audit of control effectiveness

• Evidence collection for implemented controls

• Gap analysis for surveillance audit

• Address any non-conformities

Quarter 4 (October-December): Preparation

• External surveillance audit preparation

• Final evidence package compilation

• SoA updates for auditor review

• Annual metrics and reporting

Change Management for Your SoA

I worked with a fast-growing fintech company that went from 50 to 300 employees in 18 months. Their original SoA became obsolete within months. We implemented a change management process:

SoA Change Request Process:

This keeps the SoA current without requiring constant full reviews.

Common SoA Mistakes (And How to Avoid Them)

After reviewing hundreds of SoAs, I see the same mistakes repeatedly. Let me save you the pain:

Mistake #1: Copy-Paste from Templates

I can spot a templated SoA from a mile away. Generic justifications like "This control ensures security of our assets" tell me nothing about your organization.

The Fix: Every justification should be specific to YOUR organization. Mention your technology stack, your business model, your specific risks.

Mistake #2: Confusing Applicability with Implementation

I see this constantly:

• "Control is not applicable because we haven't implemented it yet"

• "Control is applicable but we'll implement it later"

These show a fundamental misunderstanding of the SoA.

The Fix:

• Applicability = Does this control make sense for our organization?

• Implementation = Have we actually put this control in place?

They're completely separate questions.

Mistake #3: No Risk Connection

Many SoAs list controls without explaining which risks they mitigate. This makes the whole document feel arbitrary.

The Fix: Link every applicable control back to specific risks from your risk assessment. This shows auditors you're making risk-based decisions.

Mistake #4: Vague Implementation Plans

"We plan to implement this control in the future" is worthless.

The Fix: Include:

• Specific implementation date (Quarter/Year minimum)

• Assigned owner

• Budget allocation

• Dependencies

• Success criteria

Mistake #5: Excluding Too Many Controls

If you've marked 20+ controls as not applicable, auditors will scrutinize every single one.

The Fix: Be conservative. If you're unsure, mark it applicable and implement. It's better to have a strong control program than to argue about exclusions.

Tools and Technology: What Actually Helps

You don't need fancy software to create a great SoA, but the right tools can make management much easier.

Options I've Used Successfully

My Recommendation: Start with Excel/Sheets for your first draft. Once you've been through the process and understand what you need, evaluate whether a specialized tool adds value.

I worked with a 40-person company that spent $60K on a GRC platform before they understood their requirements. They ended up using 20% of the features and still needed spreadsheets for actual work.

The SoA Template That Works

After creating dozens of SoAs, here's the structure I use:

Document Structure

1. Introduction
   1.1 Purpose and Scope
   1.2 Document Control Information
   1.3 Approval and Review Schedule

Real-World Example: The SoA That Saved a Certification

Let me tell you about a company that almost lost their certification because of a poor SoA.

A manufacturing company came to me three weeks before their surveillance audit. Their SoA was a mess—copy-pasted justifications, vague implementation status, no connection to their actual security practices.

We did an emergency overhaul in 10 days:

Day 1-3: Context and Risk Review

• Interviewed stakeholders to understand actual practices

• Reviewed their risk register

• Mapped current controls to risks

Day 4-7: Control-by-Control Rebuild

• Documented what they were actually doing

• Created specific justifications based on their infrastructure

• Updated implementation status with evidence references

• Linked controls to risk mitigation

Day 8-10: Evidence Package

• Created evidence map showing where proof exists for each control

• Updated policies to match SoA commitments

• Prepared auditor presentation

Result: They passed their surveillance audit with only two minor observations. The lead auditor specifically noted the quality of their SoA.

The lesson? Your SoA should reflect reality, not aspiration. It's better to document what you actually do well than to claim things you don't.

The Hard Truth About SoA Quality

After fifteen years, here's what I know: A great SoA is boring to read but invaluable to use.

It's not supposed to be exciting. It's not supposed to win writing awards. It's supposed to be:

• Accurate - Reflects what you actually do

• Specific - Uses your terminology, your systems, your risks

• Actionable - Guides implementation decisions

• Maintainable - Can be updated without complete rewrites

• Auditable - Provides clear evidence trail

If your SoA checks these boxes, you've succeeded.

"The best Statement of Applicability is one that your security team references weekly, not just when auditors come calling."

Your Action Plan: Creating an SoA in 90 Days

If you're starting from scratch, here's the realistic timeline I use:

90-Day SoA Development Plan

Total Effort: ~250 hours over 13 weeks

For a dedicated team of 2-3 people, this is achievable. For a solo CISO wearing multiple hats, extend to 16-20 weeks.

Final Thoughts: The SoA as Strategic Asset

Here's something that took me years to fully appreciate: Your Statement of Applicability is actually a strategic document.

It tells the story of how your organization thinks about security. It shows your risk priorities. It demonstrates your commitment to protecting what matters.

I've seen SoAs help organizations:

• Win enterprise contracts by demonstrating security maturity

• Negotiate better cyber insurance rates

• Streamline vendor security assessments

• Guide security budget allocation

• Onboard new security team members

• Make build-vs-buy decisions for security tools

The companies that treat their SoA as a living strategic document see it become the backbone of their security program. The ones that treat it as an audit checklist wonder why their security program feels disjointed and reactive.

Your choice.

What's Next?

Creating a Statement of Applicability is just one piece of the ISO 27001 puzzle. In upcoming articles, I'll dive deep into:

• Risk assessment methodologies that actually work

• Building an effective internal audit program

• Management review: turning compliance into business value

• Surveillance audits: what auditors really look for

But start with your SoA. Get it right, and everything else becomes easier.

Because at the end of the day, your SoA is your security program's promise to the world. Make it a promise you can keep.

Need help creating or improving your Statement of Applicability? At PentesterWorld, we provide practical, experience-based guidance on ISO 27001 implementation. Subscribe to our newsletter for templates, checklists, and real-world examples from 15+ years in the trenches.