On June 29, 2011 the PCI Security Council released a checklist outlining the types of payment applications that are eligible for PA-DSS validation:
A series of 13 questions were outlined and if you answered “yes” to any of these questions, your payment application is not eligible for PA-DSS validation. Here are a couple of those questions that will likely impact many organizations who were considering or are in the process of having applications validated against the PA-DSS.
Question #3 – Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
This is a significant impact to those vendors that have spent both time and resources to implement a tokenization solution where they do not have access to cardholder data and therefore, their payment application would not qualify for PA-DSS validation. There is a caveat – applications deemed as “payment middleware” or “payment back office” that create the token value and therefore, have access to cardholder data, would qualify for PA-DSS validation.
The Council has developed a task force to address data tokenization/point-to-point encryption and is working to develop guidelines on how this impacts PA-DSS validation.
Question #9 – Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
“Other software” here is defined as software specific to your payment application. For example, if SQL Server or other third party software is required by your payment application but not “bundled” with it, this is not a concern and would not apply. However, this is yet another significant impact to what portions/modules of a payment application are in scope. As defined by the Council:
“PA-DSS does apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. PA-DSS may only apply to the baseline module if that module is the only one performing payment functions (once confirmed by a PA-QSA).
So what does this all mean? The “baseline” module of your payment application is in scope for PA-DSS even if it does not perform payment functions. Modules that perform payment functions, including the baseline module would be included in scope of the PA-DSS review.
As a best practice and general guidance: Develop your payment application with a base installation and isolate payment functions to only specific modules.
And of course, speak with your PA-QSA to ensure they fully understand your application – PA-DSS validation requires significant work and you don’t want to find yourself going down this road only to realize your payment application is not eligible for PA-DSS validation.
Shelina Samji, PCI QSA
Senior Consultant, PCI Compliance Services
Get Ready for PCI DSS v4.0
For PCI recommendations on payment processing with newly remote workers, PCI SSC suggests a review of key areas to protect payment card data. Read Article: Payment Processing in a Remote Working Environment