What would you do if your tokenization vendor goes out of business or gets acquired by a company with a whole different approach to tokenization? This is the ever awkward but increasingly important question every IT executive looking at tokenization needs to ask.
The reality is that there are many firms in the tokenization space today, and you cannot count on all of them being around forever. Some will change business focus, go out of business, or be acquired. Because there are no standards for tokens across vendors, transferring to another vendor could be difficult. That means retail CIOs need to address what to do if (when?) the unforeseen happens.
You may want to include this eventuality in your annual risk analysis. There are no easy answers. But you need to spend some time confirming the stability of your potential provider and developing a contingency plan if the worst happens.
You also should negotiate a service-level agreement that addresses your tokenization provider's reliability and fallback processing. Attendees at the recent PCI Community Meeting heard about an encryption vendor that, due to a system glitch, stopped encrypting cardholder data. The company just passed the cleartext PANs back and forth to the merchant. The situation went undiscovered for quite some time, and it resulted in a data compromise.
In a previous column I noted that, as IT executives walk down Tokenization Street on Halloween hoping to receive goodies, they need to ask some questions before holding out their trick-or-treat bags. That is, they should not just accept whatever is put into it. That column highlighted five questions. Number six is the question from above: What happens if your tokenization vendor disappears? We get to four more below, for a total of 10 questions you need to ask before you make your decision.Your goal is to determine how tokenization will reduce your PCI scope and, thereby, the total cost to achieve and maintain PCI compliance. As I pointed out last week, I won't pretend to have all the answers. However, this set of 10 questions should get you headed in the right direction—or at least help you avoid an expensive disappointment.
Before you commit to any approach—whether it is software, a hardware appliance or hosted by a third party—you should know if it requires any upgrades or application changes.
That is, will you need to upgrade your POS terminals or payment application to fit with the tokenization application (my third question)? Does the tokenization application or appliance have compatible interfaces (APIs)? On the other side of the process, will your downstream applications be able to use the actual tokens as generated (my second question), or will they need to be rewritten? For example, if a marketing application requires a token that complies with the Luhn algorithm ("mod 10") checksum test, make sure you generate that type of token or plan to update the application.
Hopefully, the answer to this question is "no." But you should check to be sure. Many payment applications store PAN data, if only briefly. For PCI purposes, whether you store cardholder data for a millisecond or a year, you are storing cardholder data, and even with tokenization your payment application may remain in scope.
Retailers should work with their application vendor (or internal developers) to reconfigure or upgrade the payment application so it processes or transmits the cardholder data but does not store the data. It would be a shame to spend the time and effort to implement tokenization and find out that your payment systems are still in scope.
That is, will the provider accept responsibility for the security of your cardholder data in their control? I have written (some say ranted) about this issue before (see here and here), so I won't repeat myself. The point is, knowing your tokenization provider is PCI compliant is a nice start. But by itself that is not enough to meet this requirement.This question highlights an interesting quirk in PCI DSS. That is, although retailers are required to get their vendors to accept responsibility, there is no corresponding requirement on the part of vendors to provide it. Smart vendors will have no problem addressing this question to a retailer's satisfaction. If you encounter resistance, you may want to check out some of your many alternatives.
I like to break this question into three parts.
First, will you host your token vault containing the (encrypted) PANs and tokens or will a third party hold it? Hosting the vault yourself gives you the most flexibility. Additionally, because all of your PAN data is in one place, you can focus your efforts on protecting it. That vault, though, will be in your PCI scope. Having a third party host the token vault removes it from your scope and may reduce PCI scope the most.
Then consider the tokenization methodology itself. Are the tokens secure, and do they comply with Visa's best practices? How much will it cost to upgrade or replace hardware or software to implement the particular tokens?
Last, consider your tokenization provider. Almost every card processor offers, or soon will offer, tokenization. For the vast majority of small and midsize business, this approach will be a very attractive in terms of both cost and convenience. Larger retailers may prefer the flexibility that comes with controlling their own environment.
There is much more to tokenization trick-or-treat than we have covered. For example, we have not addressed the importance of securing and restricting access to the token vault, connecting the token vault to your data warehouse, avoiding token collisions with valid PANs, single-use vs. multi-use tokens, running out of token space (there are only so many numbers after all, especially if you retain the last four digits of the PAN) or even the many applications for tokenizing sensitive data outside of PCI DSS.
What do you think about tokenization and the questions you should ask? I'd like to hear your thoughts and experiences with tokenization. Either leave a comment—whether a trick or a treat—or E-mail me at [email protected].