With the advent of SAQ A and A-EP, there seems to be confusion as to what meets what for each SAQ. I thought I covered this rather well in my post titled ‘Of Redirects And Reposts’. But apparently that was not clear enough.
For outsourced eCommerce solutions, the criteria from SAQ A states it can be used if and only if:
“The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).”
For some service providers it appears that there seems to be a lot of misunderstandings as to what constitutes “originates directly from a third party”. A lot of processors believe that if their customers’ Web sites are not storing cardholder data (CHD) or sensitive authentication data (SAD) then they are out of scope regardless of the method used to process a customer’s payment. What they seem to forget is that applications that process and/or transmit CHD/SAD are in-scope for PCI compliance just as those that store CHD/SAD.
For SAQ A and A-EP, the Council took their lead from Visa Europe as to what is meant by “originates directly”. Visa Europe’s Processing eCommerce Payments guide has a great matrix that explains the difference between SAQ A and A-EP by payment processing type and merchant level.
With redirects and iFrames, the merchant’s Web server never comes into contact with the CHD or SAD because the customer is communicating directly with the transaction processor’s server. PayPal is a prime example of a redirect and meets the criteria of SAQ A. With a direct post, JavaScript, XML or any other techniques, the merchant’s eCommerce server is at least processing and/or transmitting the CHD/SAD to the processor’s servers. That is because there is some form of code/executable/script/etc. that is running on the merchant’s eCommerce server thus placing it directly in-scope.
Where things seem to get confusing is with processors that offer multiple methods of completing payments. Unfortunately, it also appears to be just as confusing to the processors’ sales personnel as well. We have encountered numerous instances where the processor’s sales people believe all of their solutions make the merchant out of scope when only the redirect/iFrame solution they have provides such a scope reduction. All of their other solutions place the merchant directly in-scope.
The bottom line is that it is extremely important to get the transaction processor to explain how a payment is processed to determine whether your server is or is not out of scope. Even if the sales person says the solution is an iFrame or a redirect, make sure to quiz them enough to ensure that they truly are delivering you an iFrame or redirect solution.
But a word to the wise. Security professionals will question a merchant’s decision to not worry about the security of their eCommerce Web server because there still is a risk even with the redirect or iFrame approaches. That risk is that the code/executable/script/etc. that invokes the redirect or iFrame on the merchant’s server gets tampered with or changed and now invokes a Web site that is not the transaction processor’s Web site. As a result, a merchant’s customers’ CHD/SAD could be sent to Timbuktu and no one would be the wiser until goods/services are not provided due to non-payment.
As a result, security conscious merchants will, at a minimum, ensure their eCommerce servers are properly security hardened, patched current and will monitor the code/executable/script/etc. for changes. Should a change be detected, the server would then be brought offline and fixed to ensure that transactions are properly processed.
Hopefully this provides everyone with clarity on how to use these SAQs peroperly.
One additional thing I would like to point out. If you look at the Level 1 merchant line of the Visa Europe matrix, it shows ROC subscripted with either an ‘A’ or an ‘A-EP’. I point this out because if you meet the criteria of either of the SAQs but are a Level 1 merchant, you can mark all of the ROC requirements not in the respective SAQ as ‘Not Applicable’ and only provide testing evidence for those requirements in the relevant SAQ.
PCI Guru 