Overpaying For PCI Compliance
Written by Walter ConwayMarch 10th, 2010
Are you paying too much to validate your PCI compliance? It’s possible, even likely, that you are, suggests PCI Columnist Walt Conway. 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.
This Story Is Only Available For Premium Subscribers. Click Or Login In Below To Read The Rest Of This Story.
Already a Subscriber? Login Here
Pages: 1 2
10 Comments | Read Overpaying For PCI Compliance
Leave a Reply
Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
-Ed
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.