Tokenization has become a hot topic lately as Enterprise customers attempt to minimize their exposure to the loss of sensitive data. Tokenization is an alternative to encryption and one-way hashes for data protection. But I think it is time to dispel some of the myths about tokenization, and discuss where this technology can be helpful in minimizing your risk.
First, tokenizing data does NOT let you bypass PCI compliance requirements. If you are a Level 1 merchant (and Level 2 at the end of 2010), you will still have to perform an annual PCI audit by a qualified QSA auditor. If you are a Level 3 or Level 4 merchant, you will still need to complete the self-assessment and meet the requirements of PCI. In some cases tokenization can help minimize the impact of PCI compliance, but in most cases it is not going to provide a significant benefit. This same is true for HIPAA and state privacy regulations.
If you are using payment-network-assigned tokens as replacements for credit card numbers, you are going to benefit by a reduction in the need to encrypt the account number and related cardholder information. In this case, when you send a payment authorization to the payment network, the response contains a token that you can store for later use. When you settle the authorization, or when you make future authorizations for recurring payments, the token will be used instead of the original credit card number. You never store the original credit card number in your database. That reduces the work you need to do to protect sensitive information, but does not get you out of PCI compliance. Only a small number of payment networks now support tokenization, so it is unlikely this is going to help you in the near term.
If you create the token on your local server, you will probably get very little relief from PCI, HIPAA, and other privacy regulations. If the token allows recovery of the original data, you have all of the normal obligations to protect the data. And, your risk may actually increase if you store the tokens for multiple applications in the same database, or if you store those tokens on the same server as the production data. For example, let’s say you store credit card numbers in the token database along with employee social security numbers, and customer account numbers for electronic funds transfer. If you have a compromise of the token database, you now have an exposure to multiple compliance regulations. Unauthorized access to the token database means you have to assume you’ve lost sensitive data for several applications.
There is one area where tokenization can provide an immediate and significant benefit – minimizing exposure in test, QA, and user acceptance environments. Many companies use multiple test and QA environments as they migrate system changes into production. To do this, you need realistic data in your test and QA databases. It is common to take snapshots of production data and use this for testing. However, this practice exposes sensitive data to a much larger group of people. Using tokenization, to replace sensitive data with bogus data, greatly reduces the risk of exposure.
The main problem I see with tokenization is that it lacks a proper definition by any standards group. It was heartening to see Visa issue some guidelines on best practices for encryption and tokenization just this month. While these are not yet formal standards, they do represent a good framework at which to look at tokenization. I was satisfied to see that our products match up with these best practices.
As many of you already know, we are just now releasing version 2 of our tokenization support. It provides an implementation of tokenization that will help you protect test and QA environments, allows separation of tokens from the production database, provides a common token database for Windows, Linux, UNIX, and System i applications, and meets proper standards for encryption and token creation. And of course it matches the Visa Best Practices guidelines for creating tokens so that you are prepared for future developments in this regulatory environment.
I hope this helps you cut through the haze of bogus information floating around about tokenization. As always, if you need more information about encryption, tokenization, or data security, you can get answers on our website or contact me directly.
Patrick