Documentation & SoA

How to Justify Control Exclusions Without Getting Flagged

Alex Fuerst

15 Nov 2025 — 6 min read

Understanding What ISO 27001:2022 Actually Requires

Every Statement of Applicability I review contains at least one exclusion that makes me raise an eyebrow. Not because organizations shouldn't exclude controls—they absolutely can and should when justified—but because most exclusions read like someone wanted to avoid the work rather than genuinely assess the risk.

Let me be clear: ISO 27001 does not require you to implement every Annex A control. What it requires, per Clause 6.1.3(e), is that you determine which controls are necessary and justify why others are not applicable. The standard explicitly states that your Statement of Applicability must include "justification for inclusions, whether they are implemented or not" and "justification for exclusions of Annex A controls."

The 2022 revision reorganized the 93 controls into four themes: organizational, people, physical and environmental, and technological. This consolidation actually makes justification more challenging. Controls are broader in scope now. Take Control 8.1 (User endpoint devices)—it's not just about corporate laptops anymore. It encompasses mobile devices, tablets, IoT devices, and any user-operated technology connecting to your systems. Excluding it requires demonstrating that absolutely none of these exist in your environment.

Good luck with that in 2024.

The Three Categories of Legitimate Exclusions

In fifteen years of auditing, I've seen defensible exclusions fall into three categories. If your exclusion doesn't fit one of these, you're probably reaching.

1. Technology or Service Model Exclusions

These are the cleanest exclusions to justify. If you genuinely don't use a technology or operate a service, the associated controls may not apply. For example, if your organization operates purely as a distributed company with no physical premises beyond a registered office address—no data centers, no offices, no meeting rooms—then certain physical security controls under the Physical and Environmental theme might legitimately not apply.

But here's where organizations get sloppy: partial applicability isn't non-applicability. I recently audited a SaaS company that excluded Control 7.8 (Equipment maintenance) claiming they had "no physical equipment." Yet their office had servers, network equipment, and workstations requiring maintenance. The control applied—they just needed to implement it through their facilities management contract and endpoint management policies.

The same logic applies to Control 8.20 (Networks security management). I've had organizations claim this doesn't apply because "we're fully cloud-based." But they have corporate WiFi networks, VPNs, and network segments even if those segments live in AWS. Network security controls apply—you implement them through cloud security groups and VPC configurations rather than traditional firewalls.

2. Contractual or Regulatory Constraints

Sometimes external requirements make certain controls impossible or unnecessary. If you operate under a regulatory framework that explicitly prohibits certain activities, you can exclude controls that require those activities. This is rare outside of highly regulated industries.

More commonly, you might exclude controls demonstrably handled by a third party under contract. If you use a SaaS provider for all data storage and your contract includes their responsibility for backup management, you might partially exclude Control 8.13 (Information backup)—but only the portions they handle. You still need to verify they're doing it, include this in your supplier management under Control 5.19, and maintain backup procedures for anything not covered.

I've seen organizations try to exclude Control 8.31 (Separation of development, test and production environments) because their cloud provider manages the infrastructure. Wrong. The control applies to your application environments, not just the underlying infrastructure. Your provider might handle server separation, but you're still responsible for database schemas, application configurations, and data segregation.

3. Risk-Based Exclusions with Compensating Controls

This is where most organizations either shine or embarrass themselves. ISO 27001 is fundamentally risk-based. If you've conducted a proper risk assessment per Clause 6.1.2 and determined that certain threats don't apply to your environment, you might exclude related controls—but only if you can demonstrate equivalent risk treatment through other means.

For instance, a software company with no mobile workforce might exclude Control 6.7 (Remote working) if they can prove all work happens from fixed locations with appropriate security. But they need compensating controls for similar risks: secure network access policies, endpoint management for office devices, and clear guidelines for any exceptional remote access.

Auditor's perspective: Risk-based exclusions require the most rigorous documentation. I'm looking for risk assessment outputs that explicitly identify why certain threat scenarios don't apply, plus evidence of alternative controls addressing related risks. Hand-waving about "low risk" without supporting analysis won't pass scrutiny.

Common Exclusion Mistakes That Trigger Findings

Let me share some real examples from recent audits (details anonymized, naturally).

The "We Don't Have That" Trap

A professional services firm excluded Control 8.1 (User endpoint devices) claiming they "don't provide company devices." During the audit, I discovered executives using personal iPads for email, consultants accessing client data from personal laptops, and a BYOD policy buried in their employee handbook. The control absolutely applied—they just didn't want to manage it properly.

