On July 23, 2012 we received the following communication from James Barrow, Director of AQM Programs, with the PCI Security Standards Council. I found it worthy of posting so that everyone understands the procedures their QSA needs to follow regarding applications that are supposedly PA-DSS validated.
The Council has recently received inquiries related to the Validation of Payment Applications process and there seems to be some confusion related to the PCI SSC listing of validated applications. The Council’s website is the authoritative listing of applications that have been accepted by the Council. This is the listing that should be checked by the assessors during each engagement with a merchant. If the merchant’s application (both name and version number) are not on this list, it cannot be considered validated.
There are some instances where a merchant might provide you with a document (not issued by the Council) stating that the application has undergone some type of review and has been deemed compliant. However, if the payment application is not listed on the PCI SSC website, it cannot be considered validated. If such an instance of this arises during one of your engagements, you as the assessor must perform your due diligence in determining if the application is capable of meeting all of the DSS requirements.
For the PA-DSS community we realize that some applications are not applicable to the PA-DSS program. The eligibility for the program is contained in the document entitled “Which Applications are Eligible for PA-DSS Validation? A Guiding Checklist” available at the Council’s document library. If an application is not eligible for the program, it does not preclude you from performing an assessment. However, at the end of the assessment you cannot communicate to your client that per the assessment the application has been “validated”, nor can the client (vendor) expect the assessment to have any bearing on a merchant’s ability to achieve DSS compliance.
Following the above guidance should help to remove any miscommunication or misunderstanding in the payment ecosystem as to what applications are considered validated, and the steps that need to be taken should a non-validated application be identified in the field.
The key here is that if the version of your payment application is not on the PCI SSC’s PA-DSS list, it is not considered PA-DSS validated and your QSA must assess it accordingly. I cannot tell you how many merchants we encounter where they have a different version of the application, yet the merchant insists that we treat it the same as the version that is PA-DSS validated.
We also run into software vendors that insist that the version the merchant is running is not significantly different from the version that is PA-DSS validated. While this could be an accurate statement, the vendor needs to have submitted the version to a PA-QSA for validation of that fact. The PA-DSS has a procedure that the PA-QSA can follow to determine that version changes have not affected cardholder data processing and the application’s PA-DSS validation. Without that validation, as a QSA, our hands are tied and we must conduct a full assessment of the application under the PCI DSS.
Much to the chagrin of a lot of merchants, a PA-DSS validation does not imply that they are PCI DSS compliant. There is also this mistaken belief by merchants that a PA-DSS validation implies that the QSA does not have to assess the application. Under the PCI DSS, a QSA still must assess the application’s implementation and ensure that it was implemented per the vendor’s instructions to maintain its PA-DSS validation. The trouble is that this implementation assessment may not save much, if any, time for the QSA.
