PCI DSS v4.0 Segmentation Testing: What It Actually Involves and Why Most Companies Fail It

Segmentation testing is one of the most misunderstood requirements in PCI DSS. Every organization we work with believes their Cardholder Data Environment is properly isolated. They point to their firewall rules, their VLAN architecture, their cloud security groups. They have network diagrams that show clean lines between the CDE and everything else. The segmentation looks solid on paper.

Then we test it.

In our experience performing PCI segmentation validation across industries, we find segmentation failures in roughly seven out of ten environments on the first engagement. Not theoretical failures or documentation gaps, but actual network paths that allow traffic from non-CDE segments into the CDE. Firewall rules that look restrictive until you test the specific port ranges. VLANs that share infrastructure in ways nobody documented. Cloud security groups that were correct when deployed but drifted over time as teams made exceptions for operational convenience.

PCI DSS v4.0 Requirement 11.4.5 exists precisely because segmentation is hard to get right and even harder to maintain. If your organization uses network segmentation to reduce PCI scope, and nearly every organization does, this requirement is not optional. Your QSA will ask for the report. If the report does not exist, or if it does not demonstrate that segmentation is effective, your scope expands to include every system that was supposed to be out of scope. That is a materially different assessment, a materially different cost, and a materially different compliance timeline.

This guide covers what PCI DSS v4.0 actually requires for segmentation testing, what the testing methodology looks like in practice, the failures we find most often, and how to prepare your environment so that testing confirms your segmentation rather than disproving it.

What PCI DSS v4.0 Says About Segmentation Testing

Network segmentation is not a PCI DSS requirement. Nothing in the standard says you must segment your network. What the standard says is that if you choose to use segmentation to reduce the scope of your PCI DSS assessment, you must prove that the segmentation actually works. That proof comes from testing.

Requirement 11.4.5: The Core Mandate

Requirement 11.4.5 in PCI DSS v4.0 states that if segmentation is used to isolate the CDE from other networks, penetration testing is performed on segmentation controls to verify that they are operational and effective. This requirement applies to all entities that use segmentation, whether merchants or service providers.

The requirement is specific about what "operational and effective" means in practice:

• All segmentation controls are confirmed to be functional. This means the testing must verify that every firewall, ACL, security group, and network control that enforces segmentation is actively blocking unauthorized traffic. A rule that exists in configuration but is not applied, or is overridden by a more permissive rule, does not count.
• Segmentation isolates the CDE from all out-of-scope systems. Partial isolation is not isolation. If your segmentation blocks traffic from 95% of non-CDE systems but allows traffic from the remaining 5%, those 5% of systems are in scope, and so is everything connected to them.
• Segmentation is effective in both directions. Traffic must be blocked from non-CDE into CDE and from CDE to non-CDE through unauthorized paths. Bidirectional validation is not optional.

What Changed from v3.2.1 to v4.0

Under PCI DSS v3.2.1, segmentation testing existed under Requirement 11.3.4 with similar intent but less specificity. PCI DSS v4.0 made several important changes:

• Explicit penetration testing methodology requirement. v4.0 ties segmentation testing to a documented, industry-accepted penetration testing methodology. Under v3.2.1, some organizations argued that a network scan or firewall rule review constituted segmentation validation. That argument no longer holds. The testing must follow a methodology consistent with NIST SP 800-115, PTES, or an equivalent standard.
• Stronger language on validation. The v4.0 language shifts from verifying that segmentation "is adequate" to confirming that segmentation controls are "operational and effective." This is a higher bar. A firewall rule that exists but has never been tested against actual traffic is not proven to be operational. A security group that was effective at deployment but has since been modified is not proven to be current.
• The customized approach option. PCI DSS v4.0 introduced the customized approach, which allows organizations to meet the intent of a requirement through alternative methods. For segmentation testing, this means an organization could theoretically propose a different validation approach if they can demonstrate it achieves the same security outcome. In practice, the customized approach requires extensive documentation, a risk analysis, and QSA agreement. For most organizations, following the defined approach, performing actual segmentation penetration testing, remains the most straightforward path to compliance.
• Enhanced documentation requirements. v4.0 requires that the testing methodology, scope, results, and any remediation actions be documented. The QSA will review this documentation as part of the assessment. A verbal assurance that "we tested segmentation and it passed" is not sufficient.

Service Provider Semi-Annual Requirement

