PCI DSS v4.0 Requirement 11.4.5 requires annual penetration testing of segmentation controls that isolate the CDE (Cardholder Data Environment) from out-of-scope networks - and after any significant change to segmentation controls. The v4.0 update clarified that "testing" means active exploitation attempts, not just rule review. QSAs now want to see: scope of systems tested, specific bypass attempts made, evidence controls prevented each attempt, and a tester attestation. Here's how to structure both the test and the deliverable.
// 01 What changed from v3.2.1 to v4.0
PCI DSS v3.2.1 Requirement 11.3.4 required penetration testing of segmentation controls but was ambiguous about what "testing" meant in practice. Many organisations passed audits with a firewall rule review and a network diagram annotation. PCI DSS v4.0 tightened the language in Requirement 11.4.5 to explicitly require active testing - attempting to traverse the segmentation boundary from out-of-scope systems to CDE systems - and made the scope definition more precise.
Req 11.3.4 (old)
If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after changes. Confirm segmentation methods are operational and effective.
Req 11.4.5 (new)
Testing of segmentation controls must be performed at least once every 12 months and after any changes. Testing must verify all out-of-scope network segments cannot reach the CDE. Testing must include all segmentation methods used. Results must be retained as evidence.
The critical addition in v4.0 is the phrase "all out-of-scope network segments cannot reach the CDE." This shifts the burden: previously you had to show segmentation existed; now you must show every out-of-scope zone was tested and found unable to reach CDE scope. The surface area of the test grew substantially.
// 02 CDE scope in 2026: what's in, what's connected, what's out
The CDE includes all system components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus any system that could impact the security of those components. The scope definition challenge in modern environments is the "connected-to" clause - systems that connect to CDE systems are in scope unless effective segmentation prevents them from affecting CDE security.
| Zone | Scope status | Segmentation test direction |
|---|---|---|
| Payment processing servers | In CDE scope | Source of test attempts inbound from all other zones |
| Corporate LAN | Out of scope (if segmented) | Must be tested - cannot reach CDE |
| Dev / staging environment | Out of scope (if segmented) | Must be tested - high-risk zone, often shares secrets |
| SaaS tools (Salesforce, Slack) | Out of scope | Not network-addressable - scope documentation sufficient |
| Cloud management plane | In scope if accesses CDE VMs | Must be tested if management access to CDE instances exists |
| CI/CD pipeline | Connected system | If pipeline deploys to CDE, it's in scope - segment and test |
// 03 The segmentation test methodology QSAs accept
An acceptable Req 11.4.5 test is not a firewall audit - it's an active penetration test targeting the segmentation boundary. The tester starts from each out-of-scope network segment and attempts to reach CDE assets by every technically feasible path. The deliverable must document both the attempts made and the evidence that each was blocked.
Scope definition and network mapping
Obtain up-to-date network diagrams, VLAN assignments, firewall rulesets and routing tables. Identify every out-of-scope segment that shares physical or virtual infrastructure with the CDE. This becomes the test matrix.
Firewall and ACL analysis
Review firewall rules for any permit rules that allow traffic from out-of-scope segments to CDE IP ranges. This is not the test - it's reconnaissance that informs the active test targets. Misconfigured rules here often surface the most findings.
Active connection attempts
From each out-of-scope zone, attempt TCP connections to every CDE system on common ports (22, 443, 3306, 5432, 6379, 8080, etc.) and on ports implied by the application stack. Document successful connections as findings; document blocked attempts as evidence of working segmentation.
Bypass technique testing
Attempt to circumvent segmentation via: VLAN hopping (802.1Q double tagging), ACL bypass via spoofed source IPs, routing protocol injection, pivot through a shared service (DNS, LDAP, monitoring), and application-layer tunnelling through permitted ports (DNS over port 53, HTTP CONNECT).
Post-change validation
Any firewall change, VLAN reconfiguration or network architecture change that touches CDE adjacency requires a re-test of the affected boundaries before the next assessment cycle - not just at the annual cadence.
Deliverable and attestation
Produce a report documenting: test scope, systems tested from each zone, specific connection attempts and results, any successful bypasses (findings), evidence of blocking controls, and a tester attestation that all reachable out-of-scope zones were tested.
// 04 Common segmentation failures we find
Dev environment flat-routed to CDE VLAN
Development and staging servers share a broadcast domain with production payment servers. No firewall enforced between VLANs - ACLs exist on paper but are not applied to the physical switch trunk. Any developer workstation can reach the payment database directly.
Corporate VPN splits to CDE subnet via misconfigured route
The VPN concentrator routes 10.4.0.0/16 (CDE range) to corporate VPN clients due to an overly broad split-tunnel route added during a network expansion. Remote workers can reach CDE servers directly from their home networks.
Shared monitoring agent bridges out-of-scope to CDE
A Datadog / Splunk forwarding agent installed on both corporate and CDE servers communicates outbound on port 443 from all zones - including CDE - to the same SaaS collector. The agent configuration allows arbitrary command execution from the management console, bridging the CDE to the corporate management plane.
DNS server in CDE scope reachable from all zones
The DNS resolver serving CDE hosts is also the authoritative resolver for the corporate domain. All corporate workstations can query it directly. While DNS itself doesn't directly expose CHD, a compromised corporate system can use DNS cache poisoning or DNS tunnelling to interact with CDE infrastructure.
// 05 What a QSA-acceptable deliverable looks like
QSAs have become more specific about segmentation test deliverables since v4.0. The following structure is what consistently satisfies auditor evidence requests in our client engagements:
Section 1 - Scope statement: Explicit list of all CDE systems and IP ranges tested. List of all out-of-scope segments from which tests were conducted. Statement that all adjacently connected zones were included.
Section 2 - Test matrix: Table of every source zone × CDE destination system × ports tested × result (blocked / accessible). Every row must have a result. QSAs look for completeness - gaps in the matrix raise questions.
Section 3 - Bypass attempts: Documentation of VLAN hopping attempts, routing bypass attempts, shared-service pivot attempts. Result and evidence for each.
Section 4 - Findings: Any successful traversal documented as a finding with CVSS score, reproduction steps, and remediation recommendation.
Section 5 - Tester attestation: Signed statement from the qualified tester that all reachable out-of-scope zones were tested and results are accurately represented.
// 06 Cloud CDE segmentation: AWS VPC, Azure VNet, GCP VPC
Cloud-hosted CDEs introduce segmentation controls that are conceptually equivalent to hardware firewalls but technically different. QSAs have clarified that cloud security groups, NACLs, and VNet NSGs are acceptable segmentation controls - but the active test requirement still applies. You cannot substitute "I reviewed the security group rules" for "I attempted connections and confirmed they were blocked."
- AWS: Test from EC2 instances in each non-CDE VPC / subnet. Attempt connections to CDE security group members. Verify VPC peering routes don't bridge non-CDE to CDE VPCs. Test Transit Gateway route tables for CDE isolation.
- Azure: Test from VMs in each non-CDE VNet. Verify NSG rules and Azure Firewall deny-by-default. Test VNet peering - Azure peering is non-transitive but explicit peering between non-CDE and CDE VNets is a common misconfiguration.
- Kubernetes: Network policies must restrict pod-to-pod communication from non-CDE namespaces to CDE namespaces. Test that a compromised non-CDE pod cannot reach CDE service endpoints. Many Kubernetes deployments have no NetworkPolicy and are fully flat by default.