Category: Cardholder Data

Cardholder Data Environment

Also known as: CDE, Cardholder Data Environment (CDE)

Simply put

The Cardholder Data Environment (CDE) is the part of a business that handles payment card information, including the systems, people, and processes that store, process, or transmit that data. It also covers connected components that could affect the security of that data. Defining the CDE helps an organization know which areas fall under PCI DSS requirements.

Formal definition

The CDE comprises the system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data, along with connected or supporting system components. Cardholder data (such as PAN, cardholder name, expiration date, and service code) and sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) are the data elements whose handling brings systems into the CDE; note that sensitive authentication data must not be stored after authorization, even when encrypted, whereas certain cardholder data may be stored under defined controls. The boundary of the CDE determines PCI DSS applicability and scope, and practitioners should confirm scoping and control requirements against the current published PCI DSS, as requirement numbering and wording differ between versions.

Why it matters

The Cardholder Data Environment defines the boundary of PCI DSS applicability. Because PCI DSS requirements apply to the system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data — as well as connected or supporting components — an inaccurate or overly narrow CDE definition can leave in-scope systems unassessed and unprotected. Conversely, an unnecessarily broad CDE increases the assessment burden and the number of systems subject to controls. Getting the scope right is therefore foundational to a defensible compliance posture.

The composition of the CDE is driven by the data elements it handles. Cardholder data such as PAN, cardholder name, expiration date, and service code brings systems into scope, and certain cardholder data may be stored under defined controls. Sensitive authentication data — including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks — must not be stored after authorization, even when encrypted. Systems that retain such data in violation of this principle expand risk and can indicate scoping or control failures that would surface during an assessment or, in the worst case, a breach.

Because connected or supporting system components fall within the CDE, organizations should account for how network segmentation, shared services, and administrative access paths affect the boundary. Practitioners should confirm scoping and applicable control requirements against the current published PCI DSS, since requirement numbering and wording differ between versions and should not be assumed from memory.

Who it's relevant to

Compliance officers and QSAs

Those responsible for PCI DSS assessments rely on an accurate CDE definition to determine which systems, people, and processes are in scope. Under- or over-scoping the CDE directly affects the validity of an assessment, so they trace data flows and confirm applicable requirements against the current published standard rather than assuming fixed requirement numbers.

Security engineers and network architects

Engineers design and maintain the boundary of the CDE, including how connected or supporting components are separated from systems that handle cardholder data. Their segmentation and access-control decisions influence which components fall inside the environment, though the scope-reducing effect of any control depends on how it is implemented and validated.

Merchants and payment processors

Organizations that store, process, or transmit cardholder data must understand where their CDE begins and ends to apply the correct controls and to avoid retaining sensitive authentication data after authorization. A clear CDE definition helps them focus protection and reduce unnecessary handling of card data.

Fraud and risk teams

Teams managing account and transaction risk benefit from understanding the CDE because it identifies where card data is concentrated and where controls apply. This informs how they reason about exposure, though the CDE governs data-handling scope and is distinct from the detection controls used to identify fraud.

Inside CDE

System components that store, process, or transmit cardholder data

Any system that handles cardholder data such as the primary account number (PAN), cardholder name, expiration date, or service code falls within the CDE. Systems handling sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) during authorization are also in scope, though such data must not be retained after authorization even when encrypted.

System components that store, process, or transmit sensitive authentication data

Components involved in authorization may transmit or process sensitive authentication data. Because this data must not be stored after authorization, the CDE controls apply to its handling during the authorization window rather than to persistent storage.

Connected-to and security-impacting systems

Systems that connect to the CDE or that could affect the security of cardholder data (for example, administrative jump hosts, authentication servers, or logging and monitoring infrastructure) can be brought into scope even if they do not themselves handle cardholder data. Readers should confirm the exact scoping treatment against the current published PCI DSS standard.

People and processes

The CDE is not limited to technology. Personnel with access to cardholder data and the business processes that handle it are part of the environment that PCI DSS controls are intended to protect.

Network segmentation boundary

Segmentation is used to isolate the CDE from the rest of the network to reduce scope. Segmentation is not a PCI DSS requirement in itself, but where used it must be validated so that out-of-scope systems genuinely cannot affect the security of the CDE. Its effectiveness depends on implementation, not on the label alone.

Common questions

Answers to the questions practitioners most commonly ask about CDE.

Does encrypting cardholder data automatically remove a system from the CDE?

