PCI DSS does not explicitly mandate network segmentation, but segmentation is the standard method organisations use to reduce cardholder data environment (CDE) scope and cut assessment cost. That reduction only happens under one condition: the isolation between segments must be real, enforced by purpose-built controls, documented, and tested. A network diagram showing separate zones proves nothing to a QSA if the firewall rules behind it are wide open.
If you take one action after reading this, make it this one: map every system that stores, processes, or transmits cardholder data, then plan a segmentation verification test against that map before your next assessment window.
- Segmentation reduces scope; it does not create scope reduction automatically
- Controls must be enforced, documented, and tested, not just architecturally implied
- Start with an accurate CDE inventory and dataflow map before touching firewall rules
Key Takeaways
Segmentation reduces PCI scope only when isolation is enforced by purpose-built controls, documented thoroughly, and verified through testing, not simply diagrammed.
| Point | Details |
|---|---|
| Segmentation isn’t mandatory, verification is | PCI DSS doesn’t require segmentation outright, but unverified segmentation gives no scope reduction at all. |
| Match controls to infrastructure type | Use firewalls and ACLs on-premises, microsegmentation for containers, and identity-based policy for dynamic cloud workloads. |
| Test at least annually and after changes | Run network-path, port, service-layer, and identity-layer tests, then keep the retest evidence on file. |
| Shared services are the usual failure point | DNS, Active Directory, and management tunnels commonly bridge zones unnoticed until an assessor finds them. |
| Re-solution builds and verifies segmentation | Re-solution combines Cisco-based network audits, Meraki and NGFW hardening, and managed testing cycles for ongoing PCI evidence. |
Table of Contents
- Core principles behind PCI DSS network segmentation that pass assessment
- Which segmentation methods suit which network types?
- How do you test and verify PCI network segmentation?
- Common segmentation failures that quietly expand your PCI scope
- What documentation and evidence do PCI assessors expect?
- A practitioner’s view on making segmentation defensible
- How Re-solution supports PCI network segmentation projects
- Sources
- FAQ
Core principles behind PCI DSS network segmentation that pass assessment
Assessor-resistant segmentation starts with a mindset shift: treat every system as in-scope until you can prove otherwise. Assuming a system sits outside the CDE because it “shouldn’t” talk to payment systems is exactly the gap QSAs are trained to find.
- Default to deny. Build rulesets on deny-by-default and least privilege, then open only the specific ports and protocols a business process actually needs.
- Use purpose-built enforcement. VLANs alone are a logical separation, not a security control. Pair them with stateful firewalls, restrictive ACLs, microsegmentation, or identity-based policies that actively block unauthorised traffic.
- Maintain an automated inventory. Manual spreadsheets go stale within weeks. An automated asset inventory tied to dataflow mapping keeps your CDE boundary accurate as systems change.
- Justify every exception. Any rule permitting cross-zone traffic needs a documented business reason, an owner, and a review date, because assessors flag unexplained “any-any” rules first.
Re-solution’s secure network design work with clients typically starts here, building the rule logic before any hardware conversation happens.
Pro Tip: Run a “why does this rule exist” audit before your assessor does. If nobody on the team can answer in one sentence, the rule is a candidate for removal.
Which segmentation methods suit which network types?
The right segmentation method depends entirely on how static or dynamic your infrastructure is. A retail chain running fixed store networks needs different controls to a SaaS platform running autoscaling containers.
- On-premises networks: VLANs and subnets combined with stateful firewalls and restrictive ACLs work well where topology is predictable and hosts rarely move. This remains the backbone of most retail and hospitality environments.
- Host and application-level controls: Host firewalls, sidecar proxies, and service mesh policies handle containers and ephemeral workloads where IP addresses change constantly. Microsegmentation ties policy to the workload itself rather than its address, which matters because ephemeral infrastructure breaks IP-based rules almost as soon as they’re written.
- Cloud environments: Dedicated accounts, projects, VPCs, or VNets with no peering between in-scope and out-of-scope environments keep the CDE boundary clean. AWS’s own guidance recommends PrivateLink for shared-service connectivity rather than peering, alongside carefully scoped IAM boundaries and security groups.
- Identity and zero trust: Attaching policy to workload or user identity, rather than network location, handles infrastructure that moves. This is the direction PCI SSC guidance now points modern architectures towards.
Most mature environments blend all four rather than picking one. Re-solution’s zero trust approach typically layers identity controls over existing network segmentation instead of replacing it outright.
How do you test and verify PCI network segmentation?
PCI DSS 4.x requires segmentation testing to confirm no unauthorised traffic actually crosses the CDE boundary, and that testing needs to happen at least annually and after any significant network change. Skipping retests after a firewall migration or a new site rollout is one of the fastest routes to a failed assessment.
A defensible testing programme covers four layers:
- Network-path validation. Attempt connections from every out-of-scope segment to every CDE host, confirming the traffic is actually blocked rather than merely assumed to be.
- Port and protocol checks. Verify TCP and UDP traffic against the specific ports your rules claim to restrict, not just a generic ping test.
- Service-layer tests. Shared services like DNS and Active Directory frequently bridge zones without anyone noticing, so test these explicitly rather than assuming they respect segment boundaries.
- Identity-layer tests in cloud environments. Check whether IAM roles can traverse account boundaries, since a misconfigured role is functionally identical to an open firewall port.
Segmentation testing in numbers: the practical difference between a pass and a fail rarely comes down to architecture, it comes down to whether test results, remediation tickets, and retest evidence exist for every boundary claimed in scope.
Automating these connection attempts and logging results centrally turns testing into a repeatable function rather than a scramble before assessment. Centralise firewall rule review on the same cadence, annually at minimum and after every significant change, and tie each rule back to its business justification.
Common segmentation failures that quietly expand your PCI scope
Most segmentation failures aren’t dramatic. They’re small permissive rules and forgotten shared services that widen the CDE far beyond what anyone intended.
- Overly permissive rules. Any-any exceptions left over from a troubleshooting session are the most common finding in practitioner assessments. Tighten scope immediately and require documented justification for anything broader than a single port.
- Shared services spanning zones. DNS, Active Directory, backup systems, and SIEM platforms often touch both the CDE and the wider network. Either bring them fully into scope or deploy dedicated instances or proxies that don’t cross the boundary.
- Management and vendor tunnels. Remote access paths for administrators or third-party vendors are a recurring bridge between segments. Route them through bastion hosts, privileged access management (PAM), and time-limited credentials rather than standing VPN access.
- Cloud IAM and peering gaps. Roles or peering connections that quietly cross account boundaries undo careful network segmentation. Enforce account separation and least privilege on every role, not just the ones you remember to check.
Pro Tip: Ask who last touched every “temporary” firewall rule older than six months. Most temporary rules outlive the project that created them.
What documentation and evidence do PCI assessors expect?
A QSA cannot verify a claim they cannot see evidence for. Documentation is what converts your architecture from a good idea into something an assessor will actually accept as scope reduction.
- Current CDE inventory and dataflow map. This should be automated where possible, showing every system that touches cardholder data and how it connects to everything else.
- Network diagrams aligned to that inventory. Diagrams that don’t match the live inventory are worse than no diagram, because they raise questions about what else is out of date.
- Firewall and ACL rule lists. Every rule needs a source, destination, port, protocol, and a business justification an assessor can read without asking you to explain it.
- Test reports and remediation records. Segmentation test results, any remediation tickets raised, retest evidence, logs showing denied traffic, and access review records all belong in the same evidence pack.
- Change-control records. Every rule change should trace back to an approved exception or change ticket, closing the loop between what’s documented and what’s actually running.
A practitioner’s view on making segmentation defensible
The gap between segmentation that looks right and segmentation that survives an assessment is almost always evidence, not architecture. Plenty of networks are genuinely well segmented and still fail assessment because nobody kept the test records, the rule justifications, or the change history that proves it.
Re-solution has worked as a Cisco partner for more than 35 years, building segmentation programmes around Meraki and Cisco NGFW deployments alongside dedicated OT segmentation for clients running operational technology alongside payment systems. A typical engagement moves through scoping and dataflow mapping, a network survey to baseline existing rules, hardening and control implementation, then segmentation testing with managed verification on an ongoing cycle rather than a one-off event.
Bringing in a specialist earns its keep fastest in multi-site estates, cloud-hybrid environments, OT-adjacent networks, or anywhere an assessor has already flagged a segmentation failure once. Repeat failures tend to come from the same root cause: nobody owns the testing cadence once the original project team moves on.
— Jacob
How Re-solution supports PCI network segmentation projects
Re-solution runs network audits and scoping assessments that identify exactly where your CDE boundary sits today, then builds segmentation designs and firewall hardening around Meraki and Cisco NGFW platforms rather than generic templates.
For organisations managing segmentation across multiple sites or hybrid cloud estates, Re-solution’s Network as a Service model adds managed verification, so testing happens on a fixed cadence instead of depending on whoever remembers to schedule it. OT-adjacent environments get dedicated OT network segmentation design where payment systems and operational technology share infrastructure, and every engagement can include an evidence pack built specifically for assessor review, covering rule justifications, test results, and change records in the format QSAs expect to see.
If your last assessment raised segmentation questions you’re still not confident you’ve answered, request a network audit and ask specifically for a segmentation health check. It’s the fastest way to find out where your scope actually sits before an assessor tells you.
Sources
- New Information Supplement: PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures
- Guidance for PCI DSS scoping and network segmentation (PCI SSC)
- Updated whitepaper: Architecting for PCI DSS scoping and segmentation on AWS
- Network segmentation for PCI DSS: architecture patterns that pass assessment (practitioner blog)
FAQ
What is network segmentation in PCI DSS?
It’s the practice of isolating systems that handle cardholder data from the rest of the network using enforced, tested controls, so that only in-scope systems fall under full PCI DSS requirements.
What are the six major principles of PCI DSS?
PCI DSS organises its requirements around six control goals: building and maintaining a secure network, protecting cardholder data, maintaining a vulnerability management programme, implementing strong access control, monitoring and testing networks regularly, and maintaining an information security policy.
What does “PCI network” mean?
It refers to any network segment that stores, processes, or transmits cardholder data, commonly called the cardholder data environment or CDE, along with any connected systems that could affect its security.
What are the types of network segmentation?
The main types are network-level segmentation using VLANs, firewalls and ACLs; host or application-level controls including microsegmentation; cloud segmentation using dedicated accounts and VPCs; and identity-based segmentation tied to zero trust policy, which Re-solution’s zero trust approach applies alongside traditional network controls.
Recommended
- OT network segmentation for cybersecurity and OT teams
- Network infrastructure checklist: optimise compliance
- Network Access Controller Guide | Secure Network | Re-Solution
- Network Access Controller Guide | Secure Network | Re-Solution
