PCI Compliance SAQ-A-EP or SAQ D

Question

Our eCommerce wesbite attracts less than 5000 CC transactions each year and we do no store any CC information in our backend or systems but transmit them to our third party provider. We also use a tokenization technique for recurrent billing. We accept CC information on our secured hosted page but trasnmit them through SSL to our third party payment provider.

I would like to know if we can still use SAQ A-EP questionnaire or we still do need to fill out SAQ-D because we do not use iFrame. Also to note that we only store the Billing token that is provided by the payment provider.

Answer 1

IANAQSA, and all quotes from Understanding SAQs for PCI DSS version 3:

Based on the information you've provided, you'd be a SAQ D.

SAQ A and A-EP are ruled out for you because they can have "no electronic storage, processing, or transmission of any cardholder data on the merchant's systems". When you say

We accept CC information on our secured hosted page but trasnmit them through SSL to our third party payment provider

That tells me you're transmitting cardholder data. I'm interpreting "secured hosted page" as "a web page on a web server you manage which is secured with SSL"; correct me if you mean otherwise.

SAQ B, B-IP, C-VT, C, and P2PE-HW are "Not applicable to e-commerce channels", which would appear to rule out your "eCommerce website". So, yeah, SAQ D applies as you're a "merchant not included in descriptions for the [other] SAQ types"

The fact that you "use a tokenization technique" and "only store the Billing token that is provided by the payment provider" does reduce the amount of work the SAQ D implies. To quote the Guidance for Non-Applicability of Certain, Specific Requirements in SAQ D:

While many organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply..... an organization that does not store any cardholder data electronically at any time would not need to validate requirements related to secure storage of cardholder data (for example, Requirement 3.4).