This is page 2 of:
Complying With Visa’s July 1 PA-DSS Mandate
PA-DSS applies to third-party applications that store, process or transmit cardholder data as part of the authorization and settlement process. Importantly, this definition includes both standalone applications and payment modules of larger enterprise resource planning (ERP) systems. In all cases, though, you license and host these applications internally.
PA-DSS does not address applications built internally or those that have been extensively customized. These apps are in your PCI scope and are included as part of your annual assessment. Similarly, third-party hosted or Software-as-a-Service (SaaS) payment applications are not covered by PA-DSS because you do not host the application.
Also excluded from PA-DSS are back-office and other back-office types of applications that, while they may access cardholder data, are not directly involved in the authorization or settlement of card transactions.
Lastly, that an application is PA-DSS validated says nothing about its functionality. The application may or may not meet your needs; it may be a horrible application. All PA-DSS says is that app should be compliant and it doesn’t store sensitive cardholder data.
PA-DSS validated applications are not magic. They do not make you PCI compliant. The best you can get: If you install the application according to the vendor’s implementation guide (Hint: Get the guide before you buy!) and install it in a PCI-compliant environment, that application should facilitate and support your PCI DSS compliance. Does this sound a little vague? You bet; but again, it is the best you are going to get. You are still responsible for satisfying all PCI requirements throughout the environment and for maintaining the relevant controls within the PA-DSS application.
What if you have an application not on the PA-DSS list? You could upgrade your noncompliant application with one from the list. Alternatively, it’s important to remember that your acquirer has a critical role in PCI and that that role includes payment applications. If you read the fine print within Visa’s mandate, you’ll see that your acquirer may assess a payment application using its own, alternate, internal validation processes. So long as the acquirer confirms that an application meets all the PA-DSS requirements and facilitates the merchant’s PCI compliance, it meets Visa’s mandate. Some acquirers are doing precisely this, so you may want to check with them to see what program they may have in place.
Your last option is to take the application in-house and include it as part of your PCI DSS assessment, just as though you built it internally. This alternative is admittedly a last resort, and it only makes sense if your users really feel this is the only application on the planet that meets their needs. You will need to get the source code and the documentation, in addition to taking full responsibility for maintaining the application. This decision will also likely trigger a new round of penetration testing and vulnerability scanning, because the new application constitutes a significant change in your cardholder data environment.
As you look at Visa’s July 1 mandate, retail CIOs should keep a few things in mind. If you have a payment application (not back-office payment applications only) that is not PA-DSS validated, talk to your acquirer. After all, Visa’s mandate is between that brand and its acquirers. If your acquirer doesn’t have a solution, your most likely course will be to replace the application with a compliant one. Alternatively, you could outsource (including SaaS) the application. As a last resort, you could pull the application in-house and include it in your PCI assessment. When you use the PA-DSS list, make sure you understand which modules and specific versions are validated so you don’t have to replace the application a second time.
What do you think? I’d like to hear your thoughts. Either leave a comment or email me at wconway@403labs.com.
-Marc
June 10th, 2010 at 9:51 am
This deadline date is interesting, guidance in Europe from VISA Europe is as follows (of course VISA Inc will have their own opinion) :
Effective 1 July 2010, acquirers must ensure that all merchants using payment applications that store (or cause to be stored) sensitive authentication data post-authorisation, or applications that are listed as ‘‘vulnerable’’ by either Visa Europe or Visa Inc. must move to applications that do not store sensitive authentication data.
Effective 1 July 2010, acquirers must ensure that all new merchants only use PA-DSS compliant applications
————————————————-
But when you ask for further clarification they state reply with the following:
New merchants applies to brand new merchants only, not merchants moving from one acquirer to another.
Note the use of compliant, at this stage we are not mandating the certification of applications.
————————————————-
So breaking it down further, Acquirers must ensure merchants dont use a listed ‘vulnerable’ paymwent app from July 1st. Then, new merchants, who have never had a bank acocunt or business before must use a compliant app but not one that has been certified from July 1st..
June 10th, 2010 at 10:12 am
This deadline date is interesting, guidance in Europe from VISA Europe is as follows (of course VISA Inc will have their own opinion) :
Effective 1 July 2010, acquirers must ensure that all merchants using payment applications that store (or cause to be stored) sensitive authentication data post-authorisation, or applications that are listed as ‘‘vulnerable’’ by either Visa Europe or Visa Inc. must move to applications that do not store sensitive authentication data.
Effective 1 July 2010, acquirers must ensure that all new merchants only use PA-DSS compliant applications
————————————————-
But when you ask for further clarification they state reply with the following:
New merchants applies to brand new merchants only, not merchants moving from one acquirer to another.
Note the use of compliant, at this stage we are not mandating the certification of applications.
————————————————-
So breaking it down further, Acquirers must ensure merchants dont use a listed ‘vulnerable’ payment app from July 1st. Then, new merchants, who have never had a bank account or business before must use a compliant app but not one that has been certified from July 1st..
June 11th, 2010 at 5:00 pm
@Chalky,
I find it very surprising that Visa or any brand or acquirer would draw a distinction between a new vs. existing merchant, especially when it comes to PCI. To me it makes no sense. In fact, with merchant IDs and retail locations coming and going, I’m not even sure I know what a “new merchant” would be in this context.
In case you can’t tell, I’m really hoping that the person to whom you spoke misunderstood the question. Did you speak to a compliance/risk person? The answer you got is particularly confusing since several of the earlier mandates (that were part of the same release) dealt explicitly with “newly boarded merchants” as opposed to new merchants.
Merchant risk and PCI compliance is too important to have all kinds of conditions attached. Let’s hope Visa Europe clarifies.
June 13th, 2010 at 9:58 am
The repsonse came back via email from the compliance team for PA-DSS / Payment applications at VISA Europe……..I also asked to see the list of vulnerable ‘third-party apps’ mentioned in your article and they told me it doesnt get put on general release and only goes to the acquirers…….
June 13th, 2010 at 8:31 pm
Well, I guess Visa Europe did clarify their position as you say. I’m a little surprised, but it is their brand and their region, so I guess they get to make the rules. As for the list of known compromised apps, you got the standard response. Visa does not release that list, but as you say your acquirer has direct access to it and can advise you if any app (or version!) you have is known to have been compromised.
Thanks for the update from Visa.