Before you assess a single risk or implement a single control, you must decide what your ISMS covers. That decision — the scope — shapes the cost, effort, and credibility of your entire certification. It is also where many projects quietly go wrong, usually by scoping far too broadly out of a misplaced desire to look thorough.
This guide explains what ISO 27001 scope is, how to define it sensibly, what to include and exclude, and how to write a scope statement that supports rather than sabotages your iso 27001 certification.
What 'scope' means in ISO 27001
The scope defines the boundaries of your ISMS: which parts of the organisation, which products and services, which locations, and which information and systems the management system covers. Everything else — risk assessment, controls, audits — applies only within that boundary.
ISO 27001 requires the scope to be documented, and it is one of the first things a Stage 1 auditor examines. Your certificate will state the scope, so it also determines what your customers see you are certified for.
In short, scope answers the question ‘certified to protect what, exactly?’
Why scope is the biggest cost lever
Almost every downstream cost scales with scope. A broader scope means more assets to assess, more controls to implement, more evidence to collect, and more for the auditor to examine — which also raises audit fees. A tighter scope concentrates effort where it matters.
This is why scope is the single most important efficiency decision in the project. Teams that scope thoughtfully often spend a fraction of what teams that ‘include everything’ do, for a certificate that satisfies buyers just as well.
Getting scope right early is the highest-leverage thing you can do for the budget.
Free resource
The Complete Guide to ISO 27001
A practical, plain-English guide to building your ISMS and earning ISO 27001 certification.
Start from what your buyers care about
The best anchor for scope is your customers’ concern: the systems and data they entrust to you. For a SaaS company that is usually the production platform, the data it holds, and the people and processes that build and operate it.
Scoping around the customer-facing service ensures the certificate covers exactly what buyers ask about, which is what makes it commercially useful. A certificate whose scope excludes your main product would impress no one.
So begin by asking: what would a prospect’s security team want to know is protected? Then scope to cover it.
Defining the boundaries
A good scope is drawn along clear boundaries. Identify the in-scope services and products, the supporting systems and infrastructure, the physical locations involved, and the teams and roles that operate within it. Be explicit about where the boundary sits and what sits outside it.
Interfaces and dependencies matter: where in-scope systems rely on out-of-scope ones or on third parties, you must address those connections rather than pretend they do not exist. Auditors probe the edges of scope carefully.
Clarity at the boundary prevents disputes later about whether something should have been covered.
Handling cloud and third parties
Most modern organisations rely on cloud providers and SaaS tools. These usually sit outside your ISMS scope (they have their own certifications), but the way you use them is inside it. You are responsible for configuring, accessing, and managing those services securely.
This is the shared-responsibility model: the provider secures the platform; you secure your use of it. Your scope and controls must cover your side of that line, and supplier-security controls address the relationship.
Documenting this clearly reassures auditors that you understand where your responsibility begins and ends.
What you can legitimately exclude
You can exclude parts of the organisation that genuinely do not touch the in-scope information — an unrelated business unit, a separate product with its own isolated environment, or office functions with no access to customer data. Exclusions must be defensible, not just convenient.
The test is whether the excluded area could affect the security of in-scope information. If it could, excluding it will draw a finding; if it genuinely cannot, a documented exclusion is fine.
Honest, well-reasoned boundaries are far stronger than an artificially shrunken scope that ignores real dependencies.
Avoiding the too-narrow trap
While over-scoping wastes effort, under-scoping fails commercially. A scope so narrow that it excludes your main product, or that carves out systems your customers obviously care about, produces a certificate that buyers will not accept — defeating the purpose.
Buyers increasingly read the scope on a certificate, not just its existence. A mismatch between your marketing and your certified scope undermines trust.
The goal is the smallest scope that still genuinely covers what matters to customers — tight, but not misleading.
Writing the scope statement
The scope statement is a concise document (often a paragraph or two) that describes the boundaries clearly: the services covered, the supporting systems and locations, and any exclusions with justification. It appears on your certificate, so precision matters.
Write it so that a customer reading the certificate understands exactly what is protected. Avoid vague language; favour specific products, environments, and locations.
A clear scope statement is both an audit requirement and a sales asset, so it is worth drafting carefully and reviewing with stakeholders.
Scope and growth
Scope is not permanent. Many companies start with a focused scope and expand it over time — adding products, locations, or business units as the ISMS matures. The standard accommodates this through re-scoping at surveillance or recertification points.
Starting tight and growing deliberately is usually wiser than starting broad. It gets you certified faster and lets you extend coverage in line with real business need rather than speculative thoroughness.
Plan for expansion, but do not let future ambitions inflate your initial scope.
Common scope mistakes
The recurring mistakes are predictable: scoping everything ‘to be safe’ and drowning in work; scoping so narrowly that the certificate is commercially useless; ignoring dependencies on out-of-scope systems; and writing a vague scope statement that confuses auditors and customers alike.
Each is avoidable with a simple discipline: anchor scope to what customers care about, draw clear boundaries, address dependencies honestly, and write the statement precisely.
Avoid these and scope becomes a foundation for the project rather than a recurring source of trouble.
The bottom line
Scope is the foundational decision of an ISO 27001 project. Define it around the systems and data your customers care about, draw clear boundaries, handle cloud and third parties through the shared-responsibility model, and write a precise scope statement.
Aim for the smallest scope that genuinely covers what matters — tight enough to be efficient, broad enough to be credible. Get this right and the rest of the project is far smoother.
ISpectra helps you scope for both efficiency and commercial value — with free VAPT and a multi-framework discount — so your certificate is affordable to earn and meaningful to your buyers.
A worked scope example
Picture a 40-person SaaS company. A sensible scope reads: ‘The information security management system covers the development, operation, and support of the [Product] cloud platform, including the AWS production environment, the engineering and support teams, and the corporate systems used to access customer data, across the company’s remote workforce and London office.’
That single statement tells an auditor and a customer exactly what is protected. It deliberately includes the production platform and the people who touch customer data, while leaving genuinely unrelated functions out — tight, clear, and commercially credible.
Use it as a template: name the service, the environment, the teams, and the locations, and you have a scope that supports both the audit and the sale.
Free consultation
Need help with ISO 27001?
Talk to our certified compliance team — we’ve supported 200+ audits.