Segmentation is a claim. Testing is the proof.

Every PCI DSS scope conversation eventually arrives at the same diagram: a cardholder data environment drawn as a neat box, firewalls on every side, and the rest of the corporate network labeled “out of scope”. The diagram is a claim. If it is true, the organization has dramatically reduced the systems that must meet PCI DSS. If it is false, every system that can reach the cardholder data environment is in scope, whether or not anyone has assessed it.

PCI DSS does not require segmentation. Where an entity relies on segmentation to reduce scope, however, the standard requires that the segmentation be proven by penetration testing. This article explains what that testing must establish, why it so often falls short, and how to do it well in modern estates.

Three categories of system

The PCI Security Standards Council’s scoping guidance sorts systems into three broad categories:

• CDE systems store, process or transmit cardholder data or sensitive authentication data, or sit on the same unsegmented network as systems that do.
• Connected-to and security-impacting systems can connect to the CDE or can affect its security: directory services, patching and configuration servers, logging and monitoring infrastructure, jump hosts, CI/CD pipelines that deploy into it.
• Out-of-scope systems cannot connect to the CDE and cannot affect its security.

Segmentation is what makes the third category possible. Its job is to ensure that a compromise of an out-of-scope system gives an attacker no path to the CDE. Testing has to show that this is so.

What 11.4.5 and 11.4.6 require

Requirement 11.4.5 in PCI DSS v4.0.1 applies whenever segmentation is used to isolate the CDE from other networks. Penetration tests on the segmentation controls must be performed at least once every 12 months and after any change to segmentation controls or methods. The tests must cover all segmentation controls and methods in use, confirm that they are operational and effective and isolate the CDE from all out-of-scope systems, and confirm the effectiveness of any isolation used to separate systems with differing security levels. They must be performed by a qualified internal resource or a qualified external third party, with organizational independence of the tester.

Requirement 11.4.6 adds an obligation for service providers: the same testing at least once every six months and after changes.

Why segmentation tests fall short

Testing from one place

The most common weakness is a test run from a single vantage point, often one laptop on the user network, that confirms the CDE is unreachable from there. That tells you nothing about the server VLANs, the management network, the VPN pools, the wireless networks, the partner connections or the cloud accounts. “All segmentation controls and methods” means testing from each out-of-scope network segment towards the CDE.

Testing ports, not paths

A port scan that finds every port filtered from an out-of-scope segment is necessary but not sufficient. Real attack paths run through permitted services: a monitoring agent that the CDE trusts, a shared Active Directory, a backup server with credentials on both sides, a CI runner that deploys to production. A segmentation test should examine whether those permitted connections can be abused to reach the CDE.

Testing the diagram, not the network

Tests scoped from the network diagram inherit its errors. We regularly find segments that are missing from diagrams: legacy VLANs, test environments that were cloned from production, forgotten site-to-site tunnels. Discovery should precede testing.

Ignoring change

The requirement to retest after changes is often ignored in practice because no-one connects firewall change management to the segmentation test schedule. A rule added to solve an urgent operational problem can silently undo the scope reduction the whole program depends on.

Segmentation in cloud and hybrid estates

In cloud environments, segmentation is rarely a single firewall. It is a combination of account or subscription boundaries, virtual network design, security groups and network ACLs, private endpoints and, critically, identity. Two systems with no network path between them are not segmented if an identity in the out-of-scope environment can assume a role that administers the CDE.

A cloud segmentation test therefore needs to cover:

• Network paths between virtual networks, including peering, transit gateways, shared VPCs and private endpoints.
• Identity paths: cross-account role trust, federated identities, workload identities and CI/CD credentials that can modify CDE resources.
• Control-plane paths: whether an administrator of an out-of-scope account can change security groups, routing or policies that protect the CDE.
• Managed services shared across environments, such as logging pipelines, container registries and key management, and whether they create a path back into the CDE.

Containers and Kubernetes add a further layer. Namespaces are not a security boundary by default; network policies, admission controls and node isolation determine whether workloads with different security levels are genuinely separated.

What a good segmentation test looks like

1. Discovery and reconciliation. Enumerate segments and routes from the live network and cloud configuration, and reconcile them with the documented scope.
2. Test plan by segment. For each out-of-scope segment, define the vantage point, the tests to run and the expected result.
3. Connectivity testing. Full TCP and relevant UDP port ranges from each vantage point to CDE ranges, and the reverse where outbound restrictions matter.
4. Permitted-path testing. For each allowed connection between connected-to systems and the CDE, attempt to use it to gain access or move laterally.
5. Identity and control-plane testing in cloud estates.
6. Reporting that an assessor can follow. Vantage points, ranges, methods, results and evidence for every segment, with any failures and their remediation retested.

Sources

• PCI Security Standards Council, PCI DSS v4.0.1, June 2024, requirements 11.4.5 and 11.4.6.
• PCI Security Standards Council, information supplement Guidance for PCI DSS Scoping and Network Segmentation.
• PCI Security Standards Council, information supplement on penetration testing guidance.

MarkTillson prepares organizations for PCI DSS assessment every year, so we know exactly what a segmentation report must show. Our network penetration testing team tests every segment, every permitted path and every identity route, and writes the report an assessor can accept on first reading.