PA DSS Is Remarkably Misunderstood

Written by Evan Schuman
October 2nd, 2008

GuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.

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


Comments are closed.


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.