Segmentation testing under PCI DSS v4.0

PCI DSS applies to the cardholder data environment (CDE) and to everything connected to it. Segmentation, isolating the CDE from the rest of the network, is how most organisations keep that scope manageable. PCI DSS does not require segmentation, but if you rely on it to reduce scope, you have to prove that it works. That proof is the segmentation test.

The requirements below are from PCI DSS v4.0; v4.0.1, the current version of the standard, keeps the same requirement numbers.

What requirements 11.4.5 and 11.4.6 ask for

• Test at least once every 12 months, and after any change to segmentation controls or methods (11.4.5).
• Service providers test at least once every six months, and after any change (11.4.6).
• Cover every segmentation control and method in use: firewalls, access control lists, cloud security groups, VLANs and host firewalls.
• Follow your defined penetration testing methodology.
• Confirm the controls are operational and effective, and that they isolate the CDE from all out-of-scope systems.
• Use a qualified tester who is organisationally independent. An internal team can do it if it is independent of the people who manage the controls; it does not have to be a QSA or an ASV.

A change to segmentation means more than a new firewall. A new VLAN, a cloud network peering, a rule change that opens a path or a new third-party connection all count, and each one resets the clock.

What counts as a segment

Start by listing every network that is supposed to be out of scope, because each one is a place to test from. Typical examples:

• The corporate user network and office Wi-Fi
• Guest and visitor Wi-Fi
• Development, test and staging environments
• Partner, supplier and remote access networks
• Other cloud accounts, subscriptions or VPCs owned by the same organisation

Then list the CDE itself, and the systems connected to it or able to affect its security, such as directory servers, jump hosts and logging. Those are in scope for PCI DSS, so they are the targets of the test rather than the places it starts from.

What a good test looks like

A segmentation test tries to reach the CDE from every network segment that is supposed to be out of scope, and records exactly what answered. In practice:

1. Map the zones: the CDE, the systems connected to it or that can affect its security, and every out-of-scope segment, each with its address ranges.
2. Write down the intended policy between zones: which flows are allowed, which are prohibited, and which are allowed only under conditions.
3. From a host in each out-of-scope segment, scan towards the CDE across all TCP ports and a meaningful set of UDP ports, with host discovery that does not rely on ping alone.
4. Compare what was reachable with the policy. Any prohibited path is a failure; any conditional path needs a documented business reason.
5. Triage every reachable service: required and documented, risk accepted, a false positive, or a gap to fix.
6. Retest after fixes, and again after any change to the segmentation.

Ports matter. Tests that scan only common TCP ports miss the UDP services, management interfaces and high ports that attackers use to cross boundaries.

Preparing for the test

Testers can only test what they can reach. Before testing starts, make sure they have:

• A current network diagram and the list of zones with their address ranges
• The firewall and security group rules that are meant to enforce the segmentation
• A testing host, or a network point, in every out-of-scope segment
• The intended policy: which flows into the CDE are allowed, and why

Reading the results

Not every open port is a failure, and not every closed one is a pass. A port that answers from an out-of-scope segment is a failure unless the policy allows that flow for a documented business reason. A port that is closed or filtered is a pass, as long as the scan genuinely covered it. The result for each path should say which it is, and why.

Cloud and modern networks

In cloud environments, segmentation is made of security groups, network ACLs, peering, private endpoints and identity policies. Test from inside each out-of-scope VPC or VNet, not just from the internet. A misconfigured peering connection or transit gateway can join segments that look separate on the diagram, and identity permissions can open paths that no network rule shows.

The evidence your QSA expects

• The methodology used, and who performed the test, showing their independence
• The date of the test, and the date of the last change to segmentation
• Every source segment tested from, with its address range
• The targets in the CDE, and the ports and protocols tested
• The results: what was reachable, from where, and whether that matches the policy
• The remediation of any failures, and the retest that proves it

Keep this together. An assessment is far easier when the QSA can see the zones, the policy, the results and the fixes in one place, rather than reconstructed from screenshots and email threads.

Common failures

• Testing from one or two segments instead of every out-of-scope segment
• Scanning only the common ports
• Forgetting that a firewall migration or a new cloud account counts as a change
• Fixing a failed path without retesting it
• Assuming the cloud network behaves the way the diagram says it does

A failed segmentation test is not just a finding. Until it is fixed, the systems that can reach the CDE are in scope for PCI DSS, with every requirement that brings.

How Cerberos Nexus runs it

In Cerberos Nexus, a segmentation test starts from zones with their address ranges and a zone-to-zone policy of allowed, prohibited and conditional paths. Results come in from nmap, Nessus, CSV or manual entry, every path is checked against the policy as a pass or a fail, and each reachable service is triaged. The client can accept or dispute each reachable service in the Client Portal, and the report is published from the same record. See how segmentation tests run in the platform.