PCI Compliance – Completing an SAQ A-EP
As we continue to discuss the different types of Self-Assessment Questionnaires (SAQs) within PCI, we’re continuing with some of the smaller SAQs from a requirements and scope perspective. SAQ A-EP is interesting and a little different from the SAQs we’ve discussed previously because it is a subset or special case of SAQ A. It’s also one of the most commonly confused or misused SAQs, from what I’ve seen, because of the special circumstances around it. It might be helpful to review our write-up of the SAQ A here before diving into this one because we’ll be comparing and contrasting the two.
What Organizations Can Use This SAQ
An organization that wants to use SAQ A-EP has to be a merchant (not a service provider) that uses an e-commerce platform. This e-commerce payment channel has to be partially outsourced to a PCI DSS validated third party, such that a client could enter cardholder data into a form on the website that your organization controls, but your organization doesn’t actually store, process, or transmit any cardholder data on their systems. Once entered, this data is immediately and directly sent to the PCI DSS validated third party for payment processing. This may still be confusing (and anyone that has worked with PCI for a long time could still get into an argument about what does or doesn’t apply to this SAQ) so let’s look at an example.
If you’re an organization that accepts payments on their Internet-facing website directly from customers, this is an e-commerce payment channel. If this is the only way you accept payments, you’re going to be using an SAQ A or A-EP. If, during the payment process, the customer is redirected to PayPal to enter their credit card information and complete the purchase transaction, this would fall into an SAQ A. No part of the payment process can be affected by the organization’s primary website, as it’s simply a full redirect, and all elements of the payment page delivered to the customer’s browser originate only and directly from your service provider. Now let’s say instead of simply redirecting to a PayPal page that pops-up for your users, you accept a customer’s payment information on form fields of your website, but then shoot that to PayPal via a direct API call using JavaScript. That payment information is never hitting your organization’s systems/premises, but the security of your e-commerce website could affect the delivery of that cardholder data to the payment processor, making this scenario an SAQ A-EP.
What Does it Take to Complete an SAQ A-EP?
For your company to complete an SAQ A-EP, you’ve got to confirm for the applicable payment channel that:
- You’re only accepting e-commerce payments and you don’t electronically store, process, or transmit cardholder data on your systems
- All service providers that store, process, or transmit cardholder data on your behalf are PCI DSS compliant
- Besides the payment page where a customer is entering in payment information, all other processing of cardholder data is outsourced (to a PCI DSS validated third-party, of course)
- Your web server does not receive cardholder data, but your website does control how customers’ cardholder data is sent to your payment processor
- Your website hosting provider (if applicable) is PCI DSS validated
- All elements of the payment page originate from your website or a PCI DSS compliant service provider
- If you do retain any cardholder data, it must be on physical paper and never received electronically