Requirement 11.4.6 applies specifically to service providers and mandates segmentation testing at least once every six months, not annually. This increased frequency reflects the elevated risk that service providers carry in the payment ecosystem. Service providers process or store cardholder data on behalf of multiple merchants, and a segmentation failure at a service provider can impact every merchant they serve.

The semi-annual requirement also applies after any changes to segmentation controls or methods, regardless of when the last scheduled test occurred. If a service provider modifies firewall rules, reconfigures VLANs, changes cloud network architecture, or makes any other change that affects how the CDE is isolated, segmentation testing must be repeated.

What Segmentation Testing Actually Involves

This is where the most significant misunderstanding exists. Segmentation testing is not a vulnerability scan. It is not a firewall rule review. It is not a network diagram audit. While all of those activities have value, none of them satisfy Requirement 11.4.5 on their own.

Segmentation testing is an active, hands-on validation that segmentation controls block unauthorized traffic between the CDE and all other network segments. Here is what the methodology looks like in practice.

Step 1: Identifying All CDE Boundaries and Data Flows

Before any testing begins, the tester must understand the architecture. This means reviewing network diagrams, data flow diagrams, firewall rule sets, VLAN configurations, and cloud security architecture. The goal is to identify every point where the CDE boundary exists, including every system that stores, processes, or transmits cardholder data and every network control that enforces isolation around those systems.

This scoping exercise is critical because segmentation testing is only valid if it covers all boundaries. Testing three of four CDE entry points and missing the fourth means the segmentation has not been validated. Common boundaries include:

• Firewall interfaces between CDE VLANs and corporate network VLANs
• Cloud VPC peering connections or transit gateway routes
• VPN tunnels that connect remote sites or third-party networks
• Management network access paths (out-of-band management, IPMI, iLO)
• Wireless network boundaries
• Third-party connectivity (payment processor links, managed service provider access)

Step 2: Testing from Non-CDE Segments into the CDE

From each non-CDE network segment, the tester attempts to reach systems within the CDE. This is not a simple ping test. The tester performs comprehensive port scanning, service discovery, and protocol-level testing to determine whether any traffic can traverse the segmentation boundary. The testing covers:

• Full TCP port range testing (1-65535). Many segmentation failures occur because firewall rules block common ports but leave high-numbered ports open. A rule that blocks ports 1-1024 but allows 1025-65535 is not segmentation.
• UDP testing on commonly abused ports. UDP is frequently overlooked in segmentation controls. DNS (53), SNMP (161/162), NTP (123), and syslog (514) are common UDP services that can bridge segments.
• ICMP testing. ICMP should be blocked across segmentation boundaries unless there is a documented business justification. ICMP can be used for network reconnaissance and certain tunnel techniques.
• Protocol-specific testing. Can an attacker establish an HTTP connection through the firewall? Can they use SSH to tunnel traffic? Can they leverage permitted protocols to carry unauthorized payloads?

Step 3: Testing from CDE Segments Outward

Segmentation must be effective in both directions. From within the CDE, the tester attempts to reach non-CDE systems and networks. This bidirectional testing catches scenarios where egress rules are more permissive than ingress rules, a common configuration error. An attacker who has compromised a CDE system should not be able to use it as a pivot point to reach the broader corporate network.

Step 4: Validating That Segmentation Blocks ALL Unauthorized Traffic

The key word is "all." Segmentation testing is a negative proof exercise. The tester must demonstrate that no unauthorized path exists, not merely that some paths are blocked. This requires methodical, comprehensive testing across every segment boundary, every protocol, and every port range. A passing segmentation test is one where the tester attempted to cross every boundary through every reasonable method and was blocked every time.

Step 5: Application-Level Segmentation Testing

Network-level segmentation is necessary but not always sufficient. Application-level segmentation must also be validated where it is used as a segmentation control. This includes:

• API gateway controls that are supposed to restrict which services can communicate with CDE applications
• Application-layer firewalls (WAFs) that enforce traffic policies between application tiers
• Database access controls that restrict which application servers can query databases containing cardholder data
• Container orchestration network policies (such as Kubernetes NetworkPolicies) that control pod-to-pod communication

Step 6: Wireless Segmentation Validation

