A helpful guide on Cardholder Data Environments (CDEs)

In the last couple of years, new and emerging business models, requirements, and workflows have forced companies to seek new ways to leverage this sensitive 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?”

The trend highlights the flexibility that access to cardholder data provides and the existing gaps in some of today’s dominant implementation strategies. Understand the basics of a cardholder data environment and make better decisions with this blog.

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”. 

Why can’t I store and share card data like plaintext?

From banks to customers, misuse of cardholder data leaves everyone vulnerable to significant reputational and financial harm. As such, the PCI DSS mandates that the systems used to transmit and store credit card details 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 considered a CDE?

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. 

TIP: 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.

Why does PCI Scope matter?

What’s in this scope has big implications for your organization. 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 PCI scope, the bigger and costlier the effort to secure, monitor, and maintain its compliance. Conversely, the smaller footprint, the simpler it is to attest compliance. 

Let’s see how this example might play out in the real world. Suppose you’ve built the necessary controls to collect and store cardholder data yourself. In that case, you’ll demonstrate compliance by filling out a SAQ-D (329 questions) each year and showing the results of your quarterly network scans and penetration tests. On the flip side, if you are a merchant using a third-party service provider to collect and store your cardholder data in their environment (as well as perform the scans, tests, etc.), you need only fill out an SAQ-A (22 questions). 

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.

What are the efforts to become and stay PCI DSS compliant?

That’s not super useful, so let’s try to break these efforts down into three high-level buckets.

• The implementation of a secure cardholder environment and programs (e.g., Set up and configuration of data protection controls)
• The maintenance of your PCI environment and programs. These include activities related to the administration and enforcement of the policies, controls, and required processes. 
• 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.

As we’ll discuss later in this series, there are solutions that allow organizations to leverage the existing compliance posture service providers to provide up to 93% of the requirements and reduce the effort to do so by 99%. 

Should I build or buy a cardholder data environment?

When it comes to setting up a CDE, you have two options: build in-house 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

Need a PCI-compliant CDE fast? 

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

Check out our PCI Blueprint to learn how to stand up your own CDE in less than 5 minutes!