Which SAQ is Right For Your Organization?

For most organizations that accept credit cards for payment, compliance with PCI DSS is a necessary evil to keep your bank happy and ensure that money keeps coming in the door. And for compliance purposes, your company is likely being required to complete an SAQ, as only a relatively small percentage of large merchants (or service providers) have to complete a full Level 1 assessment to receive a Report on Compliance (RoC). Nailing down which Self-Assessment Questionnaire (SAQ) is right for your organization can be a confusing process, though. Sometimes your bank will help direct this decision, sometimes a payment brand will tell you which they want you to complete, but for the most part, you’re on your own to make this decision.

While your acquiring bank is ultimately the one that has to accept/approve your SAQ, you may be left to figure out which one fits your business model and payment channels yourself. In many cases, you may need multiple SAQs to fit the different payment channels within your organization. To help demystify some of this process and help organizations understand which SAQ is right for them, we’ve put together this series of blogs explaining what SAQs are used for what payment channels and what the criteria to use each SAQ is. Hopefully, this will help get you on the right path to completing the proper questionnaire (which will in-turn reduce the work required to complete the SAQ) or help you make informed decisions as an organization when you’re looking at modifying payment processes that could impact your PCI compliance status. Of course if you still have questions after reviewing, feel free to reach out at any time and we’d love to help you out!

Available SAQs

We’ll start small and work our way up the SAQs (generally). As we’ve mentioned before, you want to get the best fitting SAQ to reduce your requirements as much as possible, and then limit the scope to just what is required. Let’s dive in:


For an SAQ A, your organization only accepts “card-not-present” transactions via completely outsourced third-parties, i.e. e-commerce or mail order/telephone order. In addition, all payment processing is outsourced to a PCI-compliant third-party payment processor. This means no cardholder data can touch your organizations premises for transmission, storing, or processing.

Get more detail in our blog on SAQ A.


This is a somewhat recently SAQ meant to be a more specific situation for SAQ A. Basically the same premise as above, except the payment fields where a customer is inputting their credit card information is controlled by and hosted on the organization’s website, but this cardholder data is not processed by the organization. Instead, it is directly sent to a third-party payment processor via an API call, for example.

Get more detail in our SAQ A-EP Blog.


This is for organizations that utilize stand-alone dial out terminals which are directly connected to a third-party payment processor via phone line.

Get more detail in our SAQ B Blog.


Again, a more specific case of SAQ B, this is for organizations with stand-alone terminals that are connected to payment processors via the Internet. These terminals have to be segmented from the rest of your internal network and are only permitted to send information outbound to the payment processor.

Get more detail in our SAQ B-IP blog.


Over the last couple years, organizations have started moving to stand-alone card terminals that utilize point-to-point encryption to protect card details while in transit to the payment processor. If your organization utilizes one of the PCI-approved P2PE solutions, you may be eligible to complete this SAQ.

Get more detail in our SAQ P2PE Blog.


You’ll want to look at this SAQ if your organization has a payment application on-premise but uses network segmentation to separate the cardholder data environment (CDE) from the rest of your internal network. This is the best case SAQ if you’ve got an Internet-connected payment application on your network (otherwise, you’re looking at an SAQ D).

Get more detail in this SAQ C guide.


This was created as a subset of C to reduce the number of requirements levied on organizations that are processing payments only through an acquirer, payment processor, or third-party service provider website, as opposed to a custom or on-prem payment application system.

Get more detail in our SAQ C-VT guide.

SAQ D – Merchant

If you’ve gotten this far and you’re a merchant organization, but none of the scenarios above seem to fit, then you’ve come to right place. This is the catch-all for any organization with electronic cardholder data storage or if your payment channels prevent you from using the above SAQs. As you can probably imagine, this SAQ has the most requirements associated with it (> 300) and the biggest implications for your compliance efforts as an organization.

Get more detail in our guide on SAQ-D.

SAQ D – Service Provider

Similarly, if you read through all this thinking, “I’m a Service Provider, not a Merchant” then this is your stop. If you work with other organizations to process payment card information on their behalf or perform any function that could impact the security of cardholder data in any way, you’ll need to complete an SAQ D – Service Provider or full Level 1 assessment with a Report on Compliance (RoC). While you may be able to mark a lot of requirements “Not Applicable”, you are going to have to justify these answers and this can still be a time consuming process, so best to be prepared.

Get more detail in our SAQ D for Service Provider Blog.