Tokenization vs encryption: which one shrinks your PCI scope

Side by side: what each does to a card number

Read the table a row at a time and the split shows up near the bottom. Both methods satisfy the rule for stored card numbers. Only one can leave the system holding the result outside PCI DSS, and even that one comes with conditions.

The row that matters is “Takes a system out of scope.” An encrypted card number is still the card number, waiting for its key. A token from a well-built system is not the card number at all; it is a pointer that only the tokenization system can follow back. That is why the Council draws the edge of your cardholder data environment differently for each.

What each one is, in the Council's words

The Council's tokenization guidance opens with its definition:

The next line decides whether a token is any good: “The security of an individual token relies predominantly on the infeasibility of determining the original PAN knowing only the surrogate value.” Encryption, in the Council's glossary, is “The (reversible) transformation of data by a cryptographic algorithm to produce cipher text, i.e., to hide the information content of the data.” The word in brackets is the whole story. Encryption is built to be undone.

Tokens are not all alike. The Council's Tokenization Product Security Guidelines sort them into irreversible tokens, which “can never be converted back to the original PAN,” and reversible ones, which come back either through a lookup in the card data vault or through cryptography. That last kind is where tokenization and encryption meet. When a token is “mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key,” the 2011 guidelines say “the resultant token is an encrypted PAN.” A product called tokenization can be encryption under another name, so how it is built tells you more than what it is called.

Tokens and encryption share that list with hashing and truncation. One trap sits in the same requirement: where a hashed and a truncated copy of the same card number live side by side, the standard wants “additional controls” so the two “cannot be correlated to reconstruct the original PAN.”

What each one does to your PCI scope

Encryption: in scope while the key is within reach

The Council answered this in FAQ 1086, which it highlighted on its blog in July 2017. The answer starts flat: “Use of encryption in a merchant environment does not remove the need for PCI Data Security Standard (PCI DSS) in that environment.” Encrypting card data with strong cryptography “is an acceptable method of rendering the data unreadable,” but “encryption alone may not be sufficient to render the cardholder data out of scope for PCI DSS.” Then it lists what stays in:

Read it from the merchant's side. A business that encrypts card numbers also runs the encryption and holds or reaches the keys, and those lines catch it. The relief the FAQ does offer goes to a third party that “receives and/or stores only data encrypted by another entity” and cannot decrypt it, and even then only “if certain conditions are met.”

Tokenization: a token-only system can fall outside

Tokens can shrink PCI scope, but “Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance.” The tokenization system never leaves scope: “All elements of the tokenization system and process, including de-tokenization and PAN storage, are considered part of the cardholder data environment (CDE) and are therefore in scope for PCI DSS.” A system holding only tokens is out of scope only if the PAN cannot be recovered from those tokens and the system cannot affect cardholder data security. The guidelines spell that out as tests, and a system must pass every one:

The Council's own summary is shorter: “The key for merchants wishing to reduce their PCI DSS scope is to not store, process, or transmit cardholder data.” Then, in case that was too subtle: “If you don’t need it, don’t store it!”

Sort your own setup

Pick the setup nearest to yours. Each answer is the Council's rule for that case, quoted with its source. Your acquirer still has the last word on which questionnaire you file.

Tokens from your processor: what stays yours

If you take cards through a payment gateway, the tokenization is usually the gateway's: the card goes into its page or field, and your shop gets a token back. That is the outsourced model in the Council's guidelines, and it takes real work off your desk. Not all of it.

The standard says the same about every provider: “The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity's responsibility for its own PCI DSS compliance.” (Requirement 12.8.1, applicability notes.)

Where the card is typed decides your form, not what you get back afterwards. If every card field comes from the processor, SAQ A may fit: “Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated and compliant third parties. No electronic storage, processing, or transmission of account data on their systems or premises.” If your own site builds the payment form, tokens returned later do not change that.

If you encrypt card numbers yourself

Some shops keep card numbers on purpose, for phone orders or old billing software, and encrypt them. Requirement 3.5.1 allows that, and the storing system is then plainly in scope: the SAQ Instructions send “Merchants with electronic storage of account data” to SAQ D. You also take on the key duties of Requirements 3.6 and 3.7.

Card numbers in transit are a separate rule. Requirement 4.2.1 wants strong cryptography and security protocols to safeguard PAN “during transmission over open, public networks.” When the card is typed into your processor's page, that connection is the processor's. When your own server sends card numbers anywhere, it is yours.

Using both: P2PE at the counter, tokens after

At a counter, the Council's best case uses both. Its list for getting the most scope reduction ends here:

P2PE is encryption done as a listed product: “A PCI-listed point-to-point encryption solution includes a combination of secure devices, applications and processes that encrypt cardholder data from a PCI-approved point-of-interaction (POI) device through to a secure decryption environment.” This is where encryption does buy a merchant a shorter form, and it does so through the listing, not by itself. A PCI-listed P2PE solution “can significantly help to reduce the PCI DSS validation effort of a merchant's cardholder data environment.” Only a solution on the Council's list qualifies a merchant for SAQ P2PE; an “encrypted reader” that is not listed does not.

SAQ P2PE is for “Merchants using only a validated, PCI-listed Point-to-Point Encryption (P2PE) solution. No access to clear-text account data and no electronic account data storage.” It is not for e-commerce. Once the card is read that way, tokens keep the card number out of your till software and customer records, as long as refunds, chargebacks and loyalty tracking can run on the token, which the guidelines name as the thing to look for.

On one receipt