How To Get a Jump-Start On PCI DSS 4.0 Regulations

Since 2004, the Payment Card Industry Data Security Standard (PCI DSS) has dictated how organizations that accept credit card payments must protect the data exchanged in those transactions. In 2022, PCI DSS released version 4.0 of its guidelines — the first full version update since 2013. As of today, the new standards are positioned as best practices, but merchants and service providers have until March 31, 2025, to implement necessary changes to comply with the new requirements. 

While there is a generous grace period, many organizations will need considerable time to implement the necessary safeguards to maintain PCI DSS compliance once enforcement begins. And when you consider non-compliance fines can range from $5,000 to $100,000 per month, it’s imperative to start taking the necessary steps as soon as possible.

To be clear, the new regulations have 12 requirements and more than 300 sub-requirements. However, a great deal of PCI DSS deals directly with protecting the card data environment (CDE). Let’s take a closer look at how the CDE is defined and the methods to protect it in a compliant fashion under version 4.0.
Understanding the Card Data Environment

One of the biggest changes in version 4.0 is that it acknowledges protection methods outside of routers and firewalls. The CDE was once a straightforward physical database where customer information was stored. Transparent data encryption (TDE) was commonly used to protect data written into a disc or in transit. This is an important update, as the CDE is now virtual and exists anywhere a credit card is being used — from a consumer making an online purchase to a point-of-sale exchange. PCI DSS defines the CDE in the following ways:

• System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data
• System components that may not store, process, or transmit cardholder data (CHD)/sensitive account data (SAD) but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD
• System components, people, and processes that could impact the security of the CDE

A merchant can avail themselves of responsibility as much as possible by outsourcing all access to the card data to third-party providers, but the last item of the CDE definition means that the merchant environment is still in-scope and must attest that they don’t have any access to the data and that the third-party providers are PCI compliant. This makes sense, as the merchant will suffer the consequences of customer and government angst in the case of a breach regardless of whether it is directly the merchant’s fault or not.  

Now, let’s move on to specific scenarios to protect data under PCI DSS 4.0.

Protecting Sensitive Account Data

In a typical card transaction, processed sensitive account data is generally in the clear only for a few seconds, but the prevalence of illegal point-of-sale card readers has made it easy for criminals to steal that information. Additionally, some merchants — often e-commerce sites — would store customer information in memory and delete it in batches daily, leaving swaths of data in the clear for extended periods. This practice is prohibited by PCI DSS. 

Satisfying PCI DSS: Merchants must encrypt data immediately while waiting for payment. Depending on the situation, data can be encrypted in a number of ways. First, secure sockets layer/transport layer security (SSL/TLS) protocols create secure communication between the point of sale and the processor/payment gateway. Point-to-point encryption (P2PE) and end-to-end encryption (E2EE) are slightly different methods that encrypt data throughout the payment process, starting at the point-of-sale terminal. Finally, tokenization, which replaces real data values with tokens, is used when data must be stored and used for future transactions.

Protecting Encryption Keys

Encryption’s effectiveness as a best-in-class protection method comes from the keys. Data can’t be accessed without the keys, but organizations didn’t own them for many years. It doesn’t do any good to encrypt your data if the keys are easy to access. Under PCI DSS 4.0, organizations will be non-compliant if the keys are outside their control.

Satisfying PCI DSS: In recent years, we’ve seen more cloud providers offer bring your own key (BYOK) technology to users, giving them complete control over encryption keys. With BYOK, there is a two-tier method where organizations own customer-managed keys (CMK), which never leave their respective system. The CMK is used to encrypt the data encryption key (DEK), which is then used to encrypt the data. The encrypted DEKs are stored in a database of the user’s choosing. And should the company decide to end a relationship with its cloud service provider, the keys are destroyed.  

Protecting Pre-Production Environments

Pre-production environments, also called “lower environments,” refer to any test, development, or DevOps environment where the production environment may be simulated. Traditionally, vast amounts of unprotected data were copied and shared with many people working in pre-production environments — which, under the new PCI DSS mandate, is a compliance issue.

Satisfying PCI DSS: Traditional encryption is an option, but format-preserving encryption (FPE) is preferred since the data type and length are preserved. The duplicated data is simply double-encrypted, but the keys for both layers of encryption are within the common data environment, ensuring that the original data is not available in the pre-production environment.

Protecting credit card data is undoubtedly a challenge as compliance regulations become more stringent. However, PCI DSS has given organizations a lengthy on-ramp to implement best-in-class protection methods to keep customer information safe and avoid non-compliance. The time to start working toward this new reality is now. 

— Billy VanCannon, Director of Product Management, Baffle