Segmentation testing: proving the boundary you claimed

What segmentation is, in the Council's own words

The PCI SSC glossary defines it plainly: segmentation, also called network segmentation or isolation, "isolates system components that store, process, or transmit cardholder data from systems that do not." The definition points onward to the scoping section of PCI DSS itself, which is where the boundary rules live.

The Council will not tell you whether your particular design counts. Asked whether VLANs can be used for network segmentation, it answered that adequate segmentation "can be implemented with, for example, properly-configured internal firewalls, routers with strong access control lists, VLANs, or other technologies that restrict access to a particular network segment", and then declined to give an opinion on any specific case, because that "requires an understanding of security features and controls implemented in your environment." The technology is not the answer. The demonstration is.

Why scope is the expensive decision

A QSA writing on the Council's own blog framed it in a way worth quoting to anyone who thinks scoping is paperwork:

Scope is foundational to complying with PCI DSS. Without a clear understanding of scope, you cannot validate its boundaries and you don't know where to apply the requirements. Determining scope can also get very complex; even modestly complex organizations have intricate questions of where to draw the line between in-scope and out-of-scope, so it's very rarely a trivial exercise.Jacob Ansari, QSA, published by PCI Security Standards Council

The same interview names the trap most organisations fall into. The commonest confusion, he said, "comes from systems that are connected to those that store, transmit, or process cardholder data", and the Council's scoping guidance "more firmly pronounces as in scope systems that many organizations had not previously considered such as administrator workstations or IT management systems."

Read that twice if you run a modern platform team. The jump host, the configuration management server, the identity provider, the log aggregator and the laptop your platform engineer uses to reach production are all candidates. Segmentation that keeps the payment application away from the marketing website but leaves a shared administration plane in the middle has not reduced scope; it has relabelled it.

When segmentation testing applies to you

The trigger is simple and it is not about size. If you rely on segmentation to keep systems out of the assessment, you are making an assertion about a control, and the standard expects that assertion to be tested. If you run a flat network, there is no boundary to test, because there is not one: every connected system is in scope for every other requirement instead. That is a worse outcome, not a cheaper one.

The history is documented publicly, and it is useful because it shows the intent. In PCI DSS v3.2, the Council introduced a segmentation testing requirement effective 1 February 2018. Its then Chief Technology Officer described it directly:

To address that concern, the new PCI DSS Requirement 11.3.4, which becomes effective as a requirement February 1, 2018, asks for organizations to perform penetration tests on the boundaries of their cardholder data environments to have confidence in the segmentation is effectively working.Troy Leach, then CTO, PCI Security Standards Council, 2017

A Council post from January 2018 listed the additional requirements that became effective at the same time for service providers specifically, and one of them was "Perform penetration testing on segmentation controls at least every six months (Requirement 11.3.4.1)."

What the test has to actually do

This is where most segmentation testing goes wrong, and the Council's own material is unusually specific about it.

Too often when security incidents occur, the network segmentation that should have helped prevent the attack didn't really work as advertised. Testing the effectiveness of the segmentation should help with this, provided the penetration testing really does rigorously test those controls. This needs to involve more than just port scanning from outside network segments to determine if there are any open ports. It should test remote access mechanisms, try to hop through administrator workstations, and look at any shared services networks that might allow an attacker some advantage in getting into the in-scope environment.Jacob Ansari, QSA, published by PCI Security Standards Council

Unpacked into a scope of work, that is four distinct activities, and a report that only contains the first one is not a segmentation test.

1. Reachability from each out-of-scope segment into the cardholder data environment, at the network layer. This is the part a port scan covers, and it is the easy part.
2. Remote access mechanisms. VPN concentrators, bastion hosts, vendor access paths and anything that terminates a session on both sides of the boundary. A split-tunnel VPN, in the Council's own words from a separate interview, "creates a bridge between a network of high security, the CDE, and a network of lower security".
3. Administrator workstations and the management plane. If an engineer's laptop can reach both the corporate network and the payment environment, it is the boundary, and it is the thing to test.
4. Shared services. Directory services, DNS, NTP, logging, backup, secrets management, CI runners. These are usually the reason a nominally segmented estate is not segmented, because everyone agreed the boundary would have exactly one hole in it, seven times.

