Your PCI DSS scope covers every system, person and process that stores, processes or transmits cardholder data. It also covers anything that can connect to those systems or affect their security. To shrink your cardholder data environment (CDE), you do two things: reduce where card data lives and flows, then isolate what's left with segmentation controls that actually hold. Segmentation isn't mandatory under PCI DSS, but without it your entire network is in scope.

Below, we cover how the PCI Security Standards Council (PCI SSC) expects you to categorize systems, how to design segmentation that stands up to an assessment, and how to prove it works, for teams on PCI DSS v3.2.1 today and planning for v4.0.

What is the cardholder data environment?

The CDE is the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Cardholder data means the primary account number (PAN), alone or together with the cardholder name, expiration date or service code. Sensitive authentication data includes full track data, card verification codes and PINs or PIN blocks.

The CDE also includes system components on the same network segment as those systems, even if they never touch card data themselves. If a file server sits on the same flat subnet as your payment application, it's part of the CDE by default. That rule is why network design has so much influence over how much work an assessment takes.

How does PCI DSS categorize systems for scoping?

The PCI SSC information supplement Guidance for PCI DSS Scoping and Network Segmentation (December 2016) sorts every system into one of three categories.

Category What puts a system here Scope status
CDE systems Stores, processes or transmits cardholder data, or sits on the same network segment as a system that does In scope
Connected-to and/or security-impacting systems Can connect to or access the CDE, can affect its configuration or security, or provides security services to it In scope, and must not provide an access path between the CDE and out-of-scope systems
Out-of-scope systems Doesn't handle card data, isn't on a CDE segment, and can't connect to any system in the CDE Not in scope

CDE systems

These are the obvious ones: payment applications, databases holding PAN, payment terminals, and the network devices that carry card traffic. They're assessed against all PCI DSS requirements.

Connected-to and security-impacting systems

This category catches most teams off guard. The 2016 guidance gives examples such as directory services, DNS, NTP, SMTP, monitoring tools, backup systems, anti-malware servers, authentication servers, audit log storage and the firewalls that enforce segmentation. Admin workstations and jump hosts that can reach CDE systems belong here too.

The guidance says these systems must be evaluated against all PCI DSS requirements to determine which ones apply. In practice, a time server that CDE systems query needs different controls from a domain controller that decides who can log in to them. Either way, a compromised connected-to system exposes the CDE, which is why none of them can be ignored.

Out-of-scope systems

A system is out of scope only if it doesn't store, process or transmit card data, isn't on a CDE segment, and can't connect to any system in the CDE. The last condition is usually the hard one.

An out-of-scope system may still reach a connected-to system, such as a shared DNS server. When it does, controls must stop it from using that in-scope system as a route into the CDE.

Is network segmentation required for PCI DSS?

No. PCI DSS doesn't require segmentation. But the standard is plain that without adequate segmentation (a "flat network") the entire network is in scope. For most organizations that's reason enough.

For PCI purposes, segmentation means isolating the CDE so that an out-of-scope system couldn't affect the security of card data even if it were compromised. That's the bar. A control that blocks most traffic but still allows a path from a user subnet to the database port on a payment server doesn't meet it.

How do you shrink your cardholder data environment?

Segmentation limits how far scope spreads. The bigger wins usually come earlier, from handling less card data in the first place. We work through it in this order:

  1. Find the data. Map every payment channel and data flow, then run data discovery across file shares, databases, application logs and backups. Unexpected PAN in a spreadsheet or debug log can pull a whole subnet into scope.
  2. Stop storing what you don't need. If there's no business need to keep PAN, don't. Delete it securely and fix the process that created it.
  3. Hand off card handling where you can. Hosted payment pages, validated point-to-point encryption (P2PE) and tokenization can each take large parts of your environment out of scope. Each has conditions, and the service providers involved still have to be managed under Requirement 12.8.
  4. Consolidate what remains. Put the systems that must handle card data into as few segments as possible.
  5. Segment the rest away. Restrict traffic into and out of the CDE to what's documented and justified, and deny everything else.

What makes segmentation adequate?

The 2016 guidance makes the point that separate network segments don't automatically create PCI DSS segmentation. It comes from purpose-built controls that create and enforce the separation. Common methods include internal firewalls, routers or layer-3 switches with strict access control lists, and, in virtual and cloud environments, virtual firewalls and security groups.

Whatever the method, look for these properties:

  • Default deny. Only traffic with a documented business need is allowed into and out of the CDE.
  • No transitive paths. Connected-to systems mustn't become a bridge. A jump host that the whole corporate network can reach, with broad access into the CDE, effectively puts the corporate network back in scope.
  • Controlled administration. Management interfaces for segmentation devices, hypervisors and cloud consoles are security-impacting. Anyone who can change the rules can remove the boundary.
  • Shared services thought through. Directory, DNS, logging and patching services that serve both the CDE and the rest of the business are common weak points. Dedicated CDE instances can keep the in-scope footprint small.
  • Accurate documentation. Current network diagrams and data flow diagrams that show every connection between the CDE and other networks.

