Is it possible to store cardholder data without PCI scope? The short answer is no, but that doesn’t mean you cannot store a reference to it. Let me explain.
The Payment Card Industry’s Data Security Standard (PCI DSS) suggests that anyone handling sensitive cardholder data not store it in the clear unless it is absolutely necessary. With current technologies and processes available, it is never “absolutely necessary,” so merchants (or PSPs) should never have cardholder data in the clear – not during transmission and never stored anywhere hackers could gain access.
The issue is that today’s consumers want one-click or invisible payments. So, how can merchants securely facilitate these transactions without storing cardholder data?
PCI DSS is defined by 12 requirements, further divided into 220 sub-requirements. For the purposes of this discussion, we will focus on requirement 3. Requirement 3 of PCI DSS is to “protect stored cardholder data.” If cardholder data is to be retained, PCI compliance requirements dictate that cardholder data must be rendered unreadable using industry-standard techniques.
PCI is assuming there is a need to store cardholder data to authorize additional transactions with customers; you can learn more about what can be stored and what should never be stored in the table below:
Table 1: PCI Security Standards Council: PCI Data Storage Do’s and Don’ts
Ultimately, the primary account number (PAN) must always be protected and masked when shown. Making PAN data unreadable means that the data becomes virtually useless to fraudsters. Additional cardholder data including cardholder name, service code and expiration date must be protected if stored with the PAN. All sensitive authentication data (CVV, PIN and everything on the MAG stripe) must never be stored.
PCI DSS requirement 3.4 provides several options for making the PAN data unreadable, including:
- Strong cryptography-based one-way hashes where all PAN must be hashed
- Truncation that stores a PAN section (must not exceed the first six and last four digits)
- Tokenization, which holds a replacement or proxy for the PAN
- Strong cryptography focusing on key management processes and security procedures
Merchants who plan to use stored PANs should make the data unreadable using encryption or tokenization. PCI DSS requires the use of keys and tokens, such as a cryptographic token, which replaces a PAN for an unknown value based on a specific directory.
Many of the other sections of PCI DSS Requirement 3 involve the cryptographic process, which includes generating, documenting and managing of cryptographic keys. While encryption is an excellent securing method, it is cumbersome to say the least, and best used for transmitting sensitive information rather than storing and utilizing stored cardholder data. Tokens are a better choice, as they can be stored in the same form (16-digits) and can be partially masked. This means you can create a secure token that leaves the part of the PAN unchanged. If the first 6 digits that represent the BIN (bank identification number) is unchanged, routing and reporting can be improved. Many merchants choose not to change the last 4 digits of the card number as well. This is useful for verification and customer service. Leaving part of a token unchanged makes the tokens both secure and useful.
In reference to tokens, there are both reversible and non-reversible variations. Because there is no good reason to store a token that is not reversable, we will concentrate on reversible tokens.
Reversible tokens have the potential to become a PAN again by the process of de-tokenization. For reversible non-cryptographic tokens, obtaining the PAN from its token can only be done by a data look-up in a secure card data vault (CDV), which would then typically retrieve the PAN from a PAN-to-token table within the vault. An authorized user may obtain the original PAN from its token with a de-tokenization request through an appropriate access control mechanism. Authorized use is best done through a tokenization service provider who is a third-party entity (e.g., a processor, acquirer, or payments gateway) providing tokenization services to other entities (such as merchants).
While you cannot store cardholder data, you can use a tokenization scheme to replace it and store the unique token in your systems, without the system coming into PCI scope.
For more information on how tokenization works, read the blog: A Primer on Tokens, Tokenization, Payment Tokens and Merchant Tokens
