SAQ A v2.0 vs. SAQ A v3.0 Eligibility Criteria

Now that PCI SSC has released the updated version of Self Assessment Questionnaires, I would like to share my opinion on the SAQ A v3.0 and SAQ A-EP 3.0.

The initial impression was that the SAQ A v3.0 and SAQ A-EP v3.0 will have a major impact on the Payment Card Industry as both introduce a more stringent eligibility criteria (SAQ A v3.0) and by far more applicable PCI DSS requirements (SAQ A-EP 3.0). In fact, SAQ A-EP covers almost the same requirements as SAQ C. However, after careful review of the eligibility criteria of SAQ A v2.0, SAQ A v3.0 and SAQ A-EP v3.0, and the actual impact the SAQ A-EP v3.0 will have on the merchants, the change is not that drastic.

Lets take a look at the eligibility criteria for the SAQ A 3.0 and compare it to the SAQ A 2.0; Aside from implying that third party provides have to be PCI DSS validated (“compliant” is no longer acceptable), the additional criteria includes:

• All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;
• Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;

Additionally, for e-commerce channels:

• 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 merchants that are accepting payment information as mail/telephone-order only, the impact is minimal. For e-commerce channel, and that SAQ A-EP 3.0 comes into play as well, the difference can be summarized in one word: hosting – who is hosting the web site (and the payment pages). Moreover, I can see some merchants successfully argue that the “traditional” redirection to a hosted payment provider, exactly what SAQ A-EP 3.0 qualifies for, still eligible to validate compliance using SAQ A 3.0.

For the sake of argument, lets consider a typical scenario whereby a merchant self-host an e-commerce web server which redirects to a third-party payment provider. Are all payment acceptance and processing are outsourced to a PCI DSS validated third-party service providers? Yes. Is the merchant has no direct controls of the manner in which cardholder data is captured, processed, transmitted, or stored? Yes, it is all taken care of by a third-party payment processor. Are all payment pages delivered to the consumers' browser originate directly from a third-party PCI DSS validated service provider(s)? Here, if we define payment pages as web pages where cardholder data is entered by a consumer, then the answer is still yes.

We can also define “all payment pages” as the entire e-commerce data flow (i.e. the entire e-commerce web site) which, potentially, disqualifies the merchant from validating compliance using SAQ A v3.0. However, if we slightly change the scenario and the web server is hosted by a PCI DSS validated service provider (i.e. Amazon AWS). Now, both the e-commerce pages and the payment web pages are originate directly from a third-party PCI DSS validated service provider(s).

So what is the intent of the choice of words and the additional requirements of the SAQ A v3.0? Is it to force merchants to use validated third-party service providers and to force merchants to migrate to a hosted (again, by validated third-party service providers) solutions? The alternative is, arguably, to comply with comprehensive SAQ A-EP v3.0.