This is page 2 of:
Overpaying For PCI Compliance
The cardholder dataflow diagram should include all your payment card activity–POS, MOTO, E-Commerce, fax, carrier pigeon, whatever. Be thorough. Think about whether you take payments at tradeshows or if you have old card data for system testing that never got purged. Should you use an automated tool to make sure you locate all your cardholder data? You might have servers and laptops containing years’ worth of PANs that you don’t know about, so it’s worth considering.
Using the two diagrams, critically question where and why you are storing cardholder data. Your goal is to reduce PCI scope ruthlessly. Here is where it pays to get some payment expertise. Can your acquirer advise you on reducing your PCI scope in areas like chargeback processing, refunds and recurring payments? Can your QSA? Can someone else? If you go the acquirer route, speak to someone with payment processing and compliance experience, not necessarily your sales rep.
Once you have completed Requirement 0 you are ready to tackle the other 12 requirements with a (hopefully greatly) reduced scope. Otherwise, you will spend too much money segmenting your network to protect unnecessary databases, configuring unneeded logging and monitoring systems, encrypting data you don’t really need and overspending to satisfy PCI requirements. The PCI Council covers scope reduction when it trains QSAs. I hope the new Merchant QSA training will emphasize it even more. (Note to Bob and Troy: We’re counting on you.)
Every merchant needs to understand that there are two immutable laws of PCI. The first is that your costs will increase. They may go up a little or a lot. Either way, you have to spend something on PCI compliance to continue to take payment cards, even if you outsource everything. It is not PCI’s fault. Blame the bad guys; they are the enemy.
The second law of PCI is that you will change the way you do things. Here is where Requirement 0 comes into play. Treat cardholder data as toxic. Seek out and eliminate cardholder data wherever and whenever you can. You likely will need to change some back-office procedures (e.g., processing chargebacks and refunds), and the inconvenience may increase your costs. But it may be cheaper than protecting cardholder data that is spread around the enterprise.
A side benefit to Requirement 0 is that it may make you more secure. No merchant is likely to be 100 percent PCI compliant 100 percent of the time. Unfortunately, the bad guys only have to be right once. That is why there are continuing compliance requirements, from quarterly vulnerability scans to daily log checks, built into the standard. When you minimize your scope and reduce the amount of cardholder data, you not only minimize your compliance effort, you reduce the attack surface for the bad guys. There is no such thing as 100 percent security, but every little bit helps.
How have you reduced your PCI scope? What has been your experience working with your acquirer? Do you think you are spending too much to get compliant? Leave a comment or E-mail me at wconway@403labs.com.
-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.