Network segmentation is the single most impactful technical decision in a PCI DSS compliance program. It determines the compliance scope — the number of systems subject to all 12 requirements. Effective segmentation can reduce the in-scope system count from hundreds to tens. Ineffective segmentation, or segmentation that fails QSA verification testing, collapses the entire scope reduction argument.
What Counts as Effective Segmentation
PCI DSS does not mandate any specific segmentation technology. It requires that CDE systems be isolated from all other systems such that: out-of-scope systems cannot reach CDE systems without passing through a controlled network security boundary, the CDE boundary is enforceable and verifiable, and the segmentation can be tested and proven to an independent assessor.
| KEY IDEA | VLANs alone are NOT sufficient for PCI DSS segmentation. A VLAN without a layer 3 firewall between it and other VLANs provides only traffic isolation at layer 2 — any router or layer 3 switch can forward traffic between VLANs. PCI DSS requires segmentation that is enforced by a network security control — a firewall, security group, or equivalent device that explicitly controls which traffic is permitted across the CDE boundary. |
Segmentation Architecture Options
| Architecture | Technology | Strength | Complexity | Best For |
|---|---|---|---|---|
| Dedicated firewall perimeter | Physical or virtual firewall at CDE boundary with deny-all default | Very high — industry standard | Medium | On-premise CDEs, hybrid environments |
| Cloud VPC isolation | Dedicated VPC/VNet with security groups; no peering to non-CDE accounts | Very high for cloud-native CDEs | Low-Medium (in cloud) | Cloud-native CDEs on AWS, GCP, Azure |
| VLAN + L3 ACLs | VLANs with inter-VLAN routing through ACLs on L3 switch | Moderate — dependent on ACL accuracy | Medium-High | Legacy networks; less preferred by QSAs |
| Physical separation | Dedicated physical hardware for CDE; no shared infrastructure | Highest — unambiguous isolation | High — separate hardware fleet | Highest-security CDEs; card processing cores |
| Micro-segmentation | East-west segmentation within CDE using host-based firewalls or SDN | Very high when combined with perimeter segmentation | High | Cloud-native, containerized, zero-trust CDEs |
Firewall-Based Segmentation Implementation
Perimeter Firewall Design
The CDE perimeter firewall enforces the boundary between CDE and all other networks. Configuration requirements: default deny-all inbound and outbound rules, explicit allow rules only for traffic required for business functions, stateful inspection, and logging of all connection attempts. The firewall must not be shared with non-CDE traffic unless the CDE traffic is processed in a dedicated context (separate zone, separate ruleset).
Rule Set for CDE Segmentation
Typical CDE firewall rules for a payment processing environment:
- ALLOW: Payment network → CDE (specific source IPs, specific protocols — Visa/MC network IPs to payment server)
- ALLOW: CDE → Payment network (specific destination IPs, specific protocols)
- ALLOW: Jump server (management zone) → CDE systems (SSH port 22 / RDP port 3389 from specific source IPs)
- ALLOW: CDE systems → Patch server (HTTP/HTTPS to specific patch management server IP)
- ALLOW: CDE systems → NTP server (UDP 123 to specific NTP server)
- ALLOW: CDE systems → DNS (UDP/TCP 53 to specific DNS server)
- ALLOW: CDE systems → SIEM (syslog 514 / HTTPS to SIEM server)
- DENY ALL: All other inbound and outbound traffic
| IMPORTANT | The outbound rule set is as important as the inbound rule set for PCI DSS. Requirement 1 requires that CDE systems cannot initiate unrestricted outbound connections. A finding common in assessments is CDE systems with unrestricted outbound internet access — meaning a compromised CDE system can communicate with an attacker's command-and-control server without restriction. Outbound filtering to a defined allow-list is required. |
Cloud Segmentation — AWS, GCP, Azure Implementation
AWS VPC Segmentation
For AWS-hosted CDEs: create a dedicated CDE VPC (do not co-locate CDE with non-CDE workloads), configure Security Groups with explicit ingress and egress rules (no 0.0.0.0/0 allow rules on CDE instances), use Network ACLs for subnet-level filtering as a second layer, enable VPC Flow Logs for all CDE subnets, and confirm no VPC peering exists between the CDE VPC and any non-CDE VPC.
GCP VPC Segmentation
For GCP: use dedicated VPC networks for the CDE project, configure firewall rules with deny-all defaults and explicit allow rules, enable VPC Flow Logs, and use VPC Service Controls to create API-level perimeters around sensitive GCP services used in the CDE.
Azure VNet Segmentation
For Azure: deploy CDE resources in a dedicated VNet, configure Network Security Groups at both subnet and NIC level, use Azure Firewall for centralized perimeter control, and enable NSG flow logs for traffic analysis.
Segmentation Testing — What QSAs Do
Segmentation Test Methodology
QSAs test segmentation by attempting to communicate from out-of-scope systems to in-scope CDE systems. The test confirms that: no direct network path exists from out-of-scope systems to CDE systems without passing through a controlled boundary, all traffic crossing the boundary is subject to the firewall rules, and no covert channels (DNS tunneling, HTTP smuggling, ICMP tunneling) allow boundary bypass.
Internal Segmentation Testing Before QSA Assessment
Organizations should conduct their own segmentation testing before QSA fieldwork. Tools: nmap for port scanning from out-of-scope systems toward CDE (all ports should be blocked), traceroute to verify traffic routing, and penetration testing tools for covert channel detection. Document the test methodology, the systems tested, and the results.
| An internal segmentation test that finds unexpected connectivity is not a failure — it is a success of the testing process. Finding a misconfigured firewall rule that allows out-of-scope systems to reach a CDE database server is far better discovered internally than by a QSA during fieldwork. Conduct segmentation tests quarterly and after every network change. |
Evidencing Segmentation for QSA Assessment
Evidence package for segmentation review:
- Network architecture diagrams with CDE boundary clearly marked
- Firewall configuration export (rules, zones, interfaces)
- Firewall rule list with documented business justifications
- Six-month firewall rule review records
- Segmentation test report with date, methodology, tester, and results
- VPC/VNet architecture diagrams for cloud environments
- Cloud security group rule exports
- Network flow log samples confirming blocked traffic at CDE boundary
| For Indonesian fintech organizations that have grown from a startup architecture (everything in one VPC or one VLAN) to a scale where PCI DSS compliance is required, network re-architecture is typically the most disruptive and time-consuming remediation in the entire compliance program. We recommend treating the network segmentation project as the critical path item — it must be complete and tested before any other technical remediation can be considered final. |