PCI DSS Scoping and Segmentation Done Right

Ask any assessor where PCI DSS programmes go wrong and you will get the same answer: scope. Not encryption, not firewalls, scope. Organisations either scope too narrowly and get caught at assessment time, or scope too broadly and pay to secure and assess systems that never needed to be included.

Scoping is also where the money is. Every system you legitimately remove from scope is a system you do not have to harden, monitor, sample, and assess, year after year. This guide explains how scoping works under PCI DSS v4.0.1, what the standard now formally requires, how segmentation reduces scope, and the places cardholder data hides that scoping exercises routinely miss.

What is actually in scope

PCI DSS applies to the cardholder data environment (CDE) and to systems that can affect its security. In practice, scope has three rings.

• The CDE itself: systems that store, process or transmit cardholder data or sensitive authentication data, plus anything on the same network segment as those systems. Being a neighbour is enough; a system in the CDE segment is in scope even if it never touches a card number.
• Connected-to and security-impacting systems: systems that connect into the CDE or provide services to it, such as authentication servers, patch and deployment infrastructure, monitoring platforms, and administrator workstations. These are in scope because compromising them compromises the CDE.
• Out of scope: systems with no access to the CDE and no ability to affect its security. This status must be demonstrated, not assumed, which is where segmentation and its testing come in.

Scope confirmation is now a formal requirement

Historically, scoping was something you did to prepare for an assessment. Under v4.x it is a requirement in its own right. Requirement 12.5.2 obliges every entity to document and confirm its PCI DSS scope at least once every twelve months and after any significant change: identifying all data flows, all locations of cardholder data, all system components, and all segmentation controls and third-party connections. For service providers, Requirement 12.5.2.1 tightens the frequency to at least once every six months.

The practical implication: “we think scope is the same as last year” is no longer an acceptable position. You need a documented scoping exercise, with data-flow diagrams that match reality, refreshed on a defined cycle. Assessors are required to check it.

Segmentation: the scope-reduction tool that must prove itself

Network segmentation is not mandatory in PCI DSS. Without it, however, your entire network is the CDE, and everything on it inherits every applicable requirement. That is almost always the most expensive possible configuration, which is why segmentation is the single most effective cost lever in a PCI programme.

Segmentation only reduces scope if it genuinely isolates: controls such as firewalls or access control lists must prevent out-of-scope systems from reaching the CDE. And the standard requires you to prove it works:

• Requirement 11.4.5: where segmentation is used to isolate the CDE, penetration testing must validate the segmentation controls at least once every twelve months and after any change to them, confirming they are operational and effective and that they actually separate the CDE from out-of-scope networks.
• Requirement 11.4.6 (service providers): the same segmentation testing at least once every six months and after changes.

A segmentation penetration test is a targeted exercise: from the out-of-scope segments, the tester attempts to reach the CDE. If they can, your scope was wrong all year, which is precisely the discovery you want from your own tester rather than your assessor, and infinitely preferable to learning it from an attacker.

Where cardholder data hides: the scoping misses we see most

Almost every scoping failure we encounter in assessments across New Zealand and Australia falls into a familiar pattern. Check these before your assessor does.

1. Call recordings. Contact centres that take payments by phone routinely capture full card numbers, and sometimes CVVs, in audio. Recording platforms are one of the most commonly missed CDE components.
2. Email, chat and ticketing systems. Customers send card numbers whether you want them to or not, and staff paste them into CRMs and support tickets. If there is no process to find and purge them, those platforms hold cardholder data.
3. Spreadsheets and shared drives. Finance exports, reconciliation files, chargeback records. Data discovery scans regularly find card numbers in file shares nobody declared.
4. Backups and log files. Data that was in scope stays in scope when it lands in a backup set or gets captured by verbose application logging.
5. Administrator workstations and jump hosts. Machines used to administer CDE systems affect its security and are in scope, including the laptops of engineers working from home.
6. Shared services. Active Directory, DNS, NTP, patching, monitoring: if the CDE consumes the service, the service affects CDE security. This is the ring organisations most often under-declare.
7. Third-party connections. Every provider with a pathway into your environment is part of the scoping picture, and your responsibilities around them are their own set of requirements. Cloud environments deserve particular care, which we cover in our guide to PCI DSS in the cloud.

Shrinking scope deliberately

The best scope is the one you engineered on purpose. The levers, in rough order of effectiveness: stop storing cardholder data you do not need (you cannot be assessed on data you do not have); outsource payment capture to compliant providers so card data never enters your systems, as discussed in our ASV scanning article; tokenise where card data must persist, so downstream systems hold tokens instead of PANs; and segment tightly around whatever genuinely must remain, then test that segmentation properly. Organisations that work through this list in order routinely cut their assessed environment, and their annual compliance cost, by well over half.

Frequently asked questions

Is network segmentation required by PCI DSS?

No. Segmentation is optional, but without it your entire network is in scope for every applicable requirement. Segmentation is used to reduce scope, and once you rely on it, testing it becomes mandatory: at least annually under Requirement 11.4.5, and at least every six months for service providers under 11.4.6.

How often must we confirm our PCI DSS scope?

At least once every twelve months and after significant changes, as a documented exercise under Requirement 12.5.2. Service providers must confirm scope at least every six months under Requirement 12.5.2.1. This is a formal requirement under v4.x, not just good practice.

Are employee laptops in scope?

If a laptop can access the CDE, administer CDE systems, or affect their security, it is in scope. This includes remote administrator machines. Locked-down jump hosts with restricted paths into the CDE are the usual way to keep the general laptop fleet out of scope.

What does a segmentation penetration test involve?

A tester positioned on out-of-scope network segments attempts to reach CDE systems through the segmentation controls. Success means the controls failed and scope must be redrawn; a clean result is your evidence that out-of-scope really means out of scope. It is a focused test, distinct from a full network penetration test, though often run together.

Get your scope right before it gets expensive

Cianaa’s QSAs run scoping workshops and readiness reviews that establish exactly what is in scope, what can be removed, and what the segmentation evidence needs to look like, before the formal assessment clock starts. If your scope has never been independently challenged, book a scoping call or start with our PCI DSS services overview.