New SAQ A-EP Addresses E-Commerce Merchants Using Payment Redirects

March 7, 2014 • Published Categories Industry Topics Tags , , , , , , , ,

The new PCI DSS version 3.0 Self Assessment Questionnaires (SAQs) are out, and after our initial look, there are some notable differences. This article focuses on the brand new “SAQ A-EP” for “Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing.”

NOTE: After reading this post, be sure to see my June 12, 2014 update here.

Many e-commerce merchants assume that using a hosted payment solution will better secure their online payment transactions and eliminate their own web infrastructure from the scope of the PCI DSS. Historically, those merchants have filled out an SAQ A to validate their compliance. While the SAQ A still exists for version 3.0 and has only nominal changes, many e-commerce merchants will instead be subject to the new  SAQ A-EP. With 139 questions, a required quarterly ASV Scan and a required annual penetration test, this SAQ represents a big departure from the simple SAQ A.

Why the new SAQ A-EP?
Many e-commerce merchants typically host their own website (or utilize any hosting service provider), then outsource just the payment page to a third-party, PCI-compliant service provider. Previously, this configuration allowed the merchant to validate their compliance with the 13-question SAQ A.

With the release of the PCI DSS 3.0, the PCI SSC has rightly pointed out that this common configuration still leaves open vectors for attack, and that merchants must secure their web infrastructure given its ability to impact the security of payment transactions.

For example, let’s assume the merchant hosts their own e-commerce website, but when a consumer makes a purchase, they are directed to a completely different page, hosted by a third-party, PCI-compliant service provider. In this scenario, an attacker could compromise and gain access to the underlying host operating system running the website. Then, they can simply edit the file that causes the user to be directed to the real payment page and have it point to the attacker’s fake payment page.

We heard about this from the PCI SSC at the 2013 RSA conference, and then again at the 2013 PCI Community Meetings.  With the new SAQ A-EP, it is very clear that e-commerce merchants no longer get to validate via the simple SAQ A by using a hosted payment solution.

Who has to use the new SAQ A-EP?
Merchants who fit the following description are eligible for the new SAQ A-EP:

“Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor”

So, if a consumer goes to a merchant’s website, shops, and when it is time to pay, is re-directed to a PCI DSS validated third-party payment processor, then that merchant will be required to validate with the SAQ A-EP.

It is also important to note that e-commerce merchants can no longer validate with an SAQ C.  In fact, e-commerce merchants are specifically excluded from validating with all SAQs except SAQ A, SAQ A-EP or SAQ D-Merchant.

Are any e-commerce merchants still eligible for the short SAQ A?
Yes. A merchant that outsources their whole e-commerce website, including shopping pages and payment page, to a third-party, PCI-compliant service provider host can still use an SAQ A. But my guess is that there are not many e-commerce merchants meeting these criteria.

Will merchants find the differences in eligibility between version 3.0 SAQ A and SAQ A-EP confusing?
It is very likely that many will. If you read just the requirements for the version 3.0 SAQ A, you might think that any e-commerce merchant can still use the SAQ A:

“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).”

However, a careful read of the directions in the SAQ A-EP should correct that misconception:

“SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.”


 “Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;”

What should e-commerce merchants do?
E-commerce merchants should examine their systems or consult with their service providers (hosted payment company, web host, web application developer or security consulting company, like ControlScan) to determine if they meet the criteria for an SAQ A-EP. The 3.0 SAQs will not become required until January, 2015, but given the very large differences between the SAQ A and the SAQ A-EP, merchants may want to begin getting familiar with the new requirements.

The requirements to pay particular attention to are those for scanning and penetration testing:

  • An external PCI ASV scan has to be completed quarterly (requirement 11.2.2). This scan must be completed with an ASV (Approved Scanning Vendor);
  • An internal vulnerability scan must also be run quarterly and after any significant changes in the network environment (requirement 11.2.3); and
  • An external penetration test must be completed at least annually (requirement 11.3).

These scans can detect vulnerabilities that take time to address so that they are removed and a passing scan is achieved. Should you have any questions about this process, please give ControlScan a call at 800-825-3301, ext. 2. We also have related PCI DSS 3.0 articles here.

Leave a Comment