If your environment includes wireless networks, segmentation testing must validate that wireless segments cannot reach the CDE. This includes testing whether a device connected to the corporate wireless network can communicate with CDE systems, whether rogue access points could bridge wireless and wired CDE networks, and whether wireless management interfaces are properly isolated.

Segmentation Approaches Compared

Not all segmentation strategies are equal. The approach you take directly impacts your PCI scope, your risk profile, and the cost and complexity of your assessment.

The middle column, segmented with validation, is the only approach that actually delivers scope reduction. The third column is where most organizations find themselves before their first segmentation test. They have invested in the infrastructure but have not invested in proving it works.

Common Segmentation Failures We Find

These are not theoretical risks. These are findings from our segmentation testing engagements, anonymized but representative of what we encounter regularly across industries.

• Firewall rules that allow "any" on specific ports from non-CDE to CDE. This is the most common failure. An administrator created a rule to allow a specific application to communicate across the boundary on port 443. But the source was set to "any" instead of the specific server IP, meaning every device on the non-CDE segment can reach CDE systems on that port. One overly broad rule negates the segmentation for that port across the entire segment.
• VLANs that share a trunk without proper ACLs. Two VLANs, one CDE and one corporate, carried on the same trunk port to a switch. The VLANs are logically separate, but without inter-VLAN routing ACLs, traffic between them flows freely at the switch level. The network diagram shows segmentation. The switch configuration does not enforce it.
• Management networks that bridge CDE and non-CDE environments. Out-of-band management interfaces (IPMI, iDRAC, iLO) on CDE servers are connected to the same management VLAN as non-CDE servers. An attacker who compromises the management network can reach CDE systems through their management interfaces, bypassing all perimeter firewall rules entirely.
• Cloud security groups that are too permissive. In AWS, an EC2 security group for a CDE instance allows inbound traffic from a security group ID that is shared across CDE and non-CDE workloads. Or a VPC peering connection exists between the CDE VPC and a development VPC with no route table restrictions. Cloud environments make it easy to create connectivity and difficult to track all the paths that connectivity enables.
• VPN connections that inadvertently bridge segments. A site-to-site VPN connects a remote office to the main data center. The VPN terminates inside the CDE perimeter because the payment application at the remote site needs to communicate with the central CDE. But the remote office network is a flat network, meaning every device at the remote site now has a network path into the CDE through the VPN tunnel.
• DNS that resolves across segment boundaries. CDE systems use the same DNS server as the rest of the corporate network. While DNS itself does not constitute a data breach, it provides reconnaissance capability. An attacker on the corporate network can enumerate CDE hostnames and IP addresses through DNS queries. More critically, if the DNS server is in the non-CDE segment and CDE systems depend on it, the DNS server becomes a connected-to system and falls into scope.
• Shared services that cross CDE boundaries. Active Directory, DHCP, NTP, syslog, SNMP monitoring, backup servers. These services are shared infrastructure by nature, and they frequently cross CDE boundaries. If your CDE servers authenticate against the same Active Directory domain as your corporate workstations, that Active Directory infrastructure is in scope. If your CDE servers send syslog to a centralized logging server that also collects logs from non-CDE systems, that logging server is in scope. Every shared service is a potential segmentation gap.

The Semi-Annual Testing Requirement in Practice

For service providers, Requirement 11.4.6 mandates segmentation testing at least every six months. For merchants using segmentation, Requirement 11.4.5 mandates annual testing at minimum. In practice, both cadences require planning, budgeting, and operational coordination.

Scheduling and Cadence

The most practical approach is to align segmentation testing with your broader PCI penetration testing schedule. Many organizations combine segmentation testing with their annual or semi-annual penetration test engagement, since the same testing team typically performs both. This reduces coordination overhead and ensures that the testing vendor has full context of both the segmentation architecture and the broader CDE environment.

For service providers on a semi-annual cadence, a common schedule is:

• Q1: Full annual penetration test including segmentation testing. Remediate any findings. Retest.
• Q3: Semi-annual segmentation test (focused on segmentation validation only, unless significant changes have occurred that warrant broader penetration testing). Remediate any findings. Retest.

Changes That Trigger Additional Testing

Both Requirements 11.4.5 and 11.4.6 require testing after changes to segmentation controls or methods. In practice, the following changes should trigger a segmentation retest:

