PCI-DSS Network Segmentation — Requirements & Design Checklist 2026
8 min read · 3 May 2026
Network segmentation is the most powerful lever available to organisations that process payment card data. Done correctly, it can cut your PCI-DSS compliance scope by 80% or more — reducing assessment costs, audit time, and breach exposure in one architectural decision.
Definition
PCI-DSS network segmentation is the isolation of the Cardholder Data Environment (CDE) — the systems that store, process, or transmit payment card data — from the rest of the network. Effective segmentation reduces PCI-DSS compliance scope, limits breach impact, and is one of the most cost-effective controls an organisation can implement.
PCI-DSS v4.0 Notice
PCI-DSS v4.0 (effective March 2025) requires organisations to document and justify their segmentation controls. Untested segmentation does not reduce scope — you must verify controls annually.
What counts as in-scope for PCI-DSS?
Understanding scope is the first step in segmentation design. Three categories of systems fall within PCI-DSS scope:
- CDE systems — any system that stores, processes, or transmits Primary Account Numbers (PANs), cardholder names, expiration dates, or sensitive authentication data.
- Connected systems — systems that have unrestricted connectivity to CDE systems, including network infrastructure, authentication servers, and jump hosts. These are in scope regardless of whether they touch card data directly.
- Security systems — systems that monitor or manage CDE security (SIEM, IDS/IPS, log aggregators). These must be in scope for audit integrity.
Effective segmentation creates a hard boundary that prevents connected systems from being classified as CDE components. A VLAN boundary backed by stateful firewall rules — with no permitted path from corporate LAN to CDE — means corporate workstations are out of scope entirely.
PCI-DSS v4.0 Segmentation Requirements
The following requirements from PCI-DSS v4.0 directly govern how your network must be designed and documented:
| Requirement | Description | Network Design Implication |
|---|---|---|
| 1.3.2 | Restrict inbound and outbound traffic to the CDE to that which is necessary | Firewall rules must implement a default-deny posture with explicit permit rules for each required flow |
| 1.3.3 | NSC (network security control) rule sets reviewed at least every six months | Maintain a documented firewall change log; schedule biannual reviews in your compliance calendar |
| 6.3.3 | All system components protected from known vulnerabilities via security patches | CDE systems must be on a patching VLAN with controlled update paths; lateral movement from unpatched hosts must be blocked |
| 7.2.5 | All application and system accounts are managed by a documented policy | Management VLAN must be isolated; privileged access to CDE must transit a dedicated jump server |
| 11.3.1 | Internal vulnerability scans performed at least quarterly | Scanner must have access paths to CDE systems; scanner host is considered a connected system and must be secured accordingly |
| 12.3.2 | Targeted risk analysis for all controls not mandated at a specific frequency | Segmentation controls require a written risk analysis justifying the control approach; this must be reviewed annually |
Segmentation Design Checklist
Use this checklist when designing or auditing your CDE segmentation architecture:
How VP Compass helps with PCI-DSS segmentation
VP Compass ships a purpose-built Retail / PCI-DSS template that implements the segmentation architecture described in this guide. You get:
- A pre-built CDE zone with firewall boundaries and default-deny annotations already positioned
- A POS VLAN isolated from corporate traffic with a documented data flow path to the payment gateway
- A DMZ separating internet-facing systems from internal CDE components
- A Management VLAN with a jump server for privileged access, meeting Requirement 7.2.5
- AI-generated annotations explaining the compliance rationale for each segment — useful for QSA documentation packages
Export your completed diagram as a DrawIO file or PNG for inclusion in your SAQ or ROC documentation. The diagram becomes living compliance evidence — update it whenever your network changes, and it stays current for the next assessment cycle.
Frequently Asked Questions
Does network segmentation reduce PCI-DSS scope?
Yes — effective network segmentation is the primary mechanism for reducing PCI-DSS scope. By isolating the Cardholder Data Environment (CDE) from all other systems, you limit which systems require PCI-DSS assessment. However, segmentation must be tested annually by a qualified security assessor or internal team to be recognised as scope-reducing.
What firewall rules are required for PCI-DSS?
PCI-DSS Requirement 1.3 requires firewalls to restrict all inbound and outbound traffic to the CDE to only that which is necessary for cardholder data processing. All other traffic must be explicitly denied. Firewall rule sets must be reviewed at least every six months (Requirement 1.3.2), and all rule changes must be documented.
How do I document network segmentation for PCI-DSS?
PCI-DSS v4.0 Requirement 12.3.2 requires a targeted risk analysis for all segmentation controls. Your documentation must include a network diagram showing CDE boundaries, a list of all systems in scope, firewall rule justifications, and evidence of annual segmentation testing. VP Compass exports network diagrams suitable for QSA review.
What is a cardholder data environment (CDE)?
The Cardholder Data Environment (CDE) is the set of systems, people, and processes that store, process, or transmit cardholder data or sensitive authentication data — or that can directly affect the security of such data. This includes POS terminals, payment gateways, card databases, and any systems with direct network connectivity to those components.
Design your PCI-DSS network topology
Start from the Retail/PCI-DSS template — CDE zone, DMZ, POS VLAN, and management VLAN pre-configured.
Use the Retail/PCI-DSS template in VP Compass →