In the same way you wouldn't buy your gold Rolex from a street vendor, you shouldn't buy a software payment application that is not on the PCI Council's list of PA-DSS validated applications. My advice to retailers: If an application is not on the list, don't even include it in an RFP. (For a look at the apps that were found to actually retain prohibited data, see our story about the Visa Bad Apps list.)
In October 2007, Visa issued a series of mandates to acquirers addressing merchant PCI compliance. The last of these mandates says acquirers have to ensure that their merchants who use third-party payment applications are using only PA-DSS-compliant versions by July 1, 2010. (Note: This date refers to Visa USA; other regions may have different timelines.)
Although originally aimed at smaller Level 3 and Level 4 merchants, a few nuances to this mandate have a number of Level 1 CIOs scratching their heads. Unfortunately, the mandate may also cause some CIOs to look for PA-DSS validated applications when they may not necessarily need to. In a few cases, it may even cause CIOs to reject a potential software application unnecessarily. To avoid either mistake, we should understand what Visa's mandate does and does not cover, in addition to some nuances in the PA-DSS program.
The PA-DSS evolved from Visa's Payment Application Best Practices (PABP) program, the goal of which was eliminating "vulnerable payment applications." These apps are defined as those that store the magnetic stripe (or chip) information or other sensitive authentication data such as the three-digit security codes or PINs. Visa maintains a list of vulnerable payment applications and updates it quarterly. Although the brand does not release this list publicly, you can check the status of any application you have by contacting your acquirer.
The applications on the PA-DSS list are version-specific, so make sure your vendor delivers a compliant version. You want to avoid the pleasure of paying again for an upgrade to the PA-DSS validated one. Validated applications have an expiry date, so check that, too, when you are evaluating your purchase.PA-DSS applies to third-party applications that store, process or transmit cardholder data as part of the authorization and settlement process. Importantly, this definition includes both standalone applications and payment modules of larger enterprise resource planning (ERP) systems. In all cases, though, you license and host these applications internally.
PA-DSS does not address applications built internally or those that have been extensively customized. These apps are in your PCI scope and are included as part of your annual assessment. Similarly, third-party hosted or Software-as-a-Service (SaaS) payment applications are not covered by PA-DSS because you do not host the application.
Also excluded from PA-DSS are back-office and other back-office types of applications that, while they may access cardholder data, are not directly involved in the authorization or settlement of card transactions.
Lastly, that an application is PA-DSS validated says nothing about its functionality. The application may or may not meet your needs; it may be a horrible application. All PA-DSS says is that app should be compliant and it doesn't store sensitive cardholder data.
PA-DSS validated applications are not magic. They do not make you PCI compliant. The best you can get: If you install the application according to the vendor's implementation guide (Hint: Get the guide before you buy!) and install it in a PCI-compliant environment, that application should facilitate and support your PCI DSS compliance. Does this sound a little vague? You bet; but again, it is the best you are going to get. You are still responsible for satisfying all PCI requirements throughout the environment and for maintaining the relevant controls within the PA-DSS application.
What if you have an application not on the PA-DSS list? You could upgrade your noncompliant application with one from the list. Alternatively, it's important to remember that your acquirer has a critical role in PCI and that that role includes payment applications. If you read the fine print within Visa's mandate, you'll see that your acquirer may assess a payment application using its own, alternate, internal validation processes. So long as the acquirer confirms that an application meets all the PA-DSS requirements and facilitates the merchant's PCI compliance, it meets Visa's mandate. Some acquirers are doing precisely this, so you may want to check with them to see what program they may have in place.
Your last option is to take the application in-house and include it as part of your PCI DSS assessment, just as though you built it internally. This alternative is admittedly a last resort, and it only makes sense if your users really feel this is the only application on the planet that meets their needs. You will need to get the source code and the documentation, in addition to taking full responsibility for maintaining the application. This decision will also likely trigger a new round of penetration testing and vulnerability scanning, because the new application constitutes a significant change in your cardholder data environment.
As you look at Visa's July 1 mandate, retail CIOs should keep a few things in mind. If you have a payment application (not back-office payment applications only) that is not PA-DSS validated, talk to your acquirer. After all, Visa's mandate is between that brand and its acquirers. If your acquirer doesn't have a solution, your most likely course will be to replace the application with a compliant one. Alternatively, you could outsource (including SaaS) the application. As a last resort, you could pull the application in-house and include it in your PCI assessment. When you use the PA-DSS list, make sure you understand which modules and specific versions are validated so you don't have to replace the application a second time.
What do you think? I'd like to hear your thoughts. Either leave a comment or email me at [email protected].