How do you validate that segmentation works?

Designing segmentation is half the job. PCI DSS expects you to prove it isolates the CDE, and to keep proving it.

Penetration testing of segmentation controls

Under v3.2.1, Requirement 11.3.4 calls for penetration testing of segmentation controls at least annually and after any changes to segmentation controls or methods. Service providers have an additional requirement, 11.3.4.1, to test at least every six months. PCI DSS v4.0 carries these forward as Requirements 11.4.5 and 11.4.6 with the same frequencies. It also spells out that testing must cover all segmentation methods in use and be performed by a qualified tester with organizational independence.

A useful segmentation test runs from each out-of-scope network toward the CDE and confirms that nothing unapproved is reachable. It should cover every segmentation method in use, including virtual and cloud controls, not just the main internal firewall. The PCI SSC's Penetration Testing Guidance information supplement (September 2017) covers segmentation testing in more depth.

Rule reviews and change control

Firewall and router rule sets must be reviewed at least every six months (Requirement 1.1.7 in v3.2.1, 1.2.7 in v4.0). Pair those reviews with change control that flags any change touching the CDE boundary, because those changes also trigger a segmentation retest.

Ongoing scope confirmation

Scope drifts. A new integration or production data copied into a test system can widen it. PCI DSS v3.2.1 expects entities to confirm the accuracy of their scope at least annually and before the annual assessment. Repeat your data discovery at the same time.

What changes for scoping in PCI DSS v4.0?

The PCI SSC published PCI DSS v4.0 in March 2022. Version 3.2.1 remains active until March 31, 2024, so there's time to transition, but several scoping changes are worth planning for now:

  • Requirement 12.5.2 turns scope confirmation into a formal, testable requirement. Scope must be documented and confirmed at least once every 12 months and upon significant change to the in-scope environment. That confirmation covers data flows, where account data is stored, processed and transmitted, in-scope system components, segmentation controls with the justification for anything out of scope, and third-party connections.
  • Requirement 12.5.2.1 will require service providers to confirm scope at least once every six months. It's a best practice until March 31, 2025, when it becomes mandatory.
  • Network security controls. Requirement 1 now talks about network security controls rather than firewalls and routers, which fits virtual and cloud controls better.
  • Diagrams. Network diagram and data flow diagram requirements move to 1.2.3 and 1.2.4.

The logic of scoping stays the same. What changes is that scope can no longer be treated as a once-a-year exercise.

Common scoping mistakes

  • Forgetting administrative paths, such as remote access tools, jump hosts and the workstations administrators use every day.
  • Leaving shared services out of scope because they don't "touch" card data.
  • Assuming a hosted payment page removes all scope, when the web pages that redirect to or embed it can still affect card data security.
  • Letting diagrams go stale between assessments.
  • Testing only the primary firewall and ignoring secondary segmentation methods.

Frequently asked questions

Does a VLAN count as segmentation?

Not by itself. A VLAN separates broadcast domains but doesn't decide which traffic may pass between networks. It needs access controls at the boundary, such as firewall rules or ACLs at the routing layer. Your assessor will look at what traffic can actually pass, not at how the network is labeled.

Do connected-to systems have to meet every PCI DSS requirement?

They're in scope and must be evaluated against every requirement to see which ones apply. A domain controller that authenticates CDE users will end up with close to the full set. Document your reasoning for each type of system so the assessor can follow it.

Can our corporate network be out of scope?

Yes, if it's segmented so that no system on it can connect to CDE systems, and any access to shared services can't be used to reach the CDE. Admin access is the usual sticking point. If administrators reach the CDE directly from their everyday laptops, those laptops are in scope.

How often should we re-check our scope?

At least annually and whenever a significant change affects the CDE. Under v4.0, Requirement 12.5.2 formalizes that cadence. Tying scope checks to change management means you don't have to wait for the annual cycle to catch drift.

Next steps

  • Build or refresh a data flow diagram for every payment channel, then run data discovery to test it against reality.
  • Classify every system as CDE, connected-to or security-impacting, or out of scope, using the 2016 PCI SSC guidance as your reference.
  • Remove card data you don't need, and look at whether P2PE, tokenization or outsourcing can take more systems out of scope.
  • Enforce default-deny rules at the CDE boundary and lock down administrative paths.
  • Schedule segmentation penetration tests at the required frequency and after every change to the boundary.
  • Map your scoping process to v4.0 Requirement 12.5.2 now, so the switch before March 31, 2024 is uneventful.