• Firewall rule additions or modifications that affect CDE boundary interfaces
• New VLAN configurations or changes to existing VLAN assignments for CDE systems
• Changes to cloud VPC architecture, security groups, network ACLs, or route tables affecting CDE resources
• New VPN tunnels or changes to existing VPN configurations that connect to CDE networks
• Addition of new network segments that are adjacent to or connected to CDE segments
• Changes to shared services (AD, DNS, monitoring) that serve CDE systems
• Migration of CDE systems to new infrastructure (cloud migration, data center moves)

Documentation Requirements

Your QSA will expect documentation that covers the complete testing lifecycle:

• Testing scope identifying all CDE boundaries tested and the non-CDE segments from which testing was performed
• Testing methodology referencing the industry-accepted approach used
• Testing results with evidence showing that segmentation controls blocked unauthorized traffic at every boundary
• Any findings where segmentation was not effective, including the specific boundary, protocol, and port involved
• Remediation evidence showing that any findings were corrected
• Retest results confirming that remediated findings are resolved
• Date and duration of testing, plus qualifications of the team that performed it

Cloud Segmentation Challenges

Segmentation in cloud environments introduces complexities that do not exist in traditional data center architectures. The abstraction layers that make cloud infrastructure flexible also make segmentation harder to reason about and harder to validate.

AWS VPC Segmentation

In AWS, the primary segmentation unit is the Virtual Private Cloud (VPC). A properly segmented PCI environment typically places CDE workloads in a dedicated VPC with its own security groups, network ACLs, and route tables. Common segmentation failures in AWS include:

• VPC peering without restrictive route tables. When a CDE VPC is peered with a development or corporate VPC, the route tables in both VPCs must be configured to only allow specific, documented traffic. Default peering configurations often allow full connectivity between peered VPCs.
• Transit Gateway misconfigurations. AWS Transit Gateway simplifies connectivity between VPCs and on-premises networks, but it also creates potential paths between CDE and non-CDE segments if route tables and associations are not carefully managed.
• Shared security groups. A security group that references another security group as a source can inadvertently allow traffic from non-CDE resources if that referenced security group is applied to both CDE and non-CDE instances.
• IAM role cross-account access. IAM roles that allow cross-account or cross-VPC API access to CDE resources create application-level paths that bypass network segmentation entirely.

Azure VNet Segmentation

Azure uses Virtual Networks (VNets) as the primary segmentation construct. CDE workloads should reside in a dedicated VNet with Network Security Groups (NSGs) enforcing traffic policies. Azure-specific segmentation challenges include:

• VNet peering with default connectivity. Azure VNet peering enables full network-level connectivity between peered VNets by default. NSGs must be applied to subnets and NICs to enforce segmentation within and between peered VNets.
• Azure Firewall or NVA bypass paths. If CDE traffic is supposed to route through Azure Firewall but some subnets have user-defined routes that bypass it, those subnets have an unsegmented path to the CDE.
• Private endpoint connectivity. Azure Private Endpoints bring PaaS services into VNet address space. A private endpoint for an Azure SQL database containing cardholder data that is accessible from non-CDE subnets creates a segmentation gap.

GCP VPC Segmentation

Google Cloud uses a global VPC model where subnets span regions. This is fundamentally different from AWS and Azure where VPCs/VNets are regional constructs. GCP-specific segmentation considerations include:

• Shared VPC complexity. GCP Shared VPC allows a host project to share network resources with service projects. If the CDE and non-CDE workloads are in different service projects but share a VPC, firewall rules are the only segmentation control, and they must be meticulously configured.
• Firewall rule priority conflicts. GCP firewall rules are evaluated by priority number. A high-priority allow rule can override a lower-priority deny rule, creating unintended connectivity. Segmentation testing must account for the full firewall rule chain.
• VPC Service Controls. GCP offers VPC Service Controls as an additional boundary mechanism that can restrict API-level access to resources. These are a useful complement to network-level segmentation but do not replace it.

Container and Kubernetes Segmentation

Organizations running CDE workloads in Kubernetes face an additional layer of segmentation complexity. By default, all pods in a Kubernetes cluster can communicate with all other pods. This means a non-CDE workload running in the same cluster as a CDE workload has unrestricted network access to it unless Kubernetes NetworkPolicies are explicitly configured.

Segmentation testing in containerized environments must validate:

