I would like to compliment all payment application vendors who have gone beyond Payment Application Data Security Standard (PA-DSS) to upgrade their offerings so they no longer store any cardholder data electronically. These far-sighted vendors have succeeded in reducing their customers' risk, improving security and, importantly, minimizing their customers' PCI scope. It is a shame that not all application developers have gotten the message.
Although a payment application may be PA-DSS validated, that validation says nothing about whether it stores cardholder data. This seemingly minor issue actually is pretty important to the merchant running the software. The reason is that if the validated application stores electronic cardholder data, then it does not reduce the merchant's PCI scope very effectively.
For larger merchants in this situation, you and your QSA still have to protect all that cardholder data sitting on your system(s). For smaller merchants who self-assess, storing electronic cardholder data means having to use Self-Assessment Questionnaire (SAQ) D with all 226+ requirements instead of one of the simplified SAQs. This can be an unpleasant surprise to those merchants with an anything-but-SAQ-D approach to PCI.
The problem arises when a payment application vendor focuses more on how it complies with PCI and less on how to reduce risk and simplify the merchant's PCI compliance.
Merchants need to use only applications validated against the PA-DSS for a couple of reasons. First—and maybe we can stop with this one—Visa mandates it. If you use a packaged software application for payments, it has to be on the PA-DSS list or approved by your acquirer. The other reason is that when the application is installed according to the vendor's PA-DSS Implementation Guide and in a PCI-compliant environment, you and your QSA don't have to dig into the workings of the code; the PA-QSA already did that.
I still meet merchants who think either that PA-DSS is their silver bullet for PCI compliance (it isn't) or that a validated application will automatically reduce their PCI scope (that is not the case, and the application may actually increase scope).
The problem is that the PA-DSS listing at the Council's Web site says nothing about whether the application stores electronic cardholder data. Let me be clear that if the application stores electronic data—even for a fraction of a second—it constitutes storing electronic cardholder data for PCI.
Historically, applications would have stored data for a number of reasons. An application might write the data to a database for only a few seconds while waiting for an authorization response from the bank; after that, the data was erased. That way if there was a communication problem or the authorization timed-out, the application could resend the request. Other applications kept the data to help if the acquirer lost the merchant's transactions for that day. With the stored data the merchant could presumably reconstruct the batch and not lose any transactions. Still other applications stored the data to help the merchant process refunds or chargebacks.Not one of these is a valid reason to store cardholder data today. Communications are reliable and timeouts are infrequent. When you have a problem, re-swipe the card. If your acquirer loses your transactions and can't reconstruct them from its own records, get a new acquirer. And if you think you are required to keep the data to process exception items, see Visa's recent guidance, which makes the point that storing cardholder data is the acquirer's job, not the merchant's.
Today, the only way to tell if a payment application stores cardholder data is to ask the vendor. I personally wish the PCI Council would add a column to the PA-DSS listings to indicate which of the following three conditions exist: "Yes," the app stores cardholder data; "no," it does not; or "configurable," meaning the merchant has the option. My suggestion does not require any change to the PA-DSS or the validation process, and it would not cost anything. Unfortunately, this change is not likely to happen anytime soon.
I raised the issue recently with a senior executive of the PCI Council. The response was that reporting this information was not a role that made sense for the Council. Instead, it should be "left to the market," meaning it should be the merchants' responsibility. I respect the Council's position; it is a standards body, after all. But I wish its mission could also include making scope reduction a little bit easier for merchants.
Therefore, because "the market" will have to be responsible, I would like to encourage all those vendors whose application does not store cardholder data to shout that fact on their Web sites and in their sell sheets. Believe me, your customers and potential customers want to know this fact. You provide a merchant benefit that goes beyond PA-DSS validation. Merchants who want to minimize their PCI scope or qualify for a simplified SAQ can make a clear choice.
In the same way, software vendors who re-write their applications so they no longer store cardholder data should highlight the benefits of simplified compliance to their merchants.
Although the functionality of the payment application will be critical, whether that application also stores cardholder data should be part of your cost equation along with price and maintenance.
I want to make it clear that merchants may store electronic cardholder data. My professional opinion is that it does not make sense in most cases ("We always did it this way" is neither a justification nor a compensating control). But if a merchant wants to keep the data, it is permitted. Just understand the result is that you will have a new hobby: PCI DSS.
Did you ever get half the story? Have you ever had what a friend in Texas calls "one of them sales critters" rattle on about how they are compliant, while carefully ignoring the fact that their application increases your PCI scope?
What do you think? I'd like to hear your thoughts and experiences. Either leave a comment or E-mail me at [email protected].