Defining the scope of your information security management system (ISMS) has become a bit of a rocket science. If you make the scope too small, it has little purpose and risks to get rejected. If you make it too big, you’ll pay a lot during implementation and have higher risk for a failed audit.
In the world of ISO 27001 compliance software, scope is where most projects either find their footing or start their slow descent into madness.
1. Introduction , Why Scope Is One of the Most Important Decisions in ISO 27001
Most ISO 27001 problems don't start with a weak firewall or a forgotten password; they start with a badly designed scope. It is the foundation of your entire security posture. If the foundation is cracked, the house, no matter how many expensive locks you put on the doors, is going to lean.
Your scope choice isn't just a sentence on a certificate; it directly dictates:
- Risk Assessment: You can't assess what you haven't defined as "in."
- Applicability of Controls: If a system is out of scope, you technically don't have to apply Annex A controls to it (spoiler: auditors hate this one simple trick).
- Audit Complexity: A larger scope means more days, more interviews, and more evidence.
- Certification Cost: More days = more money paid to your certification body.
- Customer Trust: If your certificate only covers your "breakroom vending machine," your enterprise customers won't be impressed.
Common Misconceptions
We see the same three myths every week:
- “Everything must be enterprise-wide”: No, you don't have to certify the marketing department's Pinterest account if it doesn't touch critical data.
- “We can exclude difficult areas without consequences”: Exclude HR? Sure. But when the auditor asks how you vet the admins who have keys to the production kingdom, you’re in trouble.
- “Certification scope and ISMS scope are separate things”: They aren't. Your certificate is a reflection of the ISMS that was actually audited. If you try to market a "company-wide" cert when you only audited a single SaaS app, you're flirting with a PR disaster.
A Simple Reality Check: Imagine a SaaS company that certifies only its production platform. It looks great on paper, until the auditor realizes that corporate Identity and Access Management (IAM) controls access to that production environment. Suddenly, the auditor is poking around central IT operations, and the "narrow" scope has just expanded like a balloon in a vacuum.
2. What ISO 27001 Actually Means by “Scope”
When we talk about scope, we’re looking at ISO/IEC 27001:2022 , Clause 4.3. It’s the rulebook for setting your boundaries. The standard (and the accompanying ISO/IEC 27003 implementation guidance) essentially asks you to define the edges of your security responsibility.
The scope defines the boundaries and applicability of the ISMS. You need to consider:
- Organisational boundaries: Which legal entities and departments are in the club?
- Information assets: What data are we actually protecting?
- Technologies and infrastructure: Cloud, on-prem, or that one server under Dave’s desk?
- Locations: Physical offices vs. fully remote setups.
- Services and processes: The actual "doing" parts of your business.
- Interfaces and dependencies: This is the big one. How do you talk to the outside world?
3. The Three Dimensions of Scope
To visualize your scope, think of it as a 3D object. If you miss a dimension, the whole thing collapses.
3.1 Organisational Scope
This covers the "Who." Which legal entities are included? Is it the whole company, or just the "Cloud Operations Division"? You need to be clear about which employees and contractors fall under the ISMS's policies and training requirements.
3.2 Technical / ICT Scope
This is the "What." It’s the cloud platforms (AWS/Azure/GCP), the specific applications, the networks, and even the CI/CD environments. If your isms software doesn't help you map these out, you're essentially flying blind.
3.3 Physical Scope
The "Where." In 2026, this is trickier than ever. It includes offices, data centres, and co-location facilities. But what about a 100% remote workforce? Your scope needs to address how you manage security, and not the "office" which is a kitchen table in Lisbon.
4. The Most Important Part: Interfaces and Dependencies
This is where 90% of scopes fail. ISO/IEC 27003 is very clear: you cannot simply exclude supporting services that materially affect your security.
If your certified SaaS environment relies on a central IT identity platform, that platform is an interface. Even if central IT is "outside" your formal scope, the auditor will evaluate the controls governing privileged access.
Key Principle: Excluding a function from scope does not eliminate its influence on the ISMS. You can’t say "HR is out of scope" and then ignore the fact that HR is responsible for background checks on the people who have root access to your database.
5. Full Enterprise Scope vs Targeted Scope
There are two main roads you can take. Neither is "wrong," but one might be much harder for your specific situation.
Option A , Enterprise-Wide ISMS
The "Go Big or Go Home" approach.
- Pros: Maximum customer trust, simpler governance (one set of rules for everyone), and fewer interface headaches.
- Cons: Massive audits, higher costs, and a much longer road to certification.
- Best for: Mature organizations, financial institutions, or companies where "security" is the primary product.
Option B , Targeted Scope
The "Laser Focus" approach.
- Pros: Faster to implement, lower initial cost, and commercially targeted to what customers actually ask for.
- Cons: Complex boundary management and high auditor scrutiny of those "interfaces" we just talked about.
- Best for: SaaS startups and companies doing phased rollouts.
6. What ISO Does Not Mean
A common trap is thinking that because a department is "out of scope," it doesn't need security. That's a dangerous path.
The certified ISMS has one formal scope for audit purposes, but broader enterprise security governance should still exist. The certificate reflects what was audited, but your GRC platform should likely handle the whole organization to ensure you don't have blind spots.
Referencing ISO/IEC 17021-1 and ISO/IEC 27006, auditors are trained to look for organizations trying to "hide" risks behind scope boundaries. If it looks like you're excluding a department just because their security is a mess, the auditor will dig deeper.
7. How Certification Bodies Actually Evaluate Scope
Auditors aren't just looking at your Word document; they’re looking for operational reality. They will look for:
- Justification for exclusions: "Because it's hard" is not a valid reason.
- Dependency management: How do you handle the "Out of Scope" HR team?
- Governance consistency: Do policies apply equally to everyone in the boundary?
Red Flags for Auditors:
- "Production is in scope but DevOps is not" (How does the code get there, then?).
- "Security team is out of scope" (This is an immediate red flag for any sane auditor).
- "Cloud platform in scope, but IAM excluded."
8. Common Bad Scope Designs
- The “Marketing Scope”: A tiny, perfect "Production" island in a sea of unmanaged chaos. It looks great on a PDF, but it fails the second an auditor asks about the laptops used to access that production environment.
- The “Everything Scope”: Including a 5,000-person global company in the first year without the staff to manage it. You’ll be drowning in non-conformities before lunch.
- The “Invisible Dependency Scope”: Ignoring the fact that your "in-scope" service relies entirely on an "out-of-scope" third party for everything from hosting to SOC monitoring.
9. A Practical Framework for Defining Scope Properly
Using a structured approach is the only way to avoid audit pain. Here is how we recommend doing it within a modern GRC platform:
- Step 1 , Start with Business Drivers: Why are you doing this? If a customer wants to see a cert for your "API Service," start there.
- Step 2 , Identify Information Assets: Map out the customer data and production systems.
- Step 3 , Map Dependencies: Use visual tools to see how your "in-scope" assets talk to "out-of-scope" systems like HR or your PECB Certified Risk Manager team.
- Step 4 , Define Clear Boundaries: Explicitly state what is included, what is excluded, and, crucially, what is shared.
- Step 5 , Test the Scope Against Reality: Ask yourself: "If this excluded department was breached tomorrow, would my in-scope data be safe?" If the answer is no, your scope is wrong.
10. Good Example Scopes
The "Good" Targeted Scope:
> “Provision, operation, and support of the Brainframe Cloud Security Platform delivered from Luxembourg using AWS infrastructure and supporting DevSecOps functions.”
- Why it works: It’s specific, identifies the tech stack, and acknowledges the supporting functions.
The "Good" Enterprise Scope:
> “Information security management supporting the development, delivery, and operation of Brainframe products and corporate services across all company operations.”
- Why it works: It’s clean, covers the whole lifecycle, and leaves no room for "interface" arguments.
11. Final Advice : Scope for Reality, Not for Marketing
At the end of the day, a narrow scope is perfectly legitimate. You don't have to boil the ocean on day one. However, those exclusions must be defensible.
Auditors care about where the data flows and who has the keys. If you try to draw a box that ignores those realities, you're not building a security system: you're building a house of cards.
Pro-tip: Use a platform like Brainframe to visualize your dependencies. When you can show an auditor exactly how your in-scope environment is isolated or how its dependencies are managed through rigorous supplier controls, you stop the "scope creep" before it even starts.
A good ISO 27001 scope is not the smallest possible boundary. It is the smallest boundary that can still demonstrate effective and accountable security governance. Keep it real, keep it defensible, and your audit will be a breeze.
If you are looking for a good solution to manage your ISMS and/or need help mapping out your scope and the rest of your implementation plan, make sure to contact us