How to scope a compliance programme (the decision that costs the most)

Scope is the highest-leverage decision in any compliance programme, and it is usually made in a hurry at the start by whoever is least equipped to make it. It determines how many controls apply, how much evidence you collect, how long the audit takes, what it costs, and - most importantly - whether the certificate answers the question your customer actually asked.

What scope actually defines

• Organisational - which legal entities, business units and teams.
• Systems - which applications, infrastructure and data stores.
• Locations - which offices, data centres and cloud regions.
• People - employees, contractors, and which roles.
• Data - which categories and classifications.
• Third parties - suppliers within the boundary and how they are covered.

Start from the question being asked

Scope should answer a specific external question. Work backwards from it:

• A customer asks for ISO 27001 covering "the service you provide us" - scope the product and its supporting infrastructure and teams.
• A tender requires certification for a named service line - scope that service line.
• PCI DSS applies to the cardholder data environment - scope is determined by where card data flows, not by preference.

Ask the buyer what they need covered, in writing, before drawing the boundary. Certifying the wrong scope is the most expensive mistake available - evaluators read the scope statement, and a certificate that excludes the tendered service is worth nothing.

The case for the smallest honest scope

Teams inflate scope to look impressive. It reliably backfires:

• More systems, more evidence, more interviews, more audit days, higher cost.
• More opportunities for a control to fail somewhere you were not watching.
• Longer timelines, which is often the constraint that actually matters.
• A failed broad audit is far worse commercially than a passed narrow one.

Start with what customers ask about, then widen at recertification once the management system is running. Widening later is routine; recovering from a failed Stage 2 is not.

What drags things into scope unintentionally

• Shared services. If in-scope and out-of-scope systems share an identity provider, that provider is in scope - and so is much of what it controls.
• Flat networks. Without segmentation, connected systems are in scope. This is why PCI scope reduction starts with segmentation.
• Shared staff. An administrator with access to both sides brings both sides in.
• Backups and logs. In-scope data replicated into an out-of-scope store pulls that store in.
• Support and monitoring tooling that reaches into the environment.
• Development environments containing production data - the most common accidental inclusion.

Segmentation is the mechanism that makes a narrow scope defensible. Asserting a boundary without enforcing it technically is exactly what an assessor probes - and PCI DSS requires testing that the segmentation actually holds.

Handling third parties

Suppliers inside your boundary are covered one of two ways: they are assessed as part of your scope, or their own certification is relied upon with due diligence evidence. SOC 2 formalises this as the inclusive versus carve-out method. Either is acceptable - what is not acceptable is silence about a supplier who is clearly in the middle of your service.

Writing the scope statement

It appears on the certificate and is read by evaluators. It should state plainly what is covered, name the services and locations, and where useful state exclusions explicitly. Vague statements invite questions; overly broad ones invite scrutiny you did not need.

Expanding over time

1. Certify the core service first.
2. Operate for a cycle and let the management system mature.
3. Add the next business unit or product at surveillance or recertification.
4. Update the scope statement and tell customers - a widened scope is a sales asset.

Key takeaways

• Work backwards from the question your customer is asking.
• The smallest honest scope that answers it is usually right.
• Shared identity, flat networks and prod data in dev quietly widen scope.
• Segmentation must be enforced and tested, not asserted.