What is Network Segmentation for PCI DSS? A Practitioner's Definition

Definition

Network segmentation for PCI DSS is the practice of separating systems that store, process, or transmit cardholder data from other business networks. In practical terms, it creates a defined cardholder data environment (CDE) with tightly controlled connections so fewer systems fall into PCI scope.

How it works

For PCI DSS, segmentation is about scope control, not just general network hygiene. If a system can freely connect to the CDE, or if it shares trust relationships, management paths, or weakly filtered network access, it may be considered in scope. The goal is to build clear boundaries and enforce them technically.

At a high level, implementation usually follows these steps:

Identify the cardholder data environment

Start by mapping where payment card data exists and where it flows. This includes payment applications, web servers that handle checkout, databases, jump hosts, authentication systems, logging systems, and any third parties with connectivity into the environment.

You need to answer:

• Which systems store, process, or transmit cardholder data?
• Which systems provide security services to those systems?
• Which admin workstations, jump boxes, or VPN paths can reach them?
• Which applications or integrations send traffic into the CDE?

If you cannot define the boundary, you cannot segment it.

Create a dedicated security zone

Most teams implement the CDE as a separate set of network segments or VLANs with explicit traffic controls between zones. Typical examples include:

• A PCI application subnet
• A PCI database subnet
• A management subnet for administrative access
• A logging or monitoring segment
• A DMZ for internet-facing payment components

The important point is that segmentation is enforced by security controls, not just labels. A VLAN by itself is not enough if routing and access are broadly open.

Restrict traffic to only what is necessary

PCI segmentation works best with a default-deny model. Only allow the exact ports, protocols, source addresses, and destinations required for business operations.

Examples:

• Web tier to app tier on a specific application port
• App tier to database on a single database port
• Admin access only from hardened jump hosts
• Logging only to approved SIEM or syslog collectors
• No direct user workstation access into database segments

This is where firewalls, router ACLs, cloud security groups, microsegmentation policies, and zero trust controls become important.

Technical Notes

A simple firewall policy model might look like this:

ALLOW 10.10.20.0/24 -> 10.10.30.10 tcp/443
ALLOW 10.10.30.0/24 -> 10.10.40.20 tcp/5432
ALLOW 10.10.50.5   -> 10.10.30.0/24 tcp/22
ALLOW 10.10.30.0/24 -> 10.10.60.15 udp/514
DENY  any -> 10.10.30.0/24 any
DENY  any -> 10.10.40.0/24 any

In a Linux host-based firewall, that may translate into rules such as:

iptables -A INPUT -s 10.10.50.5 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 10.10.20.0/24 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j DROP

These examples are simplified, but the principle is the same: permit only documented business flows.

Validate that segmentation is actually effective

This is the part many organizations underestimate. PCI DSS segmentation is only useful if it is tested and proven. Your assessor will want evidence that out-of-scope systems cannot reach the CDE except through approved paths.

Useful validation activities include:

• Internal network scans from non-CDE segments toward the CDE
• Firewall rule reviews
• Access path testing from user VLANs and server networks
• Verification of jump host controls and MFA for administration
• Review of cloud route tables, peering, security groups, and NACLs
• Confirmation that monitoring systems do not create uncontrolled backchannels

Technical Notes

A basic connectivity check from a non-CDE host might use:

nmap -Pn 10.10.30.0/24
nmap -sT -p 22,80,443,3389 10.10.40.20
traceroute 10.10.30.10

Expected outcome: only explicitly approved services respond, and unauthorized paths fail.

You should also review firewall logs for denied traffic:

action=deny src=10.20.15.44 dst=10.10.40.20 service=tcp/1433 rule=implicit-deny zone=corp-to-pci
action=deny src=10.20.18.10 dst=10.10.30.15 service=tcp/22 rule=block-admin-from-user-vlan

Those denied events help demonstrate that controls are both active and enforced.

Document the boundary for auditors and operators

For PCI DSS, segmentation is operational and evidentiary. You should maintain:

• Network diagrams showing the CDE boundary
• Data flow diagrams for payment processing
• Firewall and ACL rule documentation
• Asset inventory for in-scope systems
• Rule review and testing records
• Change management records for segmentation changes

If the boundary exists only in engineers’ heads, it will be difficult to defend during assessment and difficult to maintain during change.

When you’ll encounter it

You will encounter PCI DSS network segmentation whenever your organization accepts, processes, stores, or transmits payment card data. Common scenarios include:

• E-commerce environments with web checkout systems
• Retail stores with POS networks
• Call centers taking card payments
• Hospitality environments with payment terminals
• Service providers hosting payment applications
• Cloud migrations involving payment workloads

It also comes up when a business wants to reduce PCI scope. Without segmentation, large parts of the corporate network may become in scope because they can connect to systems in the CDE. With effective isolation, you can confine PCI controls to a much smaller environment.

For SMBs, this often becomes urgent after an acquiring bank, QSA, or internal audit asks for proof that card data systems are separated from general office IT. For enterprise teams, it often appears during redesigns, mergers, cloud adoption, or flat-network cleanup projects.

Common implementation mistakes

A few patterns repeatedly cause PCI segmentation problems:

• Assuming VLANs alone equal segmentation
• Leaving broad “any any” internal firewall rules in place
• Allowing direct admin access from user workstations
• Forgetting shared services like AD, DNS, NTP, backup, EDR, or logging
• Ignoring cloud connectivity such as VPC peering or transit gateways
• Failing to retest segmentation after network changes

The practical rule: if a system can materially impact the security of the CDE, it may still be relevant to PCI scope.

Related terms

Cardholder Data Environment (CDE)

The people, processes, and technologies that store, process, or transmit cardholder data, plus connected systems that can affect their security.

PCI DSS scope

The set of systems, applications, and network segments subject to PCI DSS controls.

Firewall allowlisting

A rule model that permits only approved traffic rather than broadly allowing internal communication.

DMZ

A controlled network segment used for internet-facing systems, often placed in front of internal PCI applications.

Microsegmentation

More granular workload-to-workload policy enforcement, often implemented in virtualized or cloud environments.

Jump host

A hardened administrative system used as the approved path for remote management into sensitive environments.

Bottom line

Implementing network segmentation for PCI DSS means building and proving a tightly controlled boundary around the CDE. Use dedicated segments, default-deny rules, limited administrative paths, and regular testing to ensure only necessary systems can communicate with payment infrastructure. Done well, segmentation reduces risk, simplifies compliance, and makes your PCI environment far easier to manage.

For further reading, check out our articles on security orchestration and the mobile incident response checklist.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.