Having a PCI Compliant Cardholder Data Environment (CDE)

New and emerging business models, requirements, and workflows are forcing companies to seek new ways to use sensitive payment data more effectively.

• “How can I safely send or receive plaintext cardholder data with a partner?”
• “How can I add a new processor to reduce transaction costs?”
• “How can I run my machine learning algorithms?”
• “How might I avoid living with the wrong vendor or implementation path?”

Answers to these questions inevitably come back to having a cardholder data environment (CDE) that is flexible enough to provide access to cardholder data, and the existing gaps in some of today’s dominant implementation strategies.

From banks to customers, misuse of cardholder data leaves everyone vulnerable to significant reputational and financial harm. As such, PCI DSS mandates that the systems used to transmit and store credit card details—collectively known as your PCI CDE—meet the 12 requirements and their over 300 sub-requirements, including a specialized cardholder data environment (CDE). 

Failure to properly store data can be expensive, costing businesses up to $100,000 each month for non-compliance. Aside from the fines, reputation loss, higher insurance costs, and even customer lawsuits typically follow suit.

What is a Cardholder Data Environment? 

The Payment Card Industry Data Security Standard (PCI DSS, or PCI) uses the term Cardholder Data Environment (CDE) to refer to the collective network of servers, systems, people, and processes exposed to raw cardholder data or the data used to authenticate transactions, like PIN, CVV, and CVC. The depth and breadth of your cardholder environment are often referred to as, “scope.”  

Each item “in scope” must comply with every PCI requirement and be assessed annually, no matter how big or small the exposure. The more systems in scope, the bigger and costlier the effort to secure, monitor, and maintain its compliance. Conversely, the smaller the footprint, the simpler it is to attest compliance. 

A CDE consists of every system with access to cardholder data within an organization’s IT environment, including those that manage authentication data for that environment. When developing a PCI DSS compliance strategy, one of the first and most important steps is identifying which systems make up the CDE. 

 Examples of systems commonly found within a CDE include the following:

• Servers: Companies commonly collect cardholder data via web-servers and store it in database servers.  Other servers may manage the authentication data used to grant or deny access to the CDE.  Both physical and virtualized servers are part of the CDE and within the scope of a compliance audit.
• Point of Sale (POS) Systems: POS systems are designed to read cardholder data from a payment card to process a transaction.  Payment terminals, cash registers, and similar systems are part of the CDE.
• Network Infrastructure: Cardholder data commonly travels over the network and may be inspected by various network and security solutions en route.  Firewalls, routers, wireless access points, and other network infrastructure may be considered part of the CDE.
• Applications: Servers host a variety of applications that perform the collection and processing of payment card data.  Applications are part of the CDE as well.
• Third-Party PCI Service Providers: To significantly reduce the burden of PCI, an organization may rely upon a third party’s CDE to collect, store, or process cardholder data through a process called tokenization. Their CDE becomes your CDE. 

Maintaining scope can be easy at first, but over time CDEs can grow significantly as new needs arise. A centralized infrastructure and tokenization platform with supporting docs, preconfigured SDKs, and access controls can help enforce compliant developer patterns, products, and services, as well as aid in evidence gathering for annual assessments. Invest in these tools to keep a small compliance footprint, reduce the costs of annual assessments, and streamline compliance approvals.

Return to Top

What can and cannot be stored in a CDE? 

PCI DSS breaks cardholder data into a couple of different categories, and some data can and cannot be stored within a CDE’s database.  

Companies are allowed to store the following types of cardholder data in a CDE:

• Primary Account Number (PAN)
• Expiration Date
• Cardholder Name
• Service Code

While this information is useful for tracking accounts, it is not enough to perform payments unilaterally.  To do so, an organization may also need sensitive authentication data (SAD), which includes the following:

• Full data stored on the card’s magnetic strip.
• CAV2/CVV2/CID
• PIN

SAD is collected from a cardholder during payment and forwarded to the processor, but companies are prohibited from storing it, unlike cardholder data. This helps limit the risk of fraud since an attacker or malicious user lacks the information necessary to perform unauthorized transactions.

Return to Top

What does it take for a CDE to be PCI compliant? 

Break the effort down into three high-level buckets.

1. The implementation of a secure cardholder environment and programs (e.g., Setup and configuration of data protection controls.)
2. Maintaining your PCI environment and programs includes activities related to administering and enforcing the policies, controls, and required processes. 
3. The assessment required to validate or attest your compliance. These quarterly and annual exercises validate that the controls are in place for each item considered to be in PCI DSS compliance scope.

Some solutions allow organizations to leverage existing third-party service providers to provide up to 93% of the requirements and reduce the effort to do so by 99%. 

Return to Top

Should I build or buy a cardholder data environment? 

When it comes to setting up a CDE, you have two options: build or buy. Take a look at the next two blogs in the series to learn about each, their pros and cons, and helpful questions to ask as you evaluate your journey to PCI Compliance: 

1. Buy vs. Build: Service Provider CDE
2. Buy vs. Build: In-house CDE

By offloading your CDE to service providers, like Basis Theory, you can reduce your compliance effort by 99% and ensure continuous compliance with new PCI standards while retaining the same level of control needed to do things, like multi-party processing and split payments. 

Stand up a secure, fully compliant cardholder data environment with Basis Theory. Get started with our documentation. 

Return to Top