PCI DSS Network Segmentation

Network segmentation is not a PCI DSS requirement, but it is the single most effective way to reduce your compliance scope and cost. By isolating systems that store, process, or transmit cardholder data from the rest of your network, you limit which systems fall under PCI DSS requirements — and which systems an attacker can use as a stepping stone into your payment environment.

The Council's position is worth stating precisely: segmentation is optional, but scoping is not. Without segmentation, the entire connected network is in scope by default, and you must be able to demonstrate — with evidence — where your scope boundary sits and why everything outside it truly cannot impact the cardholder data environment (CDE).

Why Segmentation Matters

Without segmentation, every server, workstation, laptop, printer, and network device on a flat network is in scope for PCI DSS. Each must meet all applicable requirements: hardening, patching SLAs, logging, quarterly authenticated scans, access reviews, MFA. For a 200-person company, that is a program covering hundreds of endpoints for the sake of one payment flow.

With effective segmentation, the assessed environment shrinks to the CDE plus the systems connected to it. The consequences compound:

Fewer systems to harden, patch, scan, and log — Requirements 2, 5, 6, 10, and 11 apply to a fraction of your fleet.
A smaller SAQ or ROC — assessment hours track scope size almost linearly.
Reduced breach blast radius — a compromised marketing laptop cannot pivot into the payment network.
Simpler change management — most engineering work happens outside the CDE and never triggers PCI change controls.

The Three Scoping Categories

Modern PCI scoping guidance sorts every system into one of three buckets:

Category	Definition	PCI Requirements Apply?	Examples
CDE systems	Store, process, or transmit CHD/SAD, or sit on the same network segment as systems that do	Yes — fully	Payment application, database with PANs, POS terminals, anything sharing the CDE VLAN
Connected-to / security-impacting	Can connect to the CDE or affect its security, even without touching card data	Yes — for applicable controls	Jump hosts, Active Directory/IdP, SIEM, patch servers, backup infrastructure, admin workstations, CI/CD deploying to the CDE
Out-of-scope	No access to the CDE, cannot impact its security, and this is verified	No — but you must prove the isolation	Marketing systems, corporate wiki, dev environments with no CDE path

The middle category is where scoping exercises go wrong. Teams draw a firewall around the payment servers and declare victory, forgetting that the domain controller authenticating CDE admins, the monitoring agent's management server, and the engineer's laptop with SSH access are all "connected-to" and inherit substantial requirements. A system does not need to touch a PAN to be in scope — it only needs a path to influence systems that do.

Note also that "same segment" contaminates: any system sharing an unrestricted network segment with a CDE system becomes a CDE system, regardless of function. One legacy file server on the payment VLAN drags itself — and everything that talks to it — into full scope.

Designing Segmentation

An effective design process:

Find the data first. Run card data discovery across databases, file shares, logs, backups, email, and call recordings. You cannot bound an environment whose contents you have not verified — and discovery almost always finds PANs somewhere unexpected.
Map the flows. Diagram every path card data takes: capture, authorization, settlement, refunds, chargebacks, exports. Each flow endpoint anchors the CDE.
Define the boundary deliberately. Consolidate card-touching functions into as few systems and segments as possible. The best segmentation projects are partly re-architecture projects: tokenize the database, move capture to a hosted provider, retire the legacy flow — then segment what remains.
Enforce with default-deny controls. Between the CDE and everything else: explicit allow rules for documented business-need traffic, deny all else, in both directions.
Control the admin paths. All administrative access into the CDE should traverse a hardened jump host or bastion with MFA, from managed workstations, with session logging. Admin paths are the segmentation bypass assessors probe first.
Pull shared services out or lock them down. DNS, NTP, authentication, logging, and backup services used by the CDE either live in a controlled security-services segment or are treated as connected-to systems with the corresponding controls.

Segmentation Methods

Dedicated firewalls provide the strongest and most auditable segmentation: a physical or virtual firewall between the CDE and other segments, default-deny, with a documented business justification per rule and semi-annual rule review (which Requirement 1 demands anyway).

VLANs with ACLs provide logical segmentation but only when combined with enforced access control lists on the routing layer. VLAN separation alone is insufficient — misconfigurations and VLAN-hopping techniques exist, and an assessor will not accept "different VLAN" as isolation without a filtering control between them.

Cloud-native segmentation is often the easiest to do well. In AWS, Azure, or GCP, a dedicated account/subscription/project for the CDE is the cleanest boundary — account-level separation gives you IAM isolation, billing isolation, and blast-radius isolation in one move. Within it: separate VPCs/VNets, security groups with least-privilege rules, private subnets for anything holding data, no direct internet path to data stores, and tightly controlled peering or PrivateLink-style connections. Kubernetes environments need network policies and namespace isolation, and a shared cluster hosting both CDE and non-CDE workloads is very difficult to defend as segmented — a dedicated cluster is the safer answer.

