Segmentation testing: why reducing PCI scope needs proof

Network segmentation is one of the most effective ways to reduce the cost and effort of PCI DSS compliance. If the systems that handle card data are properly isolated, much of the rest of your network can fall outside the scope of the assessment. But PCI DSS does not take segmentation on trust. If you rely on it, you must prove it works, regularly. This article explains why and how.

Why segmentation matters

PCI DSS applies to the cardholder data environment (CDE) and to systems that are connected to it or could affect its security. Without segmentation, that can mean your entire network: every laptop, every server and every printer. With effective segmentation, scope shrinks to the systems that actually need to be there.

Segmentation is not mandatory, but the Council’s scoping and segmentation guidance explains how it can reduce scope, cost and risk. That reduction is only valid if the segmentation actually blocks the traffic it is supposed to block.

What PCI DSS requires

When segmentation is used to reduce scope, penetration testing must confirm that it works:

• Requirement 11.4.5 (all entities): segmentation controls must be tested at least once every 12 months and after changes to segmentation controls or methods.
• Requirement 11.4.6 (service providers only): the frequency increases to at least once every six months and after changes to segmentation controls or methods.

The tests must cover all segmentation controls and methods in use, confirm that they are operational and effective, and confirm that out-of-scope systems are isolated from the CDE. They must be performed by a qualified internal resource or a qualified external party with organizational independence. As one practitioner guide notes, merchant and service provider frequencies are not interchangeable: an organization that acts as both should apply the six-month cycle to its service provider environment.

Segmentation testing also connects to scope confirmation. PCI DSS v4 requires organizations to confirm their PCI DSS scope at least once every 12 months under requirement 12.5.2. Test results are a key piece of evidence for that exercise.

What a segmentation test looks like

A segmentation test is a focused penetration test. The tester typically:

1. Reviews network diagrams, firewall rules and data flows to understand the intended boundaries.
2. Places testing equipment in, or obtains access to, each out-of-scope network segment.
3. Attempts to reach CDE systems from each segment, using a range of protocols and ports.
4. Tests in the opposite direction where relevant, from the CDE towards out-of-scope segments.
5. Documents every path tested and its result, and flags any unexpected connectivity.

A quick port scan from one subnet is not enough. The test must cover every segmentation method you rely on, whether that is firewalls, VLAN access lists, cloud security groups or micro-segmentation.

Modern architectures make it harder

Segmentation was once mostly about firewalls between physical networks. Today, many CDEs span on-premises systems, public cloud and software-defined networks. In 2024, the Council published scoping and segmentation guidance for modern network architectures, covering zero trust, micro-segmentation and multi-cloud environments, as well as the challenge of keeping asset inventories accurate when cloud resources are short-lived.

The lesson is that segmentation controls change more often than they used to. An infrastructure-as-code deployment or a security group change can count as a change to segmentation controls, which triggers a retest.

Common findings

• A “temporary” firewall rule added for a project and never removed.
• Management interfaces reachable from the general office network.
• Shared services, such as directory, backup or monitoring servers, that bridge the CDE and other networks without being included in scope.
• Cloud security groups that allow broad internal address ranges.
• No test performed after a network redesign.

The bottom line

Segmentation can save significant time and money, but only if you can prove it works. Treat the segmentation test as the evidence that justifies your scope, and plan it around your change calendar, not just the assessment date.

Our security testing team at Ubitrak performs segmentation testing for merchants and service providers, and our PCI DSS overview explains how scope works. If testing reveals gaps, KW Consulting can help redesign and remediate your network. Contact us to plan your next test.

Sources

• PCI SSC blog: Now is the time to adopt the future-dated requirements of PCI DSS v4.x
• PCI DSS Guide: Network segmentation testing (11.4.5 and 11.4.6)
• PCI SSC blog: Scoping and segmentation guidance for modern network architectures
• PCI SSC Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation