Network Segmentation for PCI Compliance: A Practical Guide

Without segmentation, every networked system is potentially in scope. PCI DSS does not require merchants to place the CDE on a separate network segment. It does require control over which systems are in scope. Segmentation is the practical way most merchants limit that scope, but it works only when implemented correctly and checked continuously.

What Effective Segmentation Must Do

For a segment boundary to define a PCI scope boundary, it must prevent or restrict in-scope traffic. In this context, restrict means allowing only specifically defined, necessary communication. A firewall between the CDE and the rest of the network that permits any traffic on port 443 from a corporate workstation subnet to a payment application server does not restrict in-scope traffic. It allows a broad category of traffic, including direct interaction with the payment application server.

Effective segmentation requires narrow, specific, documented firewall rules between CDE systems and everything else. Each rule should explain its business purpose: why this source must reach this destination on this port. Remove rules that cannot be justified. Tighten rules that remain necessary but are broader than needed. This requires ongoing attention. Firewall rules build up through normal change management, and rules suitable when created may no longer fit the changed environment.

Why VLANs Alone Are Not Enough

One common approach puts CDE systems on a dedicated VLAN and treats its boundary as the segmentation control. VLAN isolation separates hosts at layer 2, preventing direct frame communication across VLANs without a routing layer. Once a routing path exists, however, VLAN isolation does not determine which traffic may pass between VLANs.

If a layer 3 switch or router handles routing between the CDE VLAN and corporate VLAN without access control lists, or with overly broad ACLs, the VLAN boundary is not a PCI segmentation control. Traffic may pass freely between VLANs. Firewall inspection at the routing point, using the narrow rules described above, turns that VLAN boundary into a PCI-qualifying segmentation boundary.

This issue is especially important where one core switch routes between all internal VLANs. The CDE VLAN may be clearly identified, but inter-VLAN routing without traffic inspection provides no effective segmentation. The standard fix is to place a firewall in the routing path between the CDE VLAN and every other VLAN.

Define What Segmentation Protects

PCI DSS 4.0 Requirement 1.3 requires network access controls to limit inbound and outbound traffic to what is necessary. Supporting documentation is substantial. Firewall and router rule sets must record the business justification for each rule and stay current. A rules document that is not updated when rules change does not satisfy the requirement.

Requirement 1.3.2 addresses inbound CDE traffic specifically: allowed traffic must be authorized by business need, and everything else must be denied. This supports a default-deny posture, with explicit permits for required traffic and a default that blocks the rest. A firewall without a correctly placed final default-deny rule is a finding.

Segmentation documentation most often breaks down during change management. A request to alter a firewall rule between a CDE segment and another segment must be checked against the segmentation model before approval. Does the change still restrict in-scope traffic as defined? Does it create a new path that gives more systems network access to the CDE? These answers belong in change approval, not in an annual audit.

Penetration Testing for Segmentation

Requirement 11.4.5 requires penetration testing to verify segmentation methods at least every 12 months and after any change to the segmentation controls or methods. Many merchants give this too little attention. A penetration test differs from a firewall rule review because it actively attempts to cross the boundary from outside the CDE and checks whether the controls actually block that path.

When a tester attempts to reach a CDE system from the corporate network, effective segmentation should prevent access. Access through a misconfigured rule, a firewall vulnerability, or an indirect path that bypasses the firewall shows that segmentation is not working as documented. The validation result serves as QSA evidence, not merely an internal security assessment.

Teams often miss the requirement to test after any change to segmentation controls or methods. They make a significant network change, update firewall rules, and continue without repeating the segmentation penetration test. Under 4.0, that omission is a finding. Changes to segmentation controls must be validated, not only reviewed, before the configuration is considered compliant.

Segmentation in Cloud Environments

The same principles apply in cloud environments through security groups, network ACLs, VPC peering and routing configurations, and private subnet design. In AWS, security group rules for inbound traffic to CDE EC2 instances must allow only necessary traffic from authorized sources. A new VPC's default security group allows all outbound traffic, and that default should be assessed rather than accepted without evaluating whether unrestricted outbound traffic from CDE instances is appropriate.

Cloud environments add management plane paths that can bypass network segmentation. Console access to CDE instances, API calls that change instance settings or security group rules, and IAM permissions for administrative actions against CDE resources all require evaluation. A firewall blocking traffic between a corporate network and a CDE virtual machine is only effective if controls also prevent an administrator from changing that rule through the cloud management console.

Verify Segmentation Beyond the Annual Test

The annual penetration test is a minimum, not a full program. It can find drift accumulated over the year, but not a misconfigured rule added two weeks ago through a change request. Because actively managed environments change firewall rules often, they need verification closer to the change cycle.

Automated rule analysis can compare current rule sets with documented segmentation policy and flag newly added rules that depart from it. It does not replace penetration testing, but it covers the period between annual tests when rule drift could otherwise go unseen. Reviewing rules on every change, together with an annual penetration test of the resulting configuration, gives stronger assurance than the annual test alone.