Overpaying For PCI Compliance
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
Are you paying too much to validate your PCI compliance? It’s possible, even likely, that you are. The reason is not that your QSA is too expensive or that PCI is too demanding. Rather, the reason many merchants pay too much is that they forget PCI Requirement 0. You don’t know Requirement 0? It says: Minimize Your PCI Scope. Failing to comply with Requirement 0 may be due to inertia or ignorance or both. Regardless of the reason, the result is excessive and unnecessary spending on people, process and technology, together with a lot of frustration.
Although there may be legitimate reasons for storing cardholder data, many merchants store too much data and keep that data in too many places. One reason is inertia: “We always did it this way.” Another reason is that merchants do not understand all the ins and outs of the payment card business. Some acquiring banks have excellent education and support programs for their merchants. But the blame rests with the majority of acquirers and processors that do a poor job of educating and informing their merchants. Despite the reason, too many merchants fail Requirement 0.
For example, many merchants retain PAN data for chargebacks and refunds. In reality, there should be no need for this storage; your acquirer can locate any transaction based on date, amount, authorization response code and the last four digits of the PAN–all of which you may keep and are out of PCI scope. Similarly, storing cardholder data for recurring payments is not necessary if the merchant sets up the initial authorization properly. The merchant only needs the response code for subsequent transactions. And there is no need to retain cardholder data for customer service; for example, to locate a transaction. Again, some combination of the date, amount, authorization code and last four digits can be used to find any transaction with your acquirer. If any one of these needs is causing you to retain cardholder data, you may rate a Requirement 0 FAIL. And if your acquirer can’t help you fix the situation, you might consider getting a new acquirer.
Requirement 0 tells you to stop, take a deep breath, analyze your processes and challenge everything. The two things you need are a network diagram and a map of your cardholder dataflow. Interestingly, it may be difficult to get a comprehensive network diagram. A Department of Justice prosecutor once told me how the DOJ busted a carder ring that had remotely mapped out a target merchant’s network and put it on a giant poster. Upon seeing the poster, the merchant asked if it could keep it. Turns out the bad guys had a better network diagram than the merchant
-Marc
March 10th, 2010 at 1:25 pm
Hey Walter,
Great post. Probably the best I’ve seen in quite some time. This is something I and my company harp on all the time but far too often, it falls on deaf ears. The #1 reason for this deafness: “We always did it this way”, followed by “that would be too hard to change our procedures.” More times than not, merchants can eliminate the storage of this data without much impact on their procedures but they need to shed the always “done it that way” shell. Yes there are exceptions, but with serious thought, the exceptions are just that, exceptions. Great job!
March 10th, 2010 at 5:44 pm
There are two use cases that often cause scope to creep back in – especially with subscription services.
1. How does Customer Service terminate an account when all they have is the PAN and a date? Most subscription services have 1 -3 price points so price doesn’t give one much information. If a parent or the victim of card theft is calling in, the last 4 digits can easily match more than 1 transaction per day.
2. Acquirer lock in remains a core concern with tokenization. If a merchant’s acquirer has tokenized all a subscription merchant’s cards and the merchant needs to change providers, does the merchant get to have his cards with their associative data back to take to another provider?
-Gene
CEO
Vindicia, Inc.
March 10th, 2010 at 7:57 pm
Hi Gene,
To address you points: 1) Use additional data like name, email address or physical address with the last four digit may be an option. 2) Use a processor/acquirer neutral gateway, but I’m abviously bias. Putting my bias aside, merchants change processors or banks much more than they change gateways — unless the two are tied together as with a non-neutral gateway.
March 11th, 2010 at 6:13 am
We tend to have to store full PAN for missing and incomplete transactions….
March 11th, 2010 at 10:12 am
In regard to tokenization, consider implementing your own tokenization solution (vs. outsourcing to your acquirer, gateway, or processor). You can still reduce scope by focusing your controls on the token vault environment (and the systems that call the tokenization solution) and maintain complete independence. You can also extend your tokenization platform to address other sensitive data like PII.
March 11th, 2010 at 1:09 pm
Steve,
I may have been too brief with my use cases.
1. Let’s assume a kids subscription game. Dad looks at his credit card and sees a charge he’s been ignoring for months. He has no idea which of 2 sons or 1 daughter signed up and further doesn’t know which of the about 4 email addresses his kids used to sign up. How do you rely on anything but luck to find that TX? Further, you can’t afford the risk of cancelling the wrong one. There is one way around that problem, but it is advanced.
2. Customer who never signed up for your free trial to recipes as a service recieved a debit from your service. A card thief used your free trial as a card test and the $2000 in soon to be stolen electronics is about to post to the cardholder’s account. How do you find that account and refund it to stop the chargeback?
-Gene
March 12th, 2010 at 12:02 pm
iNTERSTING PERSPECTIVE.
March 12th, 2010 at 2:58 pm
Gene,
Interesting scenarios.
I think that these considerations are important input to the internal risk assessment for any organization.
Consider that there are many other non-PCI data elements (name, date, email, amount, first 6 and last 4 digits of the PAN, etc.) available to track down these types of transactions. The organization should take a critical look at how often something like this actually happens, how often the PAN is *really* required for resolution, and how much (or how little) work/expense it might be to get help from the acquirer to research a transaction based on PAN. Use your total security/compliance budget in your analysis and determine if the cost of securing that PAN data and complying with PCI outweighs any benefit of storage.
I think that many organizations find, after critical examination and risk analysis, that keeping large repositories of PAN data to research or resolve a small number of anomalies is not worth the risk and expense.
Remember, “We’ve always done it this way” is not a security control.
Of course, your mileage may vary.
-Todd
March 16th, 2010 at 12:16 pm
One can always come up with a theoretical scenario that requires maintaining full card holder data. Heck, my company is a gateway provider and we’ve had instances where if we stored the full raw track information, it would have greatly helped in diagnosing and solving a problem — the full PAN was not enough. But we don’t store this information because of PCI and more importantly, the increased risk profile, and we were not willing to accept this risk.
The key is balance security and risk with usability. Most of the time, the card type and last 4 digits of the PAN contained in the token is enough to return a limited result set and from there you should be able to lookup the associated accounts in your billing system. In the scenario described, what if all three kids signed up but the father wanted to cancel the two sons accounts, but not the daughters — even the full card number would not solve the problem 100% and you would need to reference the billing system.
Bottom line, just make sure you fully consider all your options, think outside the “we’ve always done it that way” box and in today’s environment I would recommend erroring on the side of security.
March 27th, 2010 at 3:56 pm
Great topic, Walter. This is the #1 issue I tackle when beginning any PCI project with a client: let’s do everything to lessen and get specific with your scope. It not only gives the client a better chance at passing the assessment (or, more correctly, fewer chances to fail), but in tightening up the processes and systems, the company’s liability is reduced, as well.
In response to “well, we’ve always done it this way” is another gem: well, we’ve never had a need for doing it that way. PCI may have its detractors, but I see the requirements helping companies adopt the new paradigm of cloud computing and, realizing that nothing is ever completely “secure,” spread around the liability so that if there is an incident, their entire business doesn’t come to a grinding halt.