PCI DSS does not require you to segment your network. It does make the alternative expensive. Without segmentation, every system on the same network as your cardholder data environment (CDE) is in scope, and every requirement that applies to those systems is tested.
Segmentation is therefore a claim: these systems cannot affect the CDE, so they are out of scope. Your assessor does not take the claim on trust. You prove it with network security controls that enforce the boundary, documentation that explains it, and penetration tests that try to cross it.
This article covers what segmentation means in PCI DSS terms, which controls count, the shared services that pull systems back in, how cloud environments change the picture, and how to test and evidence the result. It assumes you have already reduced the data you hold, as covered in reducing your PCI DSS scope.
What segmentation means in PCI DSS terms
Segmentation isolates the CDE from systems that should be out of scope, so that a compromise of an out-of-scope system cannot reach or affect the CDE. The Council's scoping and segmentation guidance treats a network with no such isolation, often called a flat network, as entirely in scope.
Two consequences follow. First, the controls that provide the isolation are themselves in scope, because they affect the security of the CDE. Your firewalls, security groups and their management interfaces are tested like any other in-scope component. Second, segmentation is only as good as its weakest path. One permitted connection from an out-of-scope system to a CDE system makes the first system a connected system, and it comes back into scope.
What counts as a segmentation control
Requirement 1 speaks of network security controls (NSCs) rather than firewalls, which acknowledges that the job can be done by physical firewalls, virtual appliances, cloud security groups, network access control lists or other technology that enforces policy on traffic between networks. What matters is that the control actually blocks traffic it has not been told to allow.
Network separation that does not enforce anything is not segmentation. Two VLANs with unrestricted routing between them are one network for PCI DSS purposes.
The requirements under Requirement 1 describe what a well-run segmentation control looks like:
Configuration standards for NSCs are defined and followed (1.2.1).
An accurate network diagram shows all connections between the CDE and other networks (1.2.3), and a data-flow diagram shows account data flows (1.2.4).
Every allowed service, protocol and port is identified, approved and has a defined business need (1.2.5).
NSC configurations are reviewed at least once every six months (1.2.7).
Inbound and outbound traffic for the CDE is restricted to what is necessary, and everything else is specifically denied (1.3.1, 1.3.2).
NSCs sit between all wireless networks and the CDE (1.3.3).
The shared services that pull systems back in
The most common reason a segmentation design underdelivers is shared infrastructure. Systems that serve both sides of the boundary are, by definition, connected to the CDE. Typical examples:
Identity providers and directory services that authenticate CDE users
Logging, monitoring and security tooling that collects from CDE systems
Patch and configuration management servers that push to the CDE
CI/CD pipelines and artifact registries that deploy to the CDE
Jump hosts and administrator workstations that reach into the CDE
DNS and time servers used by CDE systems
None of these is a reason to abandon segmentation. They are a reason to keep the list short and deliberate. For each shared service, decide whether it can be dedicated to the CDE, whether the connection can be one-directional, and whether it can be hardened to the same standard as the CDE. Whatever remains on the list is in scope and should be documented as such.
Administrative access deserves particular care. A management network that can reach every system defeats segmentation from the inside. The principles in least privilege in practice apply to network paths as much as to accounts.
Segmentation in cloud environments
Cloud platforms make segmentation easier to build and easier to undo. Separate accounts, projects or subscriptions for the CDE give a clean starting point. Security groups and network policies give fine-grained control. But two things change compared with a data center.
First, the control plane is a path. Anyone with permission to change the security groups or routing around the CDE can remove the boundary without touching the network. The identities and roles that can modify CDE network controls are security-impacting, and access to them belongs in scope.
Second, connectivity is created by configuration. Peering, transit routing, shared VPCs and private endpoints can each connect environments in ways a network diagram drawn last year does not show. Rebuild the diagram from the current configuration, not from memory.
If you use tokenization, segmentation is what keeps token-only systems away from the tokenization system. The two techniques depend on each other, as tokenization and PCI DSS scope explains.
Testing that segmentation works
Requirement 11.4.5 applies whenever you use segmentation to isolate the CDE. It asks for penetration tests on segmentation controls at least once every 12 months and after any change to segmentation controls or methods. The tests must cover all segmentation controls and methods in use, follow your penetration testing methodology, and confirm that the controls are operational and effective and isolate the CDE from all out-of-scope systems.
Service providers carry a tighter cycle. Requirement 11.4.6 asks them to test segmentation at least once every six months and after any change.
The tester must be qualified and organizationally independent. They do not need to be a QSA or an ASV. In practice, a useful segmentation test:
Starts from each out-of-scope segment. Testing from one office network proves nothing about the others.
Tries every port and protocol toward the CDE. Not only the ones you expect to be blocked.
Tests the reverse direction. Outbound paths from the CDE matter, because requirement 1.3.2 restricts them too.
Records what was tested, from where and with what result. The report is the evidence, so it needs to show coverage, not only a conclusion.
Is repeated after remediation. A failed path that was fixed needs a retest result in the file.
Where segmentation usually fails
These findings recur:
Temporary rules that became permanent. A broad rule added for troubleshooting and never removed.
Rules without a business justification. Requirement 1.2.5 needs each allowed service to have one. "Legacy" is not a justification.
Missed reviews. The six-monthly review under 1.2.7 was done once, or was done without a record of what was reviewed.
Default permissive behavior. Cloud defaults that allow traffic within a network, left in place because the CDE was meant to be in its own network.
Changes after the test. The annual test passed, and three months of rule changes followed without a retest.
Segmentation evidence an assessor asks for
Have these ready and current:
Network and data-flow diagrams that match the live configuration
NSC rule sets, with a business justification for each allowed service
Records of each six-monthly rule review, with reviewer and date
Segmentation penetration test reports, including retests
Change records for every NSC change since the last assessment
Your scope confirmation under 12.5.2, listing segmentation controls and the justification for each out-of-scope environment
The PCI DSS framework page outlines how Requirement 1 fits with the other requirements that apply to in-scope systems.
How TrustLynce helps
TrustLynce collects evidence from your cloud systems on a schedule through evidence collection, so rule reviews, test reports and change records are timestamped and attributed. Continuous monitoring routes a control that starts failing to its owner, rather than leaving it for the next assessment.