Further Clarification on SAQ A Updates: Guidance for Requirements 6.4.3 and 11.6.1

Recently two requirements that were part of SAQ A were removed, namely PCI DSS 6.4.3 and 11.6.1.

What Was the Change SAQ A?

Both of these requirements were specifically targeting the prevention of skimming credit card data from 3rd party hosted iframes used to enter card data during an e-commerce purchase process on a merchants website.

These two requirements were replaced with a modified eligibility criteria statement added to the new SAQ A referring to the merchants responsibility for securing their referring payment page against script attacks. Because many entities were having a hard time understanding the implications of the wording of the eligibility criteria, an FAQ was released recently to help clarify the meaning of that statement.

Questions About the SAQ A Changes

So, here are some of my thoughts on FAQ 1588 and how it clarifies the SAQ A eligibility criteria statement (shown below): "The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s). "

Some questions we have heard previous to the FAQ release:

What is the meaning of the word “site” in this statement? Did the scope change all of a sudden from the payment page to my whole web site?
As a merchant how can I confirm that elements provided to me by a TPSP are not “susceptible to attacks from scripts” contained on my payment page?
What are the “merchant’s e-commerce systems” mentioned in the statement?

PCI Council’s Response to the SAQ A Changes

The PCI Council hopes to clear up these questions with the release of this FAQ. Here is how I see the FAQ has helped:

FAQ 1588 clarified that the reference to “site” in the SAQ A eligibility criteria means the webpage that includes a payment element provided to a merchant by the TPSP, for example an iFrame.

What Does the SAQ A Changes Mean?

So, the eligibility criteria did not increase the scope of script security to the merchants entire website, it is still just scripts that exist on that referring payment page (the page that contains the TPSP iframe element). I also feel that the FAQ clarifies that the “merchants e-commerce systems" are those payment element(s) provided by a TPSP.

FAQ 1588 clarified that there are basically two ways to confirm that elements on your referring payment page are not susceptible to script attack:

Basically comply to the original requirements that were removed from SAQ A, those being PCI DSS 6.4.3 and 11.6.1, or,
The merchant can confirm that the TPSP providing the embedded payment element/form/iframe is providing those script attack protections on behalf of the merchant.
In other words, the TPSP is signing up for the risk of protecting their payment element from any script attacking from the merchant's referring payment page. Essentially then, the TPSP would be satisfying the eligibility criteria (or meeting 6.4.3 and 11.6.1) for the merchant and would then be potentially responsible if an attack was successful and card data lost from their provided element.

Other Options to Requirement 6.4.3 and 11.6.1

Let’s talk about that second point for a bit.

From the perspective of a merchant then, you would want to see a direct statement in the form of a provided responsibility matrix (that is a document showing exactly what requirements the TPSP is handling in the merchants behalf), or a clear statement written on the TPSP's website, or perhaps written in contract language clearly stating that the TPSP takes the responsibility of meeting SAQ A's eligibility criteria (or meeting 6.4.3 and 11.6.1 directly) for you the merchant.

Of course, all of this would be dependent on the merchant following any implementation guidance provided by a TPSP for their script security solution.

Conclusion

From a QSA's perspective working on a validated SAQ, I would want to see the TPSP statement(s) collected by the Merchants to clearly confirm the TPSP is taking on this responsibility of script protection for the merchant.