Evan Schuman's StorefrontBacktalk

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

If your goal is to limit your PCI scope, should you pursue tokenization or end-to-end encryption? Or should you do both? I find it interesting that many large (L1 and L2) merchants are actively pursuing both options, and I’m wondering if that really makes sense from either a PCI or an economic perspective.

Maybe tokenization and end-to-end encryption are just two closely related approaches that can, when properly implemented, accomplish the same thing: minimize your total PCI scope. One thing is for sure, though: Either way, you will need to bring your checkbook.

Everybody wants to minimize their company’s PCI scope. When I look at scope issues, I generally classify systems into two broad areas. The first is the set of applications and network infrastructure in the payment transaction flow from the POS to the processor/acquirer and back. The second area of scope deals with post-transaction applications that use the data; for example, velocity checking/fraud systems, relationship management, delayed or split shipments, recurring payments, and chargeback and refund processing.

The best way to minimize PCI scope is to not store cardholder data (like the PAN) electronically–ideally, on any of your systems. Although I personally think this approach is possible, I understand that it is not always practical, given the post-transaction applications every retailer uses. Therefore, merchants are looking at a choice of tokenization or end-to-end encryption to get all that nasty cardholder data out of their PCI scope.

The first thing you need to understand is that you have to bring your checkbook. There is nothing too difficult about converting a PAN to a token–just replace the middle six digits with a sequence number, for example. Similarly, although it may take some work, you could encrypt your cardholder data using internal systems and processes. Unfortunately, the PCI Council effectively ruled out both options, saying that if merchants want to implement either of these technologies then they will have to go outside and buy them from a processor or a vendor.

The Council spelled out its reasoning in response to a question about when encrypted data could be considered out of scope: “However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” As I noted in an earlier StorefrontBacktalk column, the key question here is, what is an “entity?”

I don’t know the Council’s intent, but I can tell you that if “validated” means “validated by a QSA” then you can likely forget about the “entity” being a division or subsidiary of your company. To this QSA at least, if you want to use either tokenization or end-to-end encryption to reduce your scope then you are going to have to go to an outside, independent party—be it your acquirer or a vendor. It’s a bit like bringing your own popcorn to the movies; while it may make a lot of sense to you, it just isn’t allowed.

Let’s look first at tokenization, the process whereby, when properly implemented, the PAN may be rendered out of scope for PCI.