Storing Cardholder Data Outside the PCI DSS Scope

The Payment Card Industry’s Data Security Standard (PCI DSS) states that entities should refrain from storing cardholder data unless there is a legitimate reason to do so. However, with the technological solutions that are currently available, it turns out that the merchants and PSPs hardly ever have an indisputable reason to keep such sensitive details.

While the PCI DSS guidelines provide a certain degree of protection against fraud and data theft, they also impose challenges to achieving the one-click payments that the majority of customers these days want. Keep reading to find out whether there are ways of overcoming this obstacle while remaining PCI-compliant.

Can Entities Store Cardholder Data Without the PCI Scope?

Here’s a spoiler: storing cardholder data without the PCI DSS scope is not possible, but there’s a way to store a reference to it.

According to the PCI DSS requirements, entities can store the following data, if absolutely necessary:

• Primary Account Number (PAN)
• Cardholder name
• Service code
• Expiration date

However, the Sensitive Authentication Data listed below must never be kept:

• Full magnetic stripe data
• CAV2, CVC2, CVV2, or CID
• PIN or PIN Block

Ways of Storing PAN Data Securely According to PCI DSS

The PCI DSS requirements contain several options for making the PAN data unreadable, namely:

• Tokenization holding a replacement or proxy for the PAN
• Strong cryptography involved in core security procedures
• Truncation that stores a PAN section (not exceeding the first six and last four characters)
• Cryptography-based one-way hashes with all digits replaced

While all these methods are acceptable, which one should you choose?

The Most Optimal Method of PAN Data Storage

While the cryptographic process is a PCI DSS-compliant and reliable way of storing cardholder details, it is rather complex and is best suited for the transmission of sensitive information rather than its storage and utilization.

Tokenization, on the other hand, is often considered to be a better alternative since tokens can be stored in the same 16-digit form and be only partially masked. In other words, it’s possible to create a secure token that keeps a part of the PAN unchanged.

It’s an important factor for card processing entities, as maintaining the first 6 digits representing the BIN unaltered can improve routing and reporting. However, many merchants decide to keep the last 4 digits unchanged, which is useful for verification and customer service purposes. Thus, leaving a part of the token without changes makes it not only secure but also useful.

Which Type of Tokenization Serves the Purpose Best?

There are both non-reversible and reversible tokenizations. However, for the sake of storing cardholder data, the latter type fits best since the tokens can be brought back to their initial PAN form via de-tokenization by a data look-up in a secure card data vault (CDV).

Thus, the original PAN will be accessible after the de-tokenization request is submitted by an authorized user. The most efficient way of facilitating it is via a third-party entity - a payment processor, an acquiring bank, or a payment gateway like the one offered by Payneteasy. Learn more about tokenization and the services we offer in our guide “Advanced Data Security: Tokenization Explained”.