Most merchants and application vendors seriously underestimate both the scope and the force of the Payment Applications Data Security Standard (PA DSS). If so, it's only because they haven't read the standard or don't immediately grasp what's involved. Essentially, this standard could cause merchants of all sizes in all industries to have to switch payment application vendors.
Furthermore, because these applications are not generic "plug and play" software "modules," any changes will require changes to all custom code designed to integrate with ERP, sales audit, general ledger and other office management applications. In short, PA DSS is a much "bigger deal" than the 1.2 release of the PCI DSS.
The Scope of PA DSS. Any application packaged for sale that collects, processes or stores card data (e.g., via a form that someone fills in or automated means) is included in the scope of PA DSS. This means that ALL merchants (even Level 4s) must only be running validated applications and that application vendors must pay to have their applications tested in a "laboratory" by a PA DSS QSA (assessor), a list of which is conveniently maintained by the PCI Security Standards Council, who recently took over the task from Visa.
Assessment is price-competitive. Currently, there are fewer than 20 companies worldwide that have been approved to test and validate PA DSS compliance. More are joining the list all the time. Because the demand from merchants and, hence, application vendors is just developing, we're hearing stories of a very price-sensitive market. The result is "variability" in the quality of assessment, because low-ball bidders have to make a profit on their assessments. So we caution all merchants not to assume an equal level of data security between two application vendors just because they both appear on the PA DSS "white list." Merchants need to do their own validation of the data security controls and ask for copies of the PA DSS test reports.
The application vendor's dilemma. We've interviewed application vendors who tell us that they are waiting until customers (the merchants) demand PA DSS compliance before having their software tested and/or that these customers have no clue about PA DSS. As such, they don't want to get their current version validated, particularly when a new version will be coming out in another six months and they'd have to pay to have it tested also. The issue of "Why pay for security testing that customers don't even care about?" is likely to continue for another six months or so. As long as the focus of the SSC and the card brands is on the "minor tweaks" in PCI DSS 1.2, there will be less marketing bandwidth available to highlight the major changes that PA DSS will bring about in the market.
The demand lag and its market impact. This "cat and mouse" issue of paying to have a version validated prior to demand for PA DSS will get much more complex over the next two years. Most application vendors have, thus far, only had zero or one version tested, because it's expensive and demand is "immature" at best. We expect that getting tested and being on the PA DSS "white list" will become part of nearly all relevant RFPs within a year. If this doesn't happen, then it's highly unlikely that the merchant community (all levels) will be running all PA DSS-compliant applications by the October 2009 and July 2010 deadlines. Faced with potentially massive non-compliance, the logical response would be to postpone the deadlines. It's happened before.
What are the compensating controls for PA DSS? There are none. Merchants or application vendors who are looking to "sneak by" PA DSS by saying they've built a really strong DMZ around their application are out of luck. The standard does not include a provision for compensating controls. Considering how many merchants and assessors tell us that compensating controls are quite common, this is another reason why we believe that it's better to review applications sooner rather than later.
If your application fails, you fail. Simply put, if a merchant is not running a PA DSS-validated application after the deadline, they will automatically fail their PCI assessment. It may be possible to apply compensating controls for this part of the assessment (or self-assessment), but this is clearly not the intent of the standard.
The time to act is now. I'm not an alarmist and I almost never say stuff like this, but based on the "PCI Best Practices" interviews we've conducted for the PCI Knowledge Base it's pretty clear that 99 percent of merchants (even some of the largest ones) are not running PA DSS-validated versions of their applications. Given the complexity of the process of upgrading or, worse, switching application vendors, it's important to begin having discussions with your application vendors now, rather than waiting until there are only a few months left before the 2009 deadline.
If you're a retailer, we want to get you involved in the PCI Best Practices study we're doing with the National Retail Federation. It's 100 percent anonymous. Just send us an E-mail at [email protected]