A tester who is told "confirm the VLANs are isolated" will produce a document that confirms the VLANs are isolated. Scope the engagement against the list above and the report becomes evidence.

Cloud, micro-segmentation and zero trust

The traditional model assumed a network you could draw. Most payment estates are now hybrid, and the Council has acknowledged it. In September 2024 it published an information supplement, PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures, produced by a 2023 Special Interest Group. Its stated contents are the four questions everyone actually has:

• Determining the impact of zero trust architecture on PCI DSS scope and network segmentation.
• Defining PCI DSS scope boundaries in micro-segmentation and multi-cloud implementations.
• How to develop and maintain a PCI DSS asset inventory given the ephemeral nature of cloud-hosted microservices and systems.
• Identifying risks associated with the implementation of modern network architectures given the complexity of modern system configurations.

The supplement also covers "guidance on specific PCI DSS requirements for verifying scope and segmentation controls", which is the sentence to point your assessor at when the conversation turns to how a boundary made of policy rather than cable gets demonstrated. Note the Council's own caveat: "The guidance provided in this document is supplemental and does not supersede or replace any PCI standard."

What changes in practice

Three things, in our experience of testing these estates.

• The boundary is now an identity boundary as much as a network one. A security group, an IAM role, a service mesh policy and a Kubernetes network policy are all segmentation controls, and each fails differently. A test that only sends packets will miss a role that can assume another role.
• Inventory is the hard part. The Council names the ephemerality of cloud-hosted microservices explicitly. If the scope document lists instances and the environment lists workloads, the test is scoped against something that no longer exists by the time the report lands.
• The management plane is the shortest path. In cloud estates the fastest route into a segmented environment is very often the cloud control plane, not the network. Any segmentation test worth buying tries it.

The trap the change list sets

Several requirements fire on significant change rather than on the calendar, and PCI SSC publishes the list. Two of its entries are about the boundary itself.

Activities the Council counts as a significant change

Activity	Why it touches segmentation
New hardware, software, or networking equipment added to the CDE	A new component inside the boundary is a new thing to be reachable
Any replacement or major upgrades of hardware and software in the CDE	A firewall or load balancer replacement rebuilds the rules you tested
Any changes in the flow or storage of account data	The data moved, so the boundary is now drawn around the wrong thing
Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment	This is the boundary, restated as a change trigger
Any changes to the underlying supporting infrastructure of the CDE, including directory services, time servers, logging, and monitoring	The shared services list, which is where most segmentation actually leaks
Any changes to third party vendors or services that support the CDE	Someone else now sits on your boundary

The fourth row deserves attention because it is recursive. A change to the scope of the assessment is itself a significant change. A scoping exercise that quietly grows the boundary in March therefore creates obligations in April, which is a good reason to do the scoping deliberately, once, with the assessor in the room.

What good evidence looks like

An assessor is trying to answer one question: is the boundary real. The artefacts that answer it are unglamorous.

• A current scope document that names the cardholder data environment, the connected-to systems, and the systems deliberately excluded, with the control that excludes each of them.
• A data flow that matches the scope document. Where the two disagree, the flow is usually right.
• A segmentation test report whose scope section lists the segments tested, in both directions, and whose method section describes more than scanning.
• Evidence for the paths that were not testable, and why. "Out of scope by agreement" is a finding, not an omission, and writing it down is what stops it becoming a surprise next year.
• A dated retest for anything the test found. A closed finding with no retest is an open finding with optimism attached.

For how the segmentation test sits alongside the quarterly scanning obligation, see ASV scan or penetration test. For who ends up receiving all of this, see merchant levels and validation.