Cardholder Data Environment (CDE)

The cardholder data environment (CDE) is the part of an organisation that stores, processes or transmits cardholder data or sensitive authentication data: the people, processes and technology involved, including servers, applications, networks, payment terminals and databases. Under the Payment Card Industry Data Security Standard, the CDE and the systems connected to it or able to affect its security are "in scope", meaning they must meet the standard's requirements.

The concept matters because the size of the CDE largely determines the cost and difficulty of PCI DSS compliance. An organisation that lets card data flow freely across its network may find almost every system in scope; one that confines card data to a small, well-protected area, or never touches it at all, has far less to secure. The standard is maintained by the PCI Security Standards Council, founded by the major card networks, and the current version is 4.0.1, published in 2024.

Imagine a jewellery shop. The valuable stones are kept in one locked room with cameras, alarms and a strict list of who may enter. The rest of the shop, the café corner and the staff kitchen, does not need the same security, as long as there is a solid door between them and the vault.

The cardholder data environment is that locked room. It is where card numbers live or pass through. The smaller and better sealed it is, the less of the business has to meet the toughest security rules.

• Systems handling card data. Any component that stores, processes or transmits the primary account number or sensitive authentication data, such as card security codes or chip data.
• Connected systems. Components on the same network segment or with access to the CDE, such as administrator workstations and directory servers.
• Security-impacting systems. Systems that could affect the CDE's security, such as authentication, logging and patch management servers.
• People and processes. Staff with access to card data and the procedures they follow, including third parties such as hosting and support providers.

PCI DSS version 4.0 requires organisations to confirm their scope at least once a year and after significant changes, documenting all locations and flows of card data.

Network segmentation, which isolates the CDE from the rest of the network with firewalls and access controls, is the main way to keep scope manageable. It is not mandatory, but without it the whole network may be in scope. Organisations also shrink the CDE by not handling card data at all:

• Tokenisation. Replacing stored card numbers with tokens, such as network tokens or gateway tokens, so that systems hold no usable card data.
• Point-to-point encryption. Encrypting card data in the terminal so that it can only be decrypted by the processor, typically inside hardware security modules; validated solutions under the PCI P2PE standard can sharply reduce in-store scope.
• Hosted payment pages. Redirecting customers to a payment gateway's page or embedding its secure fields, so card data never touches the merchant's servers.
• Data minimisation. Deleting card data that is no longer needed, in line with rules on cardholder data storage.

How compliance is validated depends on transaction volume and network rules. Large merchants and service providers typically undergo an annual on-site assessment by a qualified security assessor, documented in a report on compliance, while smaller merchants complete a self-assessment questionnaire whose type reflects how they accept cards. Merchants that fully outsource card handling to a compliant provider may use the shortest questionnaire, though they remain responsible for the security of their payment pages and contracts. Acquirers collect evidence of compliance from their merchants and report to the networks.

Version 4.0, published in March 2022, replaced version 3.2.1, which was retired in March 2024. Many new requirements became mandatory in March 2025. They include broader use of multi-factor authentication for access to the CDE, stronger password rules, targeted risk analyses that let organisations set some control frequencies, and new controls on scripts running on e-commerce payment pages, aimed at attacks that inject malicious code to steal card data as customers type it. The standard also introduced a customised approach, letting organisations meet a requirement's objective with alternative controls if they can show equivalent security.

A narrowly drawn CDE is only safe if the boundaries hold. Breaches often begin outside the CDE, for example through phishing of staff or compromised suppliers, and then move into it through unexpected connections. Compliance at the time of assessment does not guarantee security all year, and several large data breaches have occurred at organisations that had recently been validated. Security teams therefore treat PCI DSS as a minimum and combine it with continuous monitoring, encryption and wider data security programmes.

• PCI Security Standards Council