PCI Network Segmentation: How to Design and Test a Compliant Network

PCI network segmentation isolates the cardholder data environment (CDE) from the rest of your network, so that systems which cannot reach card data fall out of PCI DSS scope. It is not mandatory, but without it every workstation, printer and server on a flat network is in scope. If you rely on it, Requirement 11.4.5 requires segmentation testing at least every 12 months and after changes, and Requirement 11.4.6 requires service providers to test at least every six months and after changes.

The way you design your network decides how much of it a PCI DSS assessment has to cover. Get the architecture right and the CDE is small, well defined and easy to evidence. This guide explains how to design, build and prove segmentation under PCI DSS v4.0.1, the current version of the standard.

Key takeaways

• Map your card data flows before you design anything. Scope follows the data.
• Segmentation is not mandatory, but without it your whole network is in scope.
• Requirement 1 talks about “network security controls”, which covers cloud and software-defined controls as well as firewalls.
• VLANs alone are not segmentation; the traffic between them must pass through a control that enforces rules.
• Segmentation has to be proved by testing, not just drawn on a diagram.

Is network segmentation required for PCI DSS?

No, but it is the single biggest lever on the cost of compliance. PCI DSS applies to the CDE and to every system that can connect to it or affect its security. On a flat network, that is everything. Segmentation draws a boundary that an assessor can test, so systems outside it drop out of scope. To see what your current set-up means for your SAQ, try our free PCI compliance check.

The PCI Security Standards Council publishes an information supplement, “Guidance for PCI DSS Scoping and Network Segmentation”, in its document library. It is the reference most assessors use when judging whether a segmentation design holds.

How do you define the CDE before you segment?

Map the data flows

You cannot design a boundary until you know what it needs to contain. Trace every route a card number takes through the business: websites and APIs, payment terminals, telephone systems, databases, back-office applications and connections to payment processors. Requirement 1.2.4 requires an accurate data flow diagram, and 1.2.3 requires a current network diagram showing connections between the CDE and other networks.

Sort every system into a category

Shrink what you have to protect

The cheapest system to secure is the one that never touches card data. Before designing controls, ask whether you can shrink the CDE: outsource card capture to a compliant payment page, use tokenisation so internal systems handle tokens instead of card numbers, or use a validated point-to-point encryption (P2PE) solution for card-present payments. Our PCI DSS scoping guide goes into these decisions in more detail.

What makes PCI network segmentation work?

Requirement 1 in v4.0.1 is about “network security controls” (NSCs) rather than firewalls and routers. The control separating your CDE might be a hardware firewall, a virtual appliance, a cloud security group or a Kubernetes network policy. Whatever you use, the rules are the same:

• Deny all traffic by default and allow only what is needed (1.3.1 and 1.3.2 cover inbound and outbound CDE traffic).
• Document a business justification for every allowed service, protocol and port (1.2.5).
• Place NSCs between trusted and untrusted networks, and make sure systems that store card data are not directly reachable from untrusted networks (1.4).
• Review NSC rule sets at least once every six months (1.2.7).
• Control changes to NSC configurations through your change process (1.2.2).

Common segmentation methods compare like this:

Our guide to PCI DSS firewall requirements covers rule design and review in depth.

Are VLANs enough for PCI segmentation?

Not on their own. VLANs separate broadcast domains, but unless traffic between them passes through a control that enforces rules, they do not stop an attacker moving from one to another. Misconfigured trunk ports and permissive inter-VLAN routing are frequent findings. A VLAN counts as segmentation only when access control lists or a firewall restrict traffic into the CDE VLAN to what is justified, and testing proves it.

Zero trust principles fit well here. Do not trust a connection just because it comes from inside the network. Authenticate and authorise every request, grant least privilege (Requirement 7) and require multi-factor authentication for access into the CDE (Requirement 8).

How do you segment cloud and hybrid networks?

Public cloud is perfectly usable for a CDE, but responsibility is shared. The provider secures the physical infrastructure and its own services. You are responsible for your security groups, identity and access management, encryption keys, logging and the configuration of every service you use. Get the provider’s Attestation of Compliance and a responsibility matrix showing which requirements they cover.

In hybrid environments, pay attention to the link between on-premises and cloud. Private connections are not necessarily encrypted, so assess whether card data crosses them. Keep identity and policy management consistent across both sides so one environment does not become the weak point.

For containers, use namespace isolation and network policies to restrict pod-to-pod traffic, and ship logs off short-lived containers before they disappear. Our cloud penetration testing looks specifically at these configuration risks.

Which controls protect systems inside the CDE?

Segmentation defines the boundary. These controls protect what is inside it:

• Secure configuration (Requirement 2). Change or remove vendor defaults and apply hardening standards.
• Protecting stored data (Requirement 3). Do not store card data you do not need; where you must, render the card number unreadable and manage keys properly.
• Encryption in transit (Requirement 4). Use strong cryptography over open, public networks, which in practice means TLS 1.2 or higher.
• Access control and MFA (Requirements 7 and 8). MFA is required for all non-console access into the CDE (8.4.2) and all remote access from outside your network (8.4.3).
• Logging and monitoring (Requirement 10). Log access to system components and card data, and use automated mechanisms to review logs (10.4.1.1).
• Vulnerability management (Requirements 6 and 11). Patch promptly, run quarterly internal scans and external ASV scans, and test.

PCI segmentation testing: how often and who can do it

If you use segmentation to reduce scope, PCI DSS requires segmentation testing at least every 12 months, or every six months for service providers, and after any change to segmentation controls or methods. A qualified internal resource or a third party can do it, provided they are organisationally independent of the systems tested; they do not need to be a QSA or an ASV.

PCI DSS network segmentation testing checks that every segmentation control and method in use is operational and effective, and that all out-of-scope systems really are isolated from the CDE. In practice the tester tries to reach the CDE from each out-of-scope network segment, across every protocol and port, and documents what gets through. Anything that gets through either brings the source segment into scope or needs a rule fix and a retest before your assessment.

Segmentation tests sit alongside the annual internal penetration testing and external tests required by 11.4.2 and 11.4.3. Scheduling them together saves effort, and a firewall configuration review before testing often catches rule problems early.

Which segmentation mistakes are most common?

• Treating a VLAN as a security boundary without enforced rules between VLANs
• Forgetting security-impacting systems such as domain controllers and backup servers
• Allowing broad “any” rules for management traffic
• Assuming a cloud provider’s compliance covers your configuration
• Changing the network after the diagram was drawn and not updating it
• Testing segmentation from only one out-of-scope segment

Getting your design reviewed

Designing the network with the assessment in mind saves time and money later. Sovereign Secure is a PCI SSC-approved QSA company. Through our PCI DSS consultancy we review architecture and scope before you build, and our testers deliver the PCI DSS penetration testing and segmentation tests your assessor will ask for at your next PCI compliance audit.