The fix wasn't excluding the control. It was implementing mobile device management for any device accessing company data, regardless of ownership.

The Cloud Confusion

A growing trend is organizations thinking cloud adoption eliminates physical security requirements. One client excluded multiple Physical and Environmental controls claiming they were "100% cloud-based." Yet they had an office with servers for development, network equipment, and workstations storing sensitive data locally.

Cloud services might reduce your physical security footprint, but they rarely eliminate it entirely. Even fully remote organizations often have home offices, coworking spaces, or meeting locations that require physical security considerations.

The Regulatory Misunderstanding

A healthcare organization excluded Control 8.16 (Management of privileged access rights) claiming HIPAA requirements made it "unnecessary." This showed a fundamental misunderstanding. HIPAA actually requires stricter access controls, not fewer. The control was highly applicable—they needed to implement it with healthcare-specific considerations.

Cross-reference healthcare compliance requirements to understand how ISO 27001 complements rather than conflicts with sector-specific regulations.

What Auditors Actually Look For

When reviewing exclusions, I'm looking for specific evidence:

Risk Assessment Traceability

Every exclusion should trace back to your risk assessment. If you've excluded Control 5.23 (Information security for use of cloud services), I want to see risk assessment outputs showing you either don't use cloud services or have identified why related risks don't apply to your environment.

Business Justification

Generic statements like "not applicable to our business model" aren't sufficient. I need specific explanations. If you've excluded Control 6.8 (Information security in project management), explain why: "Our organization operates solely through managed services contracts with no internal project development. All project management activities are performed by suppliers under contracts that include information security requirements managed through Control 5.19."

Compensating Control Evidence

For risk-based exclusions, show me how you're addressing similar risks through other controls. If you've excluded certain access management controls due to your architecture, demonstrate how your remaining controls provide equivalent protection.

Regular Review Documentation

Exclusions aren't permanent. Your Statement of Applicability should show when exclusions were last reviewed and what triggered the review. Business changes, new technologies, or risk reassessments might make previously excluded controls applicable.

Pro tip: I recommend reviewing exclusions during your annual management review (Clause 9.3) and documenting the outcome. This demonstrates the continual improvement required by the standard and shows you're actively managing your control framework.

Documentation That Survives Scrutiny

Your Statement of Applicability needs more than checkboxes and brief justifications. Here's what works:

For Technology Exclusions

"Control 8.31 (Separation of development, test and production environments) is excluded because our organization operates exclusively through configuration management of third-party SaaS platforms. No custom development activities occur within our environment. All system modifications are performed through vendor-managed update processes covered under supplier management (Control 5.19)."

For Risk-Based Exclusions

"Control 6.7 (Remote working) is excluded based on risk assessment RA-2024-001, which identified that all personnel work exclusively from our secure office facility. Network access controls (Control 8.20) and physical security measures (Control 7.1) provide equivalent protection for the identified work-from-home threat scenarios. This exclusion will be reviewed if business operations change to include remote work."

For Contractual Exclusions

"Control 8.13 (Information backup) is partially excluded for cloud-hosted data. Our cloud service provider assumes responsibility for infrastructure backup per contract CSP-2024-01, Section 4.2. This arrangement is managed through supplier evaluation processes (Control 5.19). Local data backup requirements remain applicable and are implemented through Policy DS-001."

The Cross-Standard Connection

Don't forget to consider related standards when justifying exclusions. If you're excluding cloud-related controls, reference ISO 27017 guidance to ensure you're not missing cloud-specific considerations. For privacy-related exclusions, check ISO 27018 requirements. Supply chain exclusions should align with ISO 27036 principles.

These cross-references strengthen your justification and demonstrate comprehensive risk consideration beyond the base ISO 27001 requirements.

Making Exclusions That Stick

The difference between a defensible exclusion and an audit finding comes down to honest assessment, clear documentation, and regular review. Your exclusions should reflect genuine business reality, not wishful thinking about the controls you'd rather not implement.

Remember: the goal isn't to minimize your control set. It's to implement the right controls for your risk environment. Sometimes that means fewer controls than you expected. Sometimes it means more. But it always means being honest about what applies to your organization.

If you're struggling with control applicability decisions or want to validate your exclusion justifications before your next audit, consider connecting with experienced practitioners. The IX ISO 27001 Info Hub provides access to implementation guidance and expert perspectives on complex applicability questions.

Need personalized guidance? Reach our team at ix@isegrim-x.com.