• Kubernetes NetworkPolicies are in place and enforced by the CNI plugin (not all CNI plugins enforce NetworkPolicies by default)
• CDE pods cannot communicate with non-CDE pods on unauthorized ports
• Namespace-level isolation is properly configured
• Service mesh policies (Istio, Linkerd) enforce mutual TLS and authorization between CDE and non-CDE services
• Container egress to external networks is restricted for CDE workloads

Preparing for a Segmentation Test

The organizations that pass segmentation testing on the first attempt are the ones that prepare thoroughly. The documentation you provide to your testing vendor directly impacts the quality and efficiency of the engagement. Here is what you should have ready.

• Current network diagrams with CDE boundaries clearly marked. This is the single most important document. The diagram should show every network segment, every firewall or routing device that enforces segmentation, and exactly where the CDE boundary sits. If the diagram is outdated, the test will be scoped incorrectly.
• Firewall rule exports for all devices that enforce CDE segmentation. Your testing vendor needs to understand what the rules are supposed to do before testing whether they actually do it. Export current rule sets from every firewall, router ACL, cloud security group, and network ACL that touches a CDE boundary.
• Data flow documentation showing how cardholder data moves through the environment. Data flow diagrams identify every point where cardholder data enters, is processed, is stored, and exits the environment. These flows define where the CDE boundary must be enforced and help the tester identify every path that needs validation.
• Complete list of all systems that store, process, or transmit cardholder data. Include IP addresses, hostnames, operating systems, and the specific function of each system. Also include connected-to systems such as management servers, monitoring infrastructure, and shared services that interact with CDE systems.
• Cloud architecture diagrams including VPCs, subnets, security groups, peering connections, and route tables. For cloud environments, the traditional network diagram is not sufficient. The testing vendor needs to understand the full cloud networking architecture, including IAM relationships that could create application-level paths between segments.
• Previous segmentation test results. If this is not your first segmentation test, providing the previous report allows the testing vendor to verify that previously identified findings have been remediated and to look for regression. It also provides context about known boundary configurations.
• Change log of any modifications to segmentation controls since the last test. If firewall rules were changed, VLANs were reconfigured, or cloud networking was modified, the testing vendor should know about it. These changes are the most likely areas where new segmentation gaps have been introduced.

Frequently Asked Questions

What is PCI DSS segmentation testing?

PCI DSS segmentation testing is a specialized security assessment that validates whether network segmentation controls effectively isolate the Cardholder Data Environment from all other network segments. Unlike a general penetration test, segmentation testing specifically verifies that no unauthorized network paths exist between CDE and non-CDE segments, that segmentation controls block all unauthorized protocols and ports in both directions, and that out-of-band access paths like management networks and backup connections do not inadvertently bridge segmented environments. It is required under PCI DSS v4.0 Requirement 11.4.5 for any organization that uses segmentation to reduce PCI scope.

How often does PCI DSS v4.0 require segmentation testing?

For merchants, Requirement 11.4.5 requires segmentation testing at least once every 12 months and after any changes to segmentation controls or methods. For service providers, Requirement 11.4.6 increases the frequency to at least once every six months, plus after any changes to segmentation controls. Any significant infrastructure change that could affect segmentation should trigger additional testing regardless of when the last scheduled test occurred.

What is the difference between segmentation testing and a penetration test?

A penetration test simulates a real-world attack against your environment, attempting to exploit vulnerabilities across network and application layers to assess overall security posture. Segmentation testing is a focused validation that specifically confirms network segmentation controls are functioning as intended. It does not attempt to exploit application-level vulnerabilities or escalate privileges. Instead, it methodically tests every network path between CDE and non-CDE segments to confirm that unauthorized traffic is blocked. PCI DSS requires both: a full penetration test under Requirement 11.4.1-11.4.4 and segmentation validation under Requirement 11.4.5. Many organizations combine them into a single engagement, but they serve distinct purposes.

Can you use segmentation to reduce PCI DSS scope?

Yes, and it is one of the most effective strategies for managing PCI DSS compliance cost and complexity. By properly isolating systems that store, process, or transmit cardholder data from the rest of your network, you limit the number of systems subject to PCI DSS requirements. However, segmentation only reduces scope if it is properly implemented and validated through testing. If testing reveals that segmentation is not working as intended, all connected systems fall back into scope, potentially making the assessment significantly larger and more expensive. The investment in proper segmentation and regular validation testing consistently proves to be the most cost-effective approach to PCI DSS compliance for organizations with complex network environments.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.