Architecture Guide
Network Segmentation for PCI DSS — Reduce Scope, Reduce Cost, Reduce Risk
Effective network segmentation is the single most impactful strategy for reducing your PCI DSS assessment scope. This guide covers how to design segmentation architecture, implement it across on-premises and cloud environments, validate it with penetration testing, and avoid the mistakes that silently expand your scope.
Why Network Segmentation Matters for PCI DSS
Network segmentation is not a PCI DSS requirement in itself — you will not find a requirement that says "implement network segmentation." However, without it, every system on your network is in scope for PCI DSS. This is because any system that could impact the security of the cardholder data environment is considered "connected-to" and must meet all applicable PCI DSS requirements. On an unsegmented (flat) network, that means every server, workstation, printer, and IoT device must comply.
The practical impact is enormous. An organisation with 500 network devices on a flat network must assess all 500. With effective segmentation isolating 20 CDE systems, only those 20 (plus connected-to systems) require assessment. This translates directly into three categories of reduction:
Scope Reduction
Segmentation shrinks your cardholder data environment from "everything" to only the systems that genuinely store, process, or transmit cardholder data and the systems directly connected to them. Fewer in-scope systems means fewer configurations to harden, fewer systems to scan, fewer logs to collect, and fewer devices to include in penetration testing. Use the Scope Calculator to estimate how segmentation would reduce your specific assessment scope.
Cost Reduction
Assessment cost scales roughly linearly with scope. A QSA assessing 500 systems will charge significantly more than one assessing 20 systems. Beyond QSA fees, compliance costs include vulnerability scanning licences (priced per IP), penetration testing scope, security monitoring coverage, and the staff time required to maintain compliance controls. Organisations that implement effective segmentation typically reduce their annual PCI compliance costs by 40–70 per cent compared to a flat-network approach.
Risk Reduction
Segmentation limits the blast radius of a security breach. If an attacker compromises a system outside the CDE on a segmented network, they cannot pivot into the CDE without bypassing the segmentation controls. This containment buys time for detection and response. Every major payment card breach — from Target to Home Depot — exploited inadequate segmentation to move laterally from a compromised non-payment system into the cardholder data environment.
Types of Network Segmentation
Not all segmentation is equal. The PCI SSC's guidance on segmentation requires that the controls providing separation are adequate to prevent out-of-scope systems from communicating with or impacting the CDE. The method you choose must be appropriate for your environment and robust enough to withstand attack. Here are the four primary approaches, from most to least traditional.
Physical Segmentation
The strongest form of segmentation is physical separation — completely separate network hardware (switches, routers, cabling) for the CDE and non-CDE environments with no shared physical infrastructure. Physical segmentation eliminates the possibility of configuration errors creating unintended connectivity. However, it is the most expensive approach and is impractical for most organisations. It is primarily used in environments with extremely high transaction volumes or strict regulatory requirements beyond PCI DSS.
Logical Segmentation (VLANs with ACLs)
The most common approach uses Virtual Local Area Networks (VLANs) with access control lists (ACLs) on Layer 3 devices to create logical boundaries between network zones. Traffic between VLANs is forced through a firewall or router where ACLs enforce allow/deny rules. This approach is cost-effective and widely supported by enterprise network equipment. The critical requirement is that VLAN-to-VLAN traffic must traverse a security control — VLANs alone without enforced ACLs or firewall rules do not constitute adequate segmentation. Your assessor will verify that inter-VLAN routing is controlled, not just that VLANs exist.
Micro-Segmentation
Micro-segmentation applies security policies at the individual workload level rather than the network segment level. Using software-defined networking (SDN) or host-based firewall policies, each server or container has its own security boundary. Micro-segmentation provides the most granular control and is particularly effective in virtualised and containerised environments where traditional VLAN-based segmentation is difficult to implement cleanly. Tools like VMware NSX, Illumio, and Guardicore enable this approach. The challenge is operational complexity: managing per-workload policies requires mature automation and monitoring.
Cloud-Native Segmentation
Cloud environments provide their own segmentation primitives that map differently to traditional network concepts. Understanding these is essential for organisations running their CDE in public cloud infrastructure. For cloud-specific PCI compliance guidance, see our Cloud PCI Compliance guide.
- AWS — Use separate VPCs for CDE and non-CDE workloads. Security Groups provide instance-level stateful filtering, while Network ACLs provide subnet-level stateless filtering. VPC Peering or Transit Gateway connections between CDE and non-CDE VPCs should be avoided unless strictly necessary and controlled by restrictive Security Group rules. AWS PrivateLink can provide service connectivity without network-layer exposure.
- Azure — Use separate Virtual Networks (VNets) with Network Security Groups (NSGs) at subnet and NIC levels. Azure Firewall or third-party network virtual appliances (NVAs) control inter-VNet traffic. Azure Private Link provides service-level connectivity without exposing the CDE network. Application Security Groups (ASGs) enable micro-segmentation by grouping VMs by role.
- GCP — Use separate VPC networks with VPC firewall rules. Shared VPCs can be used with careful IAM controls, but separate VPCs provide stronger isolation. VPC Service Controls create security perimeters around GCP services to prevent data exfiltration. Hierarchical firewall policies enable organisation-wide segmentation rules.
Regardless of cloud provider, the principle is the same: CDE workloads must be isolated from non-CDE workloads by controls that prevent unauthorised traffic flow. Your assessor will review security group rules, network ACLs, and VPC/VNet architecture with the same scrutiny as on-premises firewall rulesets.
Designing Your Segmentation Architecture
Effective segmentation starts with a clear understanding of your cardholder data flows. Before designing network zones, you must know exactly where cardholder data enters your environment, which systems process it, where it is stored (if at all), and how it exits. Use the CDE Scoping Tool to map these flows systematically.
The Three-Zone Model
PCI DSS scoping recognises three categories of systems, which map naturally to three network zones:
- CDE Zone (In-Scope) — Systems that directly store, process, or transmit cardholder data. Examples: payment application servers, databases containing PANs, HSMs performing encryption, and payment terminals. Every system in this zone must comply with all applicable PCI DSS requirements.
- Connected-To Zone (In-Scope) — Systems that do not handle cardholder data themselves but have network connectivity to the CDE or could affect its security. Examples: Active Directory servers authenticating CDE users, jump servers used to access CDE systems, log aggregation servers receiving CDE logs, and management consoles for CDE infrastructure. These systems are fully in scope for PCI DSS assessment.
- Out-of-Scope Zone — Systems with no connectivity to the CDE and no ability to impact its security. These systems are outside the PCI DSS assessment boundary. The segmentation controls you implement must be strong enough that your assessor (and the penetration tester) can confirm these systems truly cannot reach the CDE.
Requirement 1: Network Security Controls at Boundaries
Requirement 1 mandates that network security controls are installed and maintained at every boundary between trusted and untrusted networks, and between the CDE and other internal networks. Under PCI DSS v4.0.1, the language has shifted from "firewalls" to "network security controls" to accommodate modern architectures — but the principle is unchanged: every zone transition must be controlled.
At each segmentation boundary, implement:
- Default deny-all rules — All traffic between zones must be denied by default. Explicit allow rules are added only for documented, authorised traffic flows.
- Stateful inspection — Network security controls must perform stateful packet inspection, not just packet filtering. This prevents attackers from crafting packets that bypass simple ACL rules.
- Documented rule justifications — Every allow rule must have a documented business justification (Req 1.2.5). Rules without justification are findings.
- Rule review cadence — Rulesets must be reviewed at least every six months (Req 1.2.7) or at the frequency defined by your targeted risk analysis. Stale rules accumulate over time and erode segmentation effectiveness.
Minimising the Connected-To Zone
The connected-to zone is where scope creep happens. Every system that has any connectivity to the CDE — even management connectivity, monitoring connectivity, or authentication services — becomes in-scope. To minimise this zone:
- Use dedicated management networks for CDE infrastructure rather than shared corporate management tools.
- Deploy separate authentication services (or a dedicated OU/realm) for CDE systems rather than sharing corporate Active Directory.
- Use dedicated log collectors for CDE systems rather than sending CDE logs to a shared corporate SIEM.
- Implement jump servers or bastion hosts as the only path into the CDE, rather than allowing direct access from corporate workstations.
Segmentation Validation Testing
Designing and implementing segmentation is only half the story. PCI DSS Requirement 11.4.5 explicitly mandates that penetration testing must validate the effectiveness of any segmentation controls used to reduce PCI DSS scope. If segmentation cannot be validated, the assessor must treat the entire network as in-scope.
What Segmentation Validation Tests
Segmentation validation testing attempts to confirm that systems in out-of-scope network zones cannot communicate with the CDE. The penetration tester places themselves in each out-of-scope zone and attempts to:
- Reach any IP address in the CDE zone on any port
- Reach any IP address in the connected-to zone on any port
- Bypass segmentation controls using techniques such as VLAN hopping, source routing, tunnelling, and exploitation of shared services
- Access CDE resources through indirect paths such as DNS tunnelling, ICMP tunnelling, or abuse of allowed protocols
If any test succeeds in reaching the CDE from an out-of-scope zone, segmentation is considered ineffective for that path, and the affected out-of-scope zone becomes in-scope.
Testing Frequency
Segmentation validation must occur:
- At least annually — As part of your annual penetration testing programme.
- After any segmentation change — Any modification to firewall rules, VLAN configurations, routing tables, or security group rules that affect CDE boundaries triggers a re-validation requirement.
- For service providers: every six months — PCI DSS requires service providers to perform segmentation validation testing at least every six months (Req 11.4.6), in addition to after any changes.
Choosing a Testing Methodology
PCI DSS requires penetration testing to follow an industry-accepted methodology (Req 11.4.1) such as NIST SP 800-115, OSSTMM, or PTES. Ensure your penetration testing provider explicitly includes segmentation validation as a test objective — many standard penetration test scopes focus on application and infrastructure vulnerabilities without specifically testing segmentation effectiveness. Request a dedicated section in the penetration test report covering segmentation validation results, including the specific tests performed and their outcomes.
Common Segmentation Mistakes
Even organisations that invest significantly in segmentation often make mistakes that inadvertently bring additional systems into scope or create paths an attacker could exploit to reach the CDE. These are the most common errors, each of which we have seen cause assessment failures or scope expansion.
1. Flat Networks with "Planned" Segmentation
The most fundamental mistake is operating a flat network where all systems share the same broadcast domain and routing table, while planning to implement segmentation "before the assessment." Segmentation is not a configuration change you flip on the week before your audit. It requires architectural design, implementation, testing, and a history of operational effectiveness. If your network is flat today, your entire network is in scope today. Begin segmentation design immediately and use the requirements browser to understand the full implications of Requirement 1.
2. Shared Credentials Across Zones
If the same Active Directory domain, the same administrative credentials, or the same service accounts are used in both CDE and non-CDE zones, segmentation is undermined. An attacker who compromises credentials in the out-of-scope zone can use those same credentials to access the CDE, regardless of network-level controls. This is how the Target breach progressed — credentials stolen from an HVAC vendor were usable across network zones. Implement separate authentication domains or, at minimum, separate administrative accounts for CDE systems with different passwords and MFA configurations.
3. DNS and DHCP Leakage
Shared DNS and DHCP services between CDE and non-CDE zones are frequently overlooked. If out-of-scope systems can resolve DNS names for CDE hosts, or if a shared DHCP server assigns addresses across zone boundaries, this creates a connectivity path that may bring the shared infrastructure into scope. Use dedicated DNS servers for the CDE or ensure that DNS resolution for CDE systems is restricted to authorised zones only. Similarly, use separate DHCP scopes with no cross-zone leasing.
4. Overly Permissive Firewall Rules
Rules that allow broad port ranges (e.g., "allow TCP 1024–65535") or entire subnets ("allow 10.0.0.0/8 to CDE") defeat the purpose of segmentation. Each rule should allow only the specific source IP, destination IP, and port required for a documented business function. "Any-to-any" rules within or between zones are common findings. Conduct a rule-by-rule review and remove or tighten any rule that is broader than necessary. Requirement 1.2.5 mandates documented justification for every allow rule.
5. Forgetting About Management Interfaces
Systems often have multiple network interfaces: a production interface and a management interface (iLO, iDRAC, IPMI, or cloud console access). If CDE servers have management interfaces accessible from out-of-scope networks, segmentation is bypassed. Ensure that all management interfaces for CDE systems are on a dedicated management VLAN that is also within the segmentation boundary. This applies equally to cloud environments where IAM-based console access to CDE resources must be restricted.
6. Not Re-Validating After Changes
Segmentation erodes over time. Every firewall rule change, VLAN modification, new server deployment, and cloud security group update has the potential to create an unintended path into the CDE. Organisations that validate segmentation once and then make months of infrastructure changes without re-testing accumulate risk. Implement change management controls that flag any modification to segmentation-related configurations and trigger re-validation testing per Requirement 11.4.5.
Documenting Segmentation with Network Diagrams
Your segmentation architecture must be thoroughly documented. The network diagram is the primary evidence artefact your assessor uses to understand and validate your segmentation approach. An incomplete or inaccurate diagram is one of the top reasons for assessment delays and findings.
What Your Network Diagram Must Show
- All network zones — Clearly labelled CDE zone, connected-to zone, and out-of-scope zones with their IP address ranges and VLAN identifiers.
- Segmentation controls — The specific firewall, router, or security device at each zone boundary with make/model and rule reference.
- All connections between zones — Every authorised traffic flow between zones, including management traffic, monitoring traffic, and authentication traffic.
- External connections — Internet connectivity, VPN termination points, third-party connections, and wireless network segments.
- Cloud environments — VPCs/VNets with subnet layouts, peering connections, transit gateways, and service endpoints.
- Data flow overlay — How cardholder data enters, traverses, and exits each zone. This may be a separate diagram or an overlay on the network diagram.
Keep your network diagram as a living document. Update it with every infrastructure change, and include a version number and last-modified date. Assessors will cross-reference the diagram against actual configurations, so discrepancies between the diagram and reality are immediate findings.
For automated network diagram generation and CDE boundary mapping, explore the CDE Scoping Tool which integrates with your infrastructure to produce assessment-ready diagrams.
Map Your CDE and Reduce Your Scope
GRCTrack's scoping tools help you define CDE boundaries, document segmentation architecture, and track compliance for every in-scope system.