PCI DSS Network Segmentation: A Practical Guide to Reducing CDE Scope

Short answer: PCI DSS network segmentation isolates the cardholder data environment (CDE) from the rest of your network so that only the systems that store, process, transmit or can affect cardholder data stay in scope. PCI DSS does not strictly require segmentation, but without it your entire network is in scope. If you rely on it, you must test it.

Related guides:

• 7 common mistakes in PCI DSS scope assessment
• How to become PCI compliant in three steps
• PCI DSS penetration testing

Key takeaways

• Segmentation is optional under PCI DSS, but it is the most common way to keep a PCI assessment manageable. A flat network puts every connected system in scope.
• Scope has three practical tiers: CDE systems, connected-to or security-impacting systems, and out-of-scope systems. Segmentation only moves systems into the third tier when it truly blocks access to the CDE.
• Good options for SaaS teams include dedicated cloud accounts or VPCs, tightly written security groups, microsegmentation and, most powerfully, keeping card data out of your environment with tokenization or a hosted payment page.
• If you use segmentation, PCI DSS v4.0.1 Requirement 11.4.5 requires penetration testing of segmentation controls at least every 12 months and after changes. Service providers must test at least every six months under Requirement 11.4.6.
• Accurate network and data flow diagrams (Requirements 1.2.3 and 1.2.4) are the backbone of any segmentation claim. Assessors start there.

What is PCI DSS network segmentation, and is it required?

PCI DSS network segmentation is the use of technical controls to isolate systems that handle cardholder data from systems that do not, and the standard treats it as a recommended scope reduction method rather than a requirement.

By default, PCI DSS applies to the CDE and to every system connected to it or able to affect its security. On a flat network, that means almost everything. Segmentation draws a hard line so that systems on the other side genuinely cannot reach the CDE and fall out of scope. The payoff is fewer systems to harden and monitor, a smaller assessment and a lower blast radius if an out-of-scope system is compromised.

The catch is that segmentation is a claim you must prove. If an assessor finds a path from an "out-of-scope" network into the CDE, that network comes back into scope.

CDE, connected-to and out-of-scope: which systems are in scope?

A system is in scope if it is part of the CDE, if it connects to the CDE, or if it can affect the security of the CDE; it is out of scope only when it has no such access or influence.

The PCI Security Standards Council's scoping guidance describes these tiers. In plain terms:

Category	What it means	Typical SaaS examples
CDE systems	Store, process or transmit cardholder data or sensitive authentication data, or sit on the same unsegmented network as systems that do	Payment API service, database holding PAN, card data vault
Connected-to or security-impacting systems	Can reach the CDE, or provide security services to it	Identity provider, bastion hosts, CI/CD pipeline deploying to the CDE, log aggregation, patch and configuration management
Out-of-scope systems	Cannot connect to any CDE system and cannot affect its security	Marketing site, internal wiki, a product workload in a separate account with no route to the CDE

Two points trip up many teams:

1. Connected-to systems are fully in scope for the requirements that apply to them. Your SSO provider or deployment pipeline is not "partly PCI". It needs controls appropriate to its role.
2. Shared services cut both ways. A management agent that can push commands into the CDE pulls its control plane into scope. Give the CDE separate instances where practical.

Which segmentation approaches work for SaaS and SMBs?

The right approach depends on where card data lives, but most SaaS teams combine cloud network isolation with strict access rules, and the strongest option is to avoid handling card data at all.

Approach	How it isolates the CDE	Good fit when	Watch out for
VLANs plus firewall ACLs	Places CDE systems on their own network segment, with firewall rules permitting only required traffic	You run offices, stores or on-premises infrastructure	VLANs alone are not segmentation. The filtering rules do the work
Cloud accounts, VPCs and security groups	Puts the CDE in a dedicated account or VPC, with security groups and network ACLs allowing only defined flows	You run on a public cloud	Peering, transit gateways and broad IAM roles can quietly reconnect environments
Microsegmentation	Enforces policy per workload or service, often using identity-based rules or a service mesh	You run containers or Kubernetes with many services	Policies must be enforced, not just observed, and must be evidenced
Tokenization or outsourcing	Replaces PAN with tokens or sends card entry to a validated third party, so your systems never see card data	You can use a payment provider's hosted fields, iframe or redirect	Your page that loads the payment form can stay in scope, depending on your SAQ type and integration

Tokenization and outsourcing are scope reducers, not segmentation. They change what your systems touch, which is often more effective than isolating it. A hosted payment page or embedded iframe from a PCI DSS validated provider can mean a much lighter assessment, although SAQ eligibility depends on the exact integration and your acquirer. Whether the payment page script requirements (6.4.3 and 11.6.1) apply also depends on your SAQ type and integration, and since a January 2025 update SAQ A no longer lists them for merchants that fully outsource card entry, using an eligibility criterion about script attacks instead (see the PCI SSC document library). Our guide to PCI for SaaS covers those trade-offs.

On AWS, a common pattern is a dedicated CDE account with its own VPC, no peering to general workloads and tightly scoped cross-account roles. Our AWS PCI DSS compliance guide explains what the provider covers and what remains yours.

HealthTech note: if you bill patients or process copays, keep payment flows separate from systems handling protected health information, or clinical systems can be dragged into PCI scope.

How does Requirement 1 shape your segmentation controls?

Requirement 1, "Install and Maintain Network Security Controls", is where your segmentation design is documented, configured and reviewed, and assessors use it to judge whether your boundary is real.