Point-to-point encryption (P2PE) deserves mention for card-present merchants: a validated P2PE solution encrypts card data at the terminal such that the merchant's network never sees cleartext, removing that network from scope far more effectively than firewalling could.

Tokenization similarly shrinks scope on the storage side: if your application stores only provider-issued tokens and the vault sits with your payment provider, the systems holding tokens are candidates for de-scoping (tokens are not PANs), subject to verifying the token cannot be reversed and your systems cannot retrieve PANs at will.

Validating Segmentation

Segmentation you have not tested is segmentation you are assuming. PCI DSS Requirement 11.4.5/11.4.6 mandates segmentation penetration testing — at least annually for merchants and at least every six months for service providers, plus after any change to segmentation controls or methods.

A proper segmentation test:

Attempts to reach CDE systems from representative out-of-scope segments using all protocols, not just a ping sweep — port scans, protocol-specific probes, and attempts against the actual enforcement points.
Tests in both directions where the design claims bidirectional restriction.
Covers every out-of-scope segment type (office LAN, guest Wi-Fi, dev environment, VPN pools), not just one convenient sample.
Is performed by someone qualified and organizationally independent of the team that manages the controls (internal staff can qualify; the tester of a control should not be its administrator).
Produces a report demonstrating that the isolation holds — this report is a first-class assessment artifact your QSA or SAQ will lean on.

Failures found during segmentation testing are effectively scope findings: until fixed and retested, the "out-of-scope" systems that reached the CDE were in scope all along.

Common Mistakes

Flat networks with a paper boundary. A diagram showing a CDE that any workstation can actually route to is worse than no diagram — it documents the misrepresentation.
Permissive rules that negate the design. "Allow any from corporate to CDE on 443" or broad management-port ranges turn a firewall into decoration.
Forgotten infrastructure. Backup systems, monitoring/management planes, hypervisor hosts, out-of-band consoles (iLO/iDRAC), and shared storage frequently bridge the CDE and the corporate network invisibly.
Shared identity without controls. If corporate AD authenticates CDE systems, AD is connected-to; a domain admin compromise is a CDE compromise. Consider a separate identity tier or forest for the CDE, or at minimum privileged access controls and MFA on every CDE-relevant account.
Virtualization and container co-tenancy. CDE and non-CDE VMs on the same hypervisor put the hypervisor in scope; the same logic applies to shared Kubernetes clusters and shared CI/CD runners.
Wireless leakage. An access point on the CDE segment — or a corporate SSID bridged to it — expands scope to the airwaves; this is why quarterly rogue-AP detection exists.
Set-and-forget. Segmentation erodes with every "temporary" rule. Semi-annual rule reviews, change control on the boundary, and recurring testing are what keep the scope you designed.

Segmentation Checklist

Frequently Asked Questions

Is network segmentation required by PCI DSS?

No. You can be compliant with a flat network — but then everything on that network is in scope and must meet every applicable requirement. Segmentation is a scope-reduction strategy, not a control mandate. What is required is accurate scoping, and — if you claim reduced scope — segmentation penetration testing proving the boundary works.

Does using a separate cloud account count as segmentation?

A dedicated account/subscription/project for the CDE is one of the strongest segmentation primitives available, but only alongside controlled cross-account access: locked-down IAM roles, no broad peering, private connectivity with least-privilege rules, and MFA on the humans. The account boundary handles the network story; identity and deployment paths (CI/CD) still need explicit attention.

Are systems that only touch tokenized data in scope?

If the tokens are irreversible from your side and your systems have no ability to detokenize or reach PANs, token-only systems are strong candidates for out-of-scope treatment. You must be able to demonstrate that: how tokens are generated, where the vault lives (ideally with your provider), and that no in-house component can convert tokens back.

Who can perform the segmentation penetration test?

Someone with penetration testing competence who is organizationally independent of the administrators of the segmentation controls. It does not have to be an external firm for most merchants, though external testing is common and easier to defend. Service providers on the six-month cadence usually alternate or combine internal and external testing.

Does segmentation help if we're SAQ A?

Mostly no — SAQ A merchants have already achieved scope reduction through outsourcing, which is a stronger version of the same idea. Segmentation thinking still applies to the systems that serve your checkout page: keeping your web infrastructure separated from general corporate systems reduces the risk of the page-tampering attacks that v4.x specifically targets.

How much does segmentation typically save?

Organizations that move from a flat network to a tight CDE routinely cut in-scope system counts by 80–95 percent, with assessment cost and internal effort falling in rough proportion. The larger and messier the network, the bigger the payoff — and the more the project resembles re-architecture rather than firewall configuration.

In the next lesson, we will cover the changes in PCI DSS v4.0.

Scoping and segmentation decisions shape which tools and assessors you need. AuditXYZ helps you compare compliance automation platforms and auditors so you can find partners experienced with environments — and scope boundaries — like yours.

PCI DSS Network Segmentation: Reducing Scope and Risk