PCI DSS network segmentation: myths and facts

Network segmentation can reduce the number of systems in PCI DSS scope, but it is not a requirement, a firewall in the path does not automatically take a system out of scope, and it has to be tested. Here are common myths checked against the Council's scoping and segmentation guidance.

Myth 1: PCI DSS requires segmentation

Fact: no. The Council's guidance says segmentation is used to keep in-scope systems separated from out-of-scope ones to reduce scope. Without it, the whole network is in scope. Segmentation is a design choice that can lower cost.

Myth 2: Any firewall between two networks counts as segmentation

Fact: the guidance separates two uses of the same technology. When technologies manage access between systems to meet PCI DSS requirements, that is not segmentation that reduces scope. The communicating systems stay in scope. For segmentation to reduce scope, the controls must keep out-of-scope systems from being able to communicate with the CDE.

Myth 3: Out-of-scope means untouched

Fact: out-of-scope systems are described as untrusted. The guidance notes that attackers target systems deemed out of scope, then pivot. It says that while PCI DSS controls are not required on out-of-scope systems, securing them helps prevent them being used to attack in-scope ones.

Myth 4: Same VLAN is fine if the card data is encrypted

Fact: in the guidance's example categories, an out-of-scope system must not be on the same network segment, subnet or VLAN as systems that store, process or transmit CHD, and must not be able to connect to or access any CDE system. Sharing a segment is a reason for a system to fall into a higher category.

Myth 5: Set it once and forget it

Fact: the assessor must verify segmentation is adequate when it is used to reduce scope. The guidance says segmentation controls must also be penetration tested at least annually, per the v3.2 requirement it cites, to confirm they continue to work. Requirement numbering changed in v4.x, so check the current number in the standard.

Myth 6: Admin accounts do not matter for segmentation

Fact: the guidance warns about compromising an administrator account in an out-of-scope network and using it to reach the CDE. It suggests separating administrative roles so that an account compromised outside cannot be used inside, and monitoring for changes to segmentation controls.

Myth 7: Shared services are out of scope because they are corporate

Fact: shared services that connect to the CDE are described in the guidance as an issue, since they connect to in-scope components. DNS, directory, patching and monitoring services often need to be treated as connected-to or security-impacting. See scope categories.

A practical segmentation checklist

1. Draw the data flows and mark where cardholder data lives.
2. Write the deny by default rules between the CDE and everything else, and keep the rule set short enough to review.
3. Test from the out-of-scope side that connections to the CDE fail.
4. Separate admin identities and credentials per zone.
5. Monitor for changes to segmentation controls and alert on them.
6. Retest after network changes, and on a fixed schedule.
7. Document the justification for each out-of-scope environment, as Requirement 12.5.2 expects.

Quick check

Sources

• PCI SSC Guidance for PCI DSS Scoping and Network Segmentation
• PCI DSS v4.0 SAQ D for Merchants, requirement 12.5.2

Last reviewed: 19 October 2026.