This is page 2 of:

Overpaying For PCI Compliance

March 10th, 2010

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


10 Comments | Read Overpaying For PCI Compliance

  1. Steve Sommers Says:

    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!

  2. Gene Hoffman Says:

    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?

    Vindicia, Inc.

  3. Steve Sommers Says:

    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.

  4. Mark Says:

    We tend to have to store full PAN for missing and incomplete transactions….

  5. Brian Grafsgaard Says:

    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.

  6. Gene Hoffman Says:


    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?


  7. Dave CISA/M/SP Says:


  8. Todd Aument Says:


    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.


  9. Steve Sommers Says:

    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.

  10. John Cartwright Says:

    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.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.