How to Define Your Cardholder Data Environment (CDE) Under PCI DSS

Before an organization can implement Payment Card Industry Data Security Standard (PCI DSS) controls, it must answer a foundational question: what is in scope? The answer lies in the definition of the Cardholder Data Environment (CDE). Get it wrong, and everything built on top of it is on shaky ground. Define it too broadly, and the compliance program becomes unnecessarily expensive and complex. Define it too narrowly, and critical systems go unprotected, assessors find gaps, and the organization faces findings that could have been avoided.

The CDE is not simply where payment card data lives. It encompasses the systems, people, and processes that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), as well as any systems that could impact the security of that environment. Understanding where the CDE begins and ends is the starting point for every meaningful PCI DSS compliance decision your organization will make.

This article breaks down how the CDE is defined under PCI DSS v4.0.1, what systems fall within scope, how network segmentation affects scope reduction, and where organizations most commonly make scoping errors. Whether you are preparing for your first PCI DSS assessment or revisiting an existing scope definition, getting the CDE right is the most consequential step in the process.

What the CDE Includes

Under PCI DSS v4.0.1, the Cardholder Data Environment is defined as the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, along with any systems connected to or that could impact the security of that environment.

This definition has three distinct components that organizations need to evaluate separately.

Systems That Store, Process, or Transmit CHD or SAD

The most obvious in-scope systems are those that directly handle payment card data. This includes point-of-sale terminals, payment applications, databases containing primary account numbers (PANs), servers that process authorization requests, and any system that receives, routes, or logs cardholder data as part of normal operations.

Sensitive authentication data includes full track data from card magnetic stripes or chips, card verification codes (CVV/CVC), and PIN data. Unlike CHD such as the PAN and cardholder name, SAD must never be stored after authorization, even if encrypted. Any system that touches SAD during the authorization process is in scope.

Systems Connected to the CDE

This is where many organizations underestimate their scope. Any system that has network connectivity to a CDE system is potentially in scope, even if it does not directly handle cardholder data. A jump server used to administer CDE systems, a logging server that receives logs from payment applications, a vulnerability scanner with access to the CDE network segment, or an authentication server that CDE systems rely on are all examples of systems that fall within scope due to connectivity alone.

PCI DSS v4.0.1 introduced the concept of connected-to or security-impacting systems to formalize this category. If a system can affect the confidentiality, integrity, or availability of the CDE, it is in scope regardless of whether it directly processes cardholder data.

People and Processes

The CDE is not just a technology boundary. Personnel who administer CDE systems, vendors with remote access to the cardholder environment, and processes that govern how cardholder data is handled, transmitted, or disposed of are all components of the CDE. This includes third-party service providers whose services touch the CDE, which must be addressed through PCI DSS Requirement 12.8 and the use of a Responsibility Matrix. Requirement 12.8 covers the management of third-party service providers, including maintaining a list of all TPSPs, establishing written agreements that include acknowledgment of their responsibility for cardholder data security, and monitoring their PCI DSS compliance status.

How Network Segmentation Affects CDE Scope

One of the most effective tools for managing CDE scope is network segmentation. When implemented correctly, segmentation isolates the CDE from other network environments, preventing systems outside the cardholder environment from having connectivity to systems inside it. Systems that cannot communicate with the CDE are generally out of scope.

PCI DSS does not require segmentation, but it is strongly recommended. Without segmentation, the entire network is effectively in scope, which significantly expands the number of systems, controls, and assessor testing activities required to demonstrate compliance.

Segmentation can be achieved through firewalls, network access controls, VLANs with properly enforced access policies, or a combination of these. However, the mere existence of a firewall or VLAN does not constitute effective segmentation. Assessors will test whether segmentation is enforced by attempting to reach CDE systems from out-of-scope networks. If connectivity exists, segmentation is not effective, and the connecting systems fall back into scope.

Organizations that rely on segmentation for scope reduction must document and validate their segmentation controls at the applicable required frequency: service providers must test segmentation controls every six months; merchants are required to test annually, and after any significant change to the network, as required under PCI DSS Requirement 11.4.5.

Common CDE Scoping Errors

Scoping errors are among the most frequent findings in PCI DSS readiness assessments. The following mistakes appear most consistently.

• Excluding connected systems. Organizations scope the CDE based on which systems directly process cardholder data and overlook servers, workstations, and network devices that connect to those systems.

• Assuming tokenization removes all scope. Tokenization replaces PANs with non-sensitive tokens and can significantly reduce scope, but the tokenization system itself and the systems that communicate with it remain in scope.