PCI DSS v4.0 (now v4.0.1) replaced "firewalls and routers" with network security controls (NSCs), which include cloud security groups and virtual firewalls. The sub-requirements most relevant to segmentation include:

• 1.2.3: an accurate network diagram showing all connections between the CDE and other networks, including wireless networks.
• 1.2.4: an accurate data flow diagram showing all account data flows across systems and networks, updated as the environment changes.
• 1.2.7: NSC configurations reviewed at least once every six months to confirm they are still relevant and effective.
• 1.3.1 and 1.3.2: inbound and outbound traffic to and from the CDE restricted to only what is necessary, with all other traffic denied.

Every allowed rule into or out of the CDE should have a documented business justification and an owner. "Allow all from the corporate VPN" turns a segmentation claim into a finding. Requirement 12.5.2 also asks you to document and confirm your PCI DSS scope at least every 12 months and after significant changes, and 12.5.2.1 raises that to every six months for service providers. Either review is a natural point to revisit your segmentation design.

What does segmentation testing under PCI DSS v4.0.1 involve?

If you use segmentation to reduce scope, you must run penetration tests that confirm the segmentation controls work and that out-of-scope systems are actually isolated from the CDE.

The frequencies are set out in two requirements:

Requirement	Applies to	Minimum frequency
11.4.5	All entities using segmentation to isolate the CDE	At least once every 12 months and after any change to segmentation controls or methods
11.4.6	Service providers only, in addition to 11.4.5	At least once every six months and after any change to segmentation controls or methods

Segmentation testing typically confirms that:

1. Each out-of-scope segment cannot reach any CDE system on any port or protocol, other than flows you have documented and justified.
2. Segmentation controls are operational and effective, tested from the out-of-scope side toward the CDE.
3. Any isolation you use to separate systems with differing security levels works as intended, if you rely on it (11.4.5 ties this to Requirement 2.2.3).

Testing must be done by a qualified internal resource or qualified external third party with organizational independence from the tested systems. Keep the methodology, results and retest evidence. It is usually scoped alongside your wider penetration test, which our PCI DSS penetration testing guide covers in more detail.

What mistakes break CDE segmentation?

Most segmentation failures come from forgotten connections rather than weak firewalls, so the boundary looks sound on paper while a side path stays open.

• Treating VLANs as isolation. Without filtering between them, VLANs are just labels.
• Shared management planes. Jump hosts, admin workstations or configuration tools that reach both sides of the boundary.
• Cloud peering and transit routes. A VPC peering connection added for a one-off migration and never removed.
• Over-broad identity permissions. Network isolation means little if a role in the general account can modify CDE resources.
• Stale diagrams. Diagrams drawn for last year's assessment that no longer match production.
• Testing only once. Skipping a retest after a firewall migration, a new region or a re-architecture.

Step-by-step plan and segmentation checklist

A workable segmentation program follows a simple sequence: find the data, minimize it, isolate what remains, document it and test it on a schedule.

1. Map account data flows, including logs, backups and support tools.
2. Reduce before you segment. Move card entry to tokenization or a validated hosted payment option where you can.
3. Define the CDE boundary. List every system that stores, processes or transmits card data, then every system that connects to it or affects its security.
4. Choose the isolation method. Dedicated cloud account or VPC, filtered network segments or microsegmentation.
5. Write deny-by-default rules. Allow only justified flows, each with an owner and business reason.
6. Separate shared services. Give the CDE its own administration paths, secrets and, where practical, tooling instances.
7. Document the result. Update the network diagram and data flow diagram.
8. Test the boundary. Commission segmentation penetration testing, fix gaps and retest.
9. Put reviews on a calendar. Six-monthly NSC reviews, annual scope confirmation and testing triggered by change.

Segmentation checklist:

• Account data flows documented and current
• CDE, connected-to and out-of-scope systems listed
• Network diagram covers every connection into and out of the CDE
• Inbound and outbound CDE traffic restricted to justified flows
• No peering, VPN or management path bypasses the boundary
• Identity permissions into the CDE limited to named roles
• NSC rule review completed in the last six months
• Segmentation test completed within the required interval and after the last change
• Findings remediated and retested, with evidence retained

How SecureSlate helps

SecureSlate helps you map PCI DSS requirements to the controls and evidence you already maintain. Cloud and identity integrations help you collect configuration and access evidence, and policy management keeps network security policies versioned and reviewed. Vendor risk management helps you track the payment providers and testers your segmentation strategy depends on. Because the control library is mapped across PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR and more, HealthTech teams can reuse much of the same work across frameworks.

Start your free SecureSlate trial

FAQ

Is network segmentation mandatory for PCI DSS?

No. PCI DSS does not require segmentation, but without it every system on the same network as your CDE is in scope. Most organizations use segmentation, tokenization or both to keep the assessment practical.

How often is segmentation testing required for PCI DSS?

Under Requirement 11.4.5, entities that use segmentation must test it at least once every 12 months and after any change to segmentation controls or methods. Service providers must also meet Requirement 11.4.6, which raises the frequency to at least once every six months.

Do security groups count as segmentation in the cloud?

They can. PCI DSS v4.0.1 treats cloud security groups and similar technologies as network security controls. What matters is that they effectively block access to the CDE, that their configuration is documented and reviewed, and that segmentation testing confirms the isolation.

Does tokenization remove the need for segmentation?

It can reduce or remove the need if your systems never store, process or transmit card data. Systems that still handle card data, or that deliver the payment form, may remain in scope. Confirm with your assessor or acquirer.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.