PCI DSS Network Segmentation

Why PCI DSS network segmentation matters

Without network segmentation, every system that can reach any CDE system is in PCI DSS scope. That typically means a flat corporate network with thousands of endpoints and servers, all of them pulled into the assessment. Network segmentation is the architectural pattern that draws a firm boundary around the cardholder data environment, isolates it, and allows the rest of the corporate network to remain out of PCI DSS scope.

Segmentation is not strictly required by PCI DSS. You can choose to run a flat network and put every system through PCI DSS testing. Almost no one does. The cost savings from segmentation are usually 10x or more across the life of a PCI DSS program -- fewer controls to implement, fewer systems to scan, fewer owners to interview, fewer evidence items to maintain. Segmentation is therefore the first design conversation in every PCI DSS program and the first architectural pattern a QSA will review.

What PCI DSS segmentation must enforce

PCI DSS segmentation must:

• Isolate the CDE from out-of-scope networks. Traffic between the two is denied by default.
• Allow only explicitly approved, business-justified traffic. Every exception is documented, owned, and reviewed.
• Use technical controls, not just policy. Segmentation must be enforced by firewalls, ACLs, network security groups, or equivalent controls -- not by trust or convention.
• Be validated. Penetration testing confirms the isolation holds in practice.

A segmentation design is not "we put the CDE on VLAN 200." It is a documented set of trust zones, a firewall ruleset that enforces traffic between them, a change process that governs rule modifications, a regular review cadence for the rules, and a testing program that validates the whole system every six or twelve months.

VLAN isolation in on-premise networks

The classic on-premise PCI DSS segmentation pattern is VLAN-based isolation:

• Dedicated VLANs for CDE systems, typically one per function (payment application servers, databases, jump hosts).
• Dedicated VLANs for CDE management traffic, separate from CDE data plane traffic.
• Stateful firewalls enforcing traffic policy between CDE VLANs and non-CDE VLANs.
• Access control lists or micro-segmentation within the CDE to limit lateral traffic.
• No routed paths from corporate VLANs to the CDE except through documented chokepoints.
• Separate DNS, NTP, and authentication services for the CDE where feasible.

Wireless networks deserve special attention. PCI DSS treats wireless access to the CDE as high-risk and requires strong authentication, unique credentials, and specific testing. Many organizations exclude wireless from the CDE entirely by routing wireless through a dedicated zone that has no direct path to cardholder data.

Cloud segmentation patterns

PCI DSS segmentation in the cloud is conceptually identical but uses cloud-native primitives:

• Dedicated VPCs or projects for the CDE, with explicit peering or transit rules to the rest of the environment.
• Tight security groups and network ACLs that enforce least-privilege traffic between the CDE and everything else.
• Private endpoints so cloud services consumed by CDE workloads do not traverse the public internet.
• Service mesh or identity-based network policies that enforce workload-level segmentation within the CDE.
• No shared accounts or projects between the CDE and non-CDE workloads unless explicitly in scope.
• Cloud provider landing-zone patterns that codify segmentation through infrastructure-as-code.

Cloud environments introduce their own risks. Misconfigured security groups, overly broad IAM roles that cross CDE boundaries, shared logging and monitoring services that collect CDE data into out-of-scope buckets -- all of these can undo segmentation. PCI DSS does not care whether segmentation is implemented with a physical firewall or a cloud security group; it cares whether the isolation actually holds.

Firewall rule design and review

PCI DSS Requirement 1 governs network security controls including firewall and equivalent rules. A strong segmentation program maintains:

• Documented ruleset with business justification for every allow rule.
• Deny-by-default posture with explicit allow rules.
• Rule review at least every six months, removing stale rules and validating business justification.
• Change management with documented approvals for every rule change.
• Separation of duties so the person requesting a rule change is not the person approving it or the person implementing it.
• Egress filtering -- outbound rules from the CDE to the internet and to non-CDE networks are explicitly defined.
• Ingress filtering from the internet into the CDE follows the same allow-list approach.

The PCI DSS v4.0 revisions of Requirement 1 explicitly cover "network security controls" rather than just firewalls, recognizing that modern environments use a variety of technologies. What does not change is the substance: deny by default, justify every exception, review regularly.

Validation testing (Requirement 11.4.5)

Segmentation only counts if it is validated. PCI DSS Requirement 11.4.5 requires penetration testing of segmentation controls at least every 12 months for merchants and every six months for service providers, plus after any change to segmentation.

A sound segmentation test:

• Places the tester on every out-of-scope network segment that is supposed to be isolated from the CDE.
• Attempts every protocol and every CDE IP from each out-of-scope segment.
• Documents what was and was not reachable.
• Escalates any unexpected reachability to remediation, then retests.

Testing is not a tabletop. It is hands-on, from real network positions. Evidence is the pen-test report, the tester's qualifications, and the retest results.

Operational risks that undo segmentation

Most segmentation failures are not architectural -- they are operational. Common patterns:

• Jump hosts that drift out of hardening baselines and become lateral-movement paths.
• Monitoring and logging tools that collect CDE data into out-of-scope systems, dragging those systems back into scope.
• Backup and recovery infrastructure that bridges the CDE to out-of-scope storage.
• Remote access vendors whose connections traverse segmentation boundaries because an exception was never formally reviewed.
• CI/CD pipelines that deploy to the CDE from out-of-scope build agents, creating a direct path that segmentation did not account for.
• Ephemeral compute that spins up into the wrong network segment because infrastructure-as-code templates drifted.

Treat segmentation as a product, not a project. Build segmentation reviews into every major change, every new vendor, and every architectural decision.

How this fits into PCI DSS compliance

Network segmentation is the force multiplier of a PCI DSS program. Requirement 1 (network security controls) is where segmentation is built. Requirement 2 (secure configurations) hardens the systems on either side of the boundary. Requirement 4 (cryptography in transit) protects any cross-boundary traffic. Requirement 7 and 8 (access control and authentication) govern who can cross. Requirement 10 (logging) records crossings. Requirement 11 (testing) validates isolation. A well-designed segmentation architecture pays dividends in every PCI DSS requirement you subsequently evaluate.

For mature PCI DSS programs, segmentation also becomes the substrate for broader security. A CDE segmentation pattern that works for PCI DSS is often reused for HIPAA-regulated data, for export-controlled environments, and for sensitive customer datasets. The investment compounds.

Common mistakes

• Flat networks where CDE and non-CDE systems coexist on the same subnet.
• Overly permissive firewall rules that negate the benefit of segmentation.
• Unreviewed rulesets that accumulate stale exceptions over years.
• Segmentation that stops at the network layer but ignores identity-based lateral movement.
• Monitoring and backup systems that bridge the CDE into out-of-scope storage.
• Missing segmentation testing or testing that does not cover every out-of-scope segment.
• Cloud security groups and VPCs that look segmented but are reachable via misconfigured peering or shared identity.
• VPN and remote access tools that punch holes through the boundary without documented justification.
• Shadow IT -- unsanctioned services on out-of-scope subnets that need CDE access and create undocumented exceptions.

How episki helps

episki connects to your firewalls, cloud security groups, and network tooling, continuously reconciling your segmentation design against the traffic that is actually flowing. Drift in firewall rules, new exceptions, and unexpected cross-segment traffic surface as PCI DSS findings before your next assessment. Explore the PCI DSS hub for how this fits into the broader program.