• Treating encryption as a scope elimination tool. Encrypting cardholder data at rest or in transit reduces risk, but it does not remove systems from scope. Encrypted data is still cardholder data.

• Overlooking shared services. DNS servers, NTP servers, Active Directory, and other shared infrastructure that CDE systems depend on may be in scope even if they serve out-of-scope systems as well.

• Ignoring third-party access paths. Vendors, managed service providers, and payment processors with remote access into the CDE environment can extend scope in ways that are not always visible from inside the organization.

• Not reassessing scope after environmental changes. Scope is not static. Adding a new payment channel, migrating to cloud infrastructure, or changing network architecture can all expand the CDE without a formal review triggering an update to the scope definition.

Scope Reduction Strategies

Reducing the size of the CDE is one of the highest-leverage activities an organization can undertake before a PCI DSS assessment. A smaller scope means fewer systems to harden, fewer controls to implement, and fewer testing activities for assessors to conduct.

Tokenization

Replacing PANs with tokens at the point of capture removes cardholder data from most downstream systems. If a system only ever sees a token and never the underlying PAN, it generally falls out of scope. Tokenization is most effective when implemented as early in the data flow as possible, ideally at the point-of-sale or payment gateway, before the PAN touches any internal system.

Point-to-Point Encryption (P2PE)

Validated P2PE solutions encrypt cardholder data from the point of interaction through to decryption in a secure environment outside the merchant's control. Merchants using a PCI SSC-validated P2PE solution can significantly reduce the scope of their assessment, in some cases reducing it to a simplified Self-Assessment Questionnaire (SAQ P2PE). Note: To claim scope reduction, the P2PE solution must be implemented strictly according to its PCI SSC-listed Implementation Guide. The key requirement is that the solution is listed on the PCI SSC validated solutions list and implemented according to its implementation guide.

Outsourcing Payment Processing

Organizations that redirect customers to a fully hosted payment page operated by a third-party payment processor, and that never receive or transmit cardholder data themselves, can significantly limit their CDE. In these architectures, the merchant's systems may qualify for a SAQ A assessment, which is the most limited PCI DSS assessment pathway. However, this only applies when the merchant has no access to the cardholder data environment of the payment processor and the third party is PCI DSS compliant. Merchants should request and obtain a current Attestation of Compliance (AOC) from their third-party payment processor as evidence of their PCI DSS compliance.

The CDE Under PCI DSS v4.0.1: What Changed

PCI DSS v4.0.1, which became the only active version of the standard in March 2024, introduced several clarifications and changes relevant to CDE scoping.

The definition of in-scope systems was clarified to explicitly include connected-to or security-impacting systems as a formal category, formalizing what many assessors had already been applying in practice. This change makes it harder for organizations to argue that support infrastructure falls outside scope on the basis that it does not directly process cardholder data.

PCI DSS v4.0.1 also introduced greater flexibility through customized approach, which allows organizations to meet the intent of a requirement through alternative controls rather than the defined approach. This is relevant to scoping because organizations with unique architectures now have a formal pathway to demonstrate compliance without forcing their environment into a standard control framework that does not fit.

Finally, v4.0 placed greater emphasis on the ongoing nature of compliance, including requirements for more frequent validation of segmentation controls and explicit requirements around targeted risk analysis for certain control frequencies. These changes reinforce that CDE scoping is not a one-time exercise but a continuous program management responsibility.

Documenting and Validating Your CDE

A well-defined CDE is not just a list of IP addresses. It is a documented, defensible description of the environment that an assessor can use as the foundation for their testing. At minimum, CDE documentation should include:

• A network diagram that clearly shows the CDE boundary, all in-scope systems, and all network connections into and out of the CDE.

• A data flow diagram that maps how cardholder data enters, moves through, and exits the environment.

• An inventory of all in-scope system components, including hardware, software, and network devices.

• Documentation of segmentation controls and evidence of periodic segmentation testing.

• A list of third-party service providers with access to the CDE and their applicable PCI DSS compliance status.

This documentation should be reviewed and updated at least annually and after any significant environmental change. Assessors will compare documentation against the actual environment during testing. Discrepancies between documented scope and actual network topology are a common source of findings.

How Compass Can Help

Compass IT Compliance has guided organizations through every stage of the PCI DSS compliance journey, from initial CDE scoping and gap assessments to remediation support and a full Report on Compliance (ROC) led by our Qualified Security Assessor (QSA) team. Our team understands how cardholder data flows through real-world environments, and we help organizations draw scope boundaries that are accurate, defensible, and built to withstand assessor scrutiny.

Contact us today to discuss your PCI DSS scoping questions and find out how we can help you build a compliance strategy that starts on solid ground.