Essentially, this standard could cause merchants in all industries and of all sizes to have to switch payment application vendors. Furthermore, since 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 would also have to change. 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 (e.g., via a form that someone fills in or automated means), processes, or stores card data is included in the scope of PA DSS. That means that ALL merchants (even Level 4s) must only be running validated applications and this means that application vendors must pay to have their application 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, with resulting "variability" in the quality of assessment, because low-ball-bidders have to make a profit on their assessments. As a result, 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 they are waiting until customers demand PA DSS compliance before having their software tested, and/or that their customers (the merchants) have no clue about PA DSS, so they don't want to get their current version validated, when a new version will be coming out in another 6 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 which 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, thusfar, 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? Read rest of article