Here’s a question I get surprisingly often from people preparing for ISO 27001 certification: “Does our certificate have to cover our entire organization?”
The answer is: not necessarily — and that’s completely fine.
There are two distinct concepts at play here, and confusing them leads to poorly designed scopes, auditor surprises, and certificates that don’t actually reflect what a company intended to certify. Let’s fix that.
What the ISMS scope actually is
The ISMS scope defines the boundaries and applicability of your information security management system. It answers the question: where and for what exactly does this management system apply?
ISO/IEC 27003 — the official guidance document for ISO 27001 implementation — is clear that scoping is a foundational activity. Get it wrong and everything downstream suffers: your risk assessment won’t cover the right assets, your controls won’t address the right threats, and your Statement of Applicability will be built on a shaky foundation.
A well-defined ISMS scope has three dimensions:
Organisational scope — which legal entities, business units, functions, processes, services, and people fall inside the boundary. This could be an entire company, a specific department, or even a defined set of services.
ICT scope — which applications, networks, cloud services, and data stores are included, and critically, where they end. Cloud regions, SaaS platforms, and outsourced infrastructure all need to be considered explicitly.
Physical scope — which sites, offices, data centres, and remote-only environments are covered.
And sitting across all three: interfaces and dependencies — the hand-offs between what’s in scope and what isn’t. This is where organisations most commonly run into trouble. It is especially important interfaces between in-scope and out-of-scope activities must be identified and their influence on the ISMS understood. Ignoring them doesn’t make the risk disappear; it just makes it unmanaged.
What the certification scope is
The certification scope is something different. It is the slice of your ISMS that a certification body (CB) audits and lists on your certificate. The auditor confirms what’s within it; the certificate describes it.
These two things — the ISMS boundary you’ve defined, and the portion a certification body chooses to audit — can be identical, or they can deliberately diverge.
Two legitimate options
Option 1: Certification scope = ISMS scope
The certificate covers everything your ISMS covers. This is what most organisations initially assume is the only option. It gives maximum credibility — customers and partners can see that your entire operation, all sites, all services, has been audited. If your goal is to demonstrate organisation-wide security governance, this is the path.
Option 2: Certification scope ≠ ISMS scope
The certificate covers a defined subset — a particular service, product line, geographic region, or customer-facing function. The rest of the ISMS exists and operates, but isn’t listed on the certificate.
When does this make sense? When a specific product team needs a certificate to meet a customer requirement, but the organisation isn’t ready (or doesn’t need) to certify its entire operation. Or when a large enterprise wants to certify a cloud service without bringing every internal support function into scope of the formal audit.
The key principle here: interfaces between the certified portion and the uncertified portions still need to be controlled. You can’t certify one part of an interconnected system and ignore the dependencies flowing in from outside the certification boundary.
A practical way to think about it
Imagine a company that builds payroll software. Their ISMS covers the whole business — development, sales, HR, finance. But their customers only care about the payroll platform itself.
They could certify just the payroll platform — the development process, the hosting environment, the operational team. The sales and HR functions remain part of the ISMS for internal governance purposes, but they don’t appear on the certificate.
The certificate is a slice of the ISMS. The ISMS is the full picture.
When a partial certification scope makes sense
Choosing to certify only a portion of your ISMS isn’t a shortcut — it’s often the most deliberate and commercially rational decision an organisation can make. Here are the most common reasons:
Customer and contractual requirements are scoped. A customer might require ISO 27001 certification for the specific service they consume — not your entire business. If only your SaaS platform handles their data, certifying the payroll department alongside it adds cost and complexity with no benefit to anyone.
Different product lines carry different risk profiles. A company running both a consumer app and an enterprise data platform might certify the enterprise product first, where the commercial stakes and customer expectations are higher. The consumer product stays within the ISMS but outside the certification boundary until the business decides otherwise.
Phased certification is a legitimate strategy. Many organisations — particularly mid-sized ones — use a partial certification scope as a starting point, then expand it over successive certification cycles as their ISMS matures. Starting with a tightly scoped certificate is far better than an overambitious scope that creates audit findings at every turn.
Regulatory or geographic boundaries. Organisations operating across multiple jurisdictions sometimes certify only the entity or data centre that is subject to a specific regulatory requirement, keeping the rest of the ISMS outside the formal certification boundary.
Cost management. Certification audits are priced in part by scope complexity. A narrower, well-defined certification scope means fewer audit days, lower fees, and a more focused remediation effort if nonconformities arise.
The important caveat — as noted earlier — is that narrowing the certification scope doesn’t let you ignore what sits outside it. Interfaces still need to be controlled. Uncertified parts of the ISMS still need to operate. The certificate is smaller; the security responsibility isn’t.
Why this matters in practice
Getting this wrong in either direction causes problems. Organisations that collapse everything into one scope when they only needed to certify a service end up with unwieldy audits. Organisations that define a certification scope without thinking about the interfaces to their wider ISMS find themselves with nonconformities they didn’t anticipate.
The cleaner approach: define your ISMS scope first, based on your actual context and risk landscape. Then decide how much of that scope you want to bring into a certification audit — and make sure the certificate reflects that deliberate choice.
The ISMS is yours to define. The certificate is a statement of what was verified.