Network Segmentation Testing for PCI DSS Scope Reduction

Scope reduction is one of the most effective ways to reduce PCI DSS compliance cost. Every system within the cardholder data environment (CDE) is subject to the full set of PCI DSS controls; every system outside is not. Network segmentation is the primary technical mechanism for defining and enforcing the CDE boundary. PCI DSS Requirement 11.4.5 requires that segmentation controls be validated by penetration testing rather than by design review alone. This document describes how defensive VAPT programmes conduct segmentation testing and produce the evidence QSAs expect.

Scoping the CDE Correctly

PCI DSS defines the cardholder data environment as the systems, network components, and applications that store, process, or transmit cardholder data. It also includes systems connected to those systems if the connection is not adequately isolated. The "adequately isolated" qualifier is where segmentation becomes central to scope — systems connected to the CDE via effective segmentation are out of scope; systems connected without effective segmentation are in scope by default.

Effective segmentation, per PCI DSS guidance, prevents an attacker who compromises an out-of-scope system from reaching the CDE. This means segmentation is not just about network isolation but about the total set of controls that an attacker would need to bypass to move from one segment to another. Firewall rules, VLAN configurations, jump host requirements, VPN gateways, and application-layer proxies all contribute to segmentation. The assessment must consider the full set of controls, not just the network topology.

Common scoping errors emerge from underestimating what systems are connected to the CDE. Directory services, monitoring systems, backup infrastructure, and IT management platforms frequently have connectivity to systems in the CDE that brings them into scope. A defensive assessment enumerates every network connection into the CDE — not just the connections the CDE administrators are aware of — and validates whether each is protected by adequate segmentation controls.

Segmentation Testing Methodology

Requirement 11.4.5 requires penetration testing to validate segmentation. The testing must be conducted from out-of-scope network segments toward the CDE, with documented evidence of the attempted traversal and its result. Testing from in-scope segments outward does not satisfy the requirement because it does not answer the question the requirement is designed to answer — whether an attacker with access to out-of-scope systems can reach the CDE.

A defensive methodology enumerates out-of-scope network segments and establishes testing positions in each. From each position, systematic attempts are made to reach each documented CDE service by every available network path. Attempts include direct connectivity to CDE-hosted services, attempts to traverse via intermediate systems, attempts to bypass network controls via legitimate protocols (DNS tunneling, HTTP CONNECT, proxied protocols), and attempts to exploit any application-layer services that bridge between segments.

Each attempt is documented with the source position, target service, method used, and result — connection allowed, connection blocked, connection allowed but authentication required. The documentation is the evidence QSAs will review. "Attempted connectivity from out-of-scope segment X to CDE service Y using method Z produced result R" is the structural form each documented attempt should take. Attempts should cover representative CDE services and representative traversal methods; exhaustive testing of every possible combination is unnecessary if the representative coverage is well-designed.

Segmentation Failures That Frequently Emerge

Shared services are the most common source of segmentation failures. Systems like Active Directory domain controllers, DNS resolvers, NTP servers, monitoring collectors, and log aggregators often serve both in-scope and out-of-scope systems. Traffic between out-of-scope clients and these shared services provides a potential pivot path into the CDE if the shared service can be compromised. Assessments frequently find shared services that should be scoped in or should be duplicated with separate instances for in-scope and out-of-scope use.

Jump hosts and administrative bastions are intended segmentation controls that sometimes create the exact traversal path they were designed to prevent. A jump host that permits interactive sessions from out-of-scope operators to CDE systems, without proper authentication and authorization enforcement, effectively bridges the two environments. Assessments should test whether jump host controls enforce authentication that cannot be bypassed and whether the sessions cannot be leveraged for arbitrary CDE access beyond the specific administrative task the jump host was intended to support.

Cloud VPC and network segmentation frequently has gaps that on-premises segmentation would not have. Cloud VPCs with default routing tables, transit gateways connecting VPCs without egress control, and security groups that allow overly broad traffic can produce traversal paths that are not obvious from architecture diagrams. Assessments of cloud-hosted CDEs should include VPC configuration review alongside dynamic traversal testing because some cloud segmentation issues manifest as static configuration rather than as dynamic traversal opportunities.

Documenting Attempts and Blocks for QSA Review

QSAs assessing segmentation testing evidence look for specific documentation attributes: the tester's starting position on the network, the target service or system, the specific method attempted, the observed result, and evidence supporting the observed result (packet captures, log excerpts, screenshots). Evidence that describes what was attempted without evidence supporting the observed result is subject to follow-up questions during audit fieldwork.

The documentation should also cover the enumeration that preceded testing. Which out-of-scope segments were identified as testing positions and how? Which CDE services were identified as target services and how? Which network paths between them were considered and tested versus considered and excluded? Evidence of the enumeration demonstrates that testing was systematic rather than selective; assessments that appear to have selectively tested only paths expected to be blocked receive follow-up questions.

For attempts that succeeded — connections that should have been blocked but were not — the documentation should include the finding, its impact on segmentation validation, and the remediation status. Findings should be tied to specific segmentation controls that failed rather than to abstract "segmentation issues"; identifying the specific firewall rule, network policy, or configuration that permitted the traversal enables specific remediation and specific verification. Continuous VAPT platforms produce this documentation as a byproduct of operation.

Frequency and Change-Driven Testing

Requirement 11.4.5 requires segmentation testing annually for merchants and every six months for service providers. In addition, testing is required after significant changes to segmentation controls or the systems they protect. The interpretation of "significant change" has expanded in PCI DSS v4.0 to include changes to systems that provide segmentation, not just changes to CDE systems. Firewall rule changes, VPC configuration changes, and network topology changes all trigger the retesting requirement.

The change-driven testing requirement is where continuous VAPT provides substantial operational value. Change management processes that trigger automated segmentation validation on firewall changes, network policy changes, or infrastructure-as-code merges produce the evidence at the moment of change rather than requiring separate testing engagements. This eliminates the operational tension between change velocity and compliance evidence collection.

For organisations pursuing PCI DSS v4.0 assessment with mature segmentation practices, the segmentation testing evidence should be substantially more comprehensive than the historical annual pentest report. Continuous coverage aligned to change velocity, systematic enumeration of tested paths, and explicit documentation of attempts and results have become the audit-ready baseline. Organisations still producing annual segmentation reports as their primary evidence should expect increasing audit friction as QSA expectations continue to develop.