Overpaying For PCI Compliance

Written by Walter Conway
March 10th, 2010

A 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


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.