PCI-DSS Network Segmentation and CDE Scope Reduction

How PCI-DSS Defines Scope: The CDE and Connected Systems

PCI-DSS compliance scope is defined by the cardholder data environment. The CDE consists of all system components that store, process, or transmit cardholder data — specifically the primary account number (PAN) and associated sensitive authentication data — plus all systems that can communicate with any CDE component. That last clause is where flat networks create explosive scope.
On a network without segmentation, every system that can communicate with a POS terminal, payment server, or cardholder data store is in scope for PCI-DSS, regardless of whether it ever touches cardholder data itself. The corporate laptop used for email and the HR system used for payroll are both in scope if they sit on the same network segment as the payment processing system and have no technical barrier preventing them from reaching it. A flat-network mid-market environment with a few hundred endpoints can easily result in hundreds of in-scope system components, all of which must satisfy the applicable PCI-DSS requirements.

What Effective Network Segmentation Requires

The PCI-DSS standard does not specify a particular technology for segmentation. Acceptable approaches include physical network separation, firewalls with documented restrictive rulesets, VLANs with access control lists enforced at the network layer, and software-defined perimeters with micro-segmentation. The critical test is whether the segmentation control technically prevents unauthorized communication between in-scope and out-of-scope systems — not merely whether it is documented as doing so.

Architecture Requirements for Valid Segmentation

For segmentation to reduce PCI-DSS scope, the boundary between the CDE and the rest of the network must meet specific architectural criteria. The CDE must be isolated using controls that actively restrict all communication between in-scope and out-of-scope systems to only what is explicitly authorized and documented. Any path that allows an out-of-scope system to initiate a connection to a CDE system — even for management, backup, or monitoring purposes — brings that out-of-scope system into scope unless the connection is explicitly defined, authorized, and enforced.
Common segmentation failures that expand scope rather than reduce it include:
Management interfaces that allow administrators to reach CDE systems from the general corporate network without passing through an approved access control boundary. Backup systems located outside the CDE that pull data directly from CDE systems, creating a data flow that traverses the segmentation boundary. Monitoring and log collection agents that report from CDE systems to a SIEM located outside the CDE via a path that lacks access controls equivalent to the CDE boundary itself. Wi-Fi networks that bridge across VLAN boundaries due to misconfigured access point configuration or SSID bridging.
Each of these patterns expands CDE scope to include the management systems, backup infrastructure, monitoring platforms, or wireless access points involved, because those systems have access paths into the cardholder data environment.

Segmentation Validation: The Annual Penetration Test Requirement

Under PCI-DSS 4.0, organizations using network segmentation to reduce CDE scope must validate that segmentation is effective at least once per year and after any significant change to the CDE or network infrastructure. The validation must be performed through penetration testing — not simply a firewall rule review or network diagram review. A penetration test focused on segmentation attempts to traverse the boundary from out-of-scope systems and confirms that the controls actively prevent access, not merely that firewall rules document the intent to prevent it.
Penetration tests validating segmentation must be conducted by a qualified tester who is organizationally independent from the team responsible for managing the segmentation controls. The results, including any findings and remediation performed, must be documented and retained as compliance evidence. For organizations subject to a QSA on-site assessment, the QSA will review penetration test reports and may conduct independent validation of segmentation effectiveness during the assessment. See PCI-DSS merchant levels for the assessment requirements applicable to your transaction volume.

Scope Reduction Approaches Beyond Network Segmentation

Tokenization

Tokenization replaces primary account numbers with non-sensitive surrogate values (tokens) at the point of capture. When implemented at or before the point of entry into a merchant’s environment, tokenization eliminates the PAN from all systems downstream of the tokenization service. Systems that store, process, or transmit only tokens — not PANs — are not in scope for PCI-DSS. Tokenization does not reduce scope in the environment where cardholder data initially enters; it eliminates scope in every downstream system that would otherwise need to handle the PAN.

Point-to-Point Encryption (P2PE)

P2PE solutions encrypt cardholder data at the point of interaction — typically the payment terminal hardware — before it enters any merchant-controlled system. When a PCI SSC-validated P2PE solution is implemented according to the solution provider’s instructions, the encrypted data that traverses the merchant’s network cannot be decrypted within the merchant’s environment, which substantially reduces the scope of systems the merchant must control. Merchants using validated P2PE solutions may qualify for SAQ P2PE, a significantly reduced assessment questionnaire. See PCI-DSS SAQ types for P2PE eligibility criteria.

Outsourcing Cardholder Data Functions

Merchants that outsource all cardholder data storage, processing, and transmission to PCI-DSS-validated third parties — and whose systems and networks have no access to cardholder data and do not affect the security of the payment transaction — can achieve minimal PCI-DSS scope. SAQ A, the shortest self-assessment questionnaire, is designed for this scenario. However, the eligibility criteria are strict: any system component the merchant controls that affects the security of the payment flow brings the merchant back into a broader scope.

Armorstack’s Role in CDE Scoping and Segmentation

Armorstack approaches network segmentation as both a compliance control and a security architecture objective. A well-segmented cardholder data environment limits breach impact even in the event of a compromise in other network zones — the CDE becomes a hardened compartment rather than part of a flat attack surface.
VERITY advisory conducts the CDE scoping analysis: documenting all system components that store, process, or transmit cardholder data, mapping all communication paths into and out of the proposed CDE boundary, and identifying systems that would be brought into scope by access paths not blocked by the segmentation controls. The scoping analysis produces a network architecture recommendation and segmentation design that reduces in-scope system count to the minimum technically achievable for the organization’s payment acceptance model.
CORE managed IT services implements the network segmentation architecture — VLAN configuration, firewall ruleset development, access control list management, and documentation of all authorized communication paths across the CDE boundary. CORE also manages ongoing configuration discipline: firewall rule reviews, change management documentation, and drift detection that identifies unauthorized changes to segmentation controls before they create audit findings.
SENTRY managed detection and response monitors network traffic across the CDE boundary continuously, alerting on unauthorized communication attempts that indicate segmentation failure or potential breach. This monitoring serves dual purposes: it satisfies Requirement 10’s continuous monitoring obligations and provides real-time detection of segmentation control failures that would otherwise go unnoticed until the next annual validation. For information on the specific PCI-DSS 4.0 requirements that segmentation testing must satisfy, see PCI-DSS 4.0 changes. For a view of the full PCI-DSS compliance program, see PCI-DSS compliance. To discuss your network architecture and CDE scoping, talk to an Armorstack compliance expert or start the 90-Day Proof.