Not by itself. Encryption transforms data but does not inherently take a system out of scope. Systems that store, process, or transmit cardholder data or sensitive authentication data are part of the CDE, and so are systems that can affect the security of those systems, such as those providing security services or connected to the CDE. Whether encryption reduces scope depends on the implementation and how key management is handled. If a system can decrypt the data or holds decryption keys, it typically remains in scope. Scope reduction claims should be validated against the current PCI DSS standard and, where relevant, the applicable P2PE requirements, rather than assumed from the presence of encryption alone.

Is the CDE just the servers where the PAN is stored?

No. The CDE is broader than storage systems. It includes people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. It also extends to system components connected to or that could impact the security of those systems, which may include network devices, servers, applications, and virtualization or cloud components. Limiting the CDE conception to storage overlooks transmission paths, processing points, and connected or security-affecting systems that fall within scope under the current PCI DSS standard.

How can we reduce the size of our CDE?

Common approaches include network segmentation to isolate the CDE from out-of-scope systems, minimizing where cardholder data is stored, processed, or transmitted, and using methods such as tokenization or validated point-to-point encryption where appropriate. The effect of these techniques on scope depends on how they are implemented and validated, not on the label alone. Segmentation is not a PCI DSS requirement in itself, but when used it should be verified to confirm it effectively isolates in-scope systems. Confirm scope-reduction expectations against the current published PCI DSS standard and applicable card brand or acquirer guidance.

How do we determine what belongs inside the CDE?

Start by identifying all locations where cardholder data and sensitive authentication data are stored, processed, or transmitted, including a documented data flow across systems, networks, and third parties. Then identify system components connected to or that could affect the security of those environments. This exercise is typically supported by up-to-date data-flow and network diagrams. Because scope definitions and wording can differ between versions of the standard, confirm the specific scoping criteria against the current published PCI DSS standard rather than relying on prior assumptions.

If we use segmentation, how do we confirm out-of-scope systems are truly isolated?

Segmentation effectiveness is generally confirmed through testing that verifies out-of-scope systems cannot access the CDE, commonly including penetration testing focused on segmentation controls. The testing should reflect the actual configuration of firewalls, access controls, and network paths. If segmentation is later found to be ineffective, the previously out-of-scope systems may fall within the CDE. Refer to the current PCI DSS standard for the applicable testing expectations and frequency rather than assuming a fixed interval.

How does the CDE relate to sensitive authentication data during and after authorization?

Systems that handle sensitive authentication data, such as full track data, card verification values, or PIN blocks, are part of the CDE while that data is being processed or transmitted for authorization. A key distinction is that sensitive authentication data must not be retained after authorization, even if encrypted, whereas certain cardholder data may be stored under defined controls. This means CDE controls must address both the systems that touch sensitive authentication data in flight and the storage practices that ensure it is not retained afterward. Validate specific storage prohibitions and permitted data elements against the current PCI DSS standard.

Common misconceptions

Encrypting stored cardholder data automatically removes a system from the CDE.

Encryption transforms data but does not by itself remove a system from scope. Scope reduction depends on the specific implementation and validation, and on whether keys and the encrypted data are managed separately. Additionally, sensitive authentication data must not be stored after authorization even when encrypted. Tokenization, truncation, masking, and hashing affect scope differently and none guarantee removal from scope based on the label used.

The CDE only includes systems that store cardholder data in a database.

The CDE includes any system that stores, processes, or transmits cardholder data, as well as connected-to and security-impacting systems, plus relevant people and processes. Transmission and processing paths, not just persistent storage, bring components into scope.

Applying network segmentation guarantees the rest of the network is out of scope.

Segmentation may reduce scope but only when it is correctly implemented and validated to confirm isolation. Improperly configured segmentation can leave systems in scope despite being intended as out-of-scope. Segmentation helps reduce scope rather than guaranteeing it.

Best practices

Maintain an accurate, current inventory of all system components, people, and processes that store, process, or transmit cardholder data, and review it whenever the environment changes.

Identify and document connected-to and security-impacting systems in addition to those that directly handle cardholder data, and confirm their scoping treatment against the current published PCI DSS standard.

Where segmentation is used to reduce scope, validate its effectiveness through testing to confirm that out-of-scope systems cannot affect the security of the CDE.

Confirm that sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) is not retained after authorization, regardless of encryption.

Evaluate tokenization, truncation, masking, or hashing for data-minimization based on how each is implemented and validated, rather than assuming any label reduces scope on its own.

Re-scope and reassess the CDE regularly and after significant changes, verifying requirement wording and numbering against the current version of the standard rather than relying on fixed references.