Which PCI SAQ Do I Need? Scenarios & Examples
Real-world scenarios showing exactly which PCI DSS Self-Assessment Questionnaire applies to your business — from e-commerce and retail to SaaS platforms and service providers.
Find your business model below and get a clear SAQ recommendation with an explanation of why it applies.
Why Choosing the Right SAQ Matters
PCI DSS defines nine different Self-Assessment Questionnaire types, ranging from 22 requirements (SAQ A) to 329 requirements (SAQ D). Selecting the wrong SAQ type is one of the most common PCI compliance mistakes — and the consequences extend well beyond wasted effort. An SAQ that is too simple leaves security gaps in your cardholder data environment, while an SAQ that is too comprehensive wastes time and resources on requirements that do not apply to your business.
If a data breach occurs and your acquiring bank or card brand determines you completed the wrong SAQ, you face increased fines, higher liability, mandatory forensic investigations at your expense, and potential loss of card processing privileges. The card brands view an incorrect SAQ determination as evidence that the merchant did not understand their own payment environment — a red flag for inadequate security practices.
The scenarios below map common business models to the correct SAQ type so you can make an informed decision. If your situation does not match any scenario exactly, use the SAQ decision tree or consult a Qualified Security Assessor.
Real-World SAQ Scenarios
I run an online store using Shopify/WooCommerce with hosted checkout
Your customers are redirected to a payment processor's hosted page (like Shopify Checkout, PayPal, or Stripe Checkout) or the payment form is loaded in an iframe entirely controlled by the processor. Your website never handles, processes, or transmits cardholder data. The entire payment experience is hosted by a PCI DSS validated third party.
SAQ A applies because the full redirect or iframe means your server and website code never interact with cardholder data. You only receive a payment confirmation token or order notification after the transaction is complete. This is the simplest SAQ type with approximately 22 requirements.
My e-commerce site has an embedded payment form (JavaScript SDK)
Your checkout page uses a JavaScript SDK from your payment processor (like Stripe.js Elements, Braintree Drop-in, or Adyen Web Components) that renders payment fields directly on your page. While the card data is sent directly from the customer's browser to the processor, your website code controls how those fields are loaded and displayed.
SAQ A-EP is required because your website's JavaScript can affect the security of the payment transaction, even though cardholder data never touches your server. If malicious code were injected into your site, it could potentially intercept card data before it reaches the processor. This SAQ has approximately 191 requirements.
I have a countertop card terminal connected to my POS
Your retail store uses countertop terminals or PIN pads connected to your network via Ethernet or Wi-Fi. Customers swipe, dip, or tap their cards at the terminal. The terminal communicates directly with the payment processor and does not store cardholder data after the transaction is authorized.
If your terminal connects via IP (Ethernet, Wi-Fi, cellular), you need SAQ B-IP (approximately 82 requirements). If it connects via a traditional analog phone line (dial-out only), you qualify for SAQ B (approximately 41 requirements). The key distinction is the connection method — phone-line terminals have a smaller attack surface because they are not on your network.
I take phone orders and key them into a virtual terminal
Your staff receives orders by phone or mail and manually enters card numbers into a web-based virtual terminal provided by your payment processor (such as Authorize.Net Virtual Terminal, Square Virtual Terminal, or PayPal Virtual Terminal). No cardholder data is stored electronically after the transaction is submitted.
SAQ C-VT applies because the virtual terminal is a web-based application hosted by your payment processor — you are simply entering data into their interface via your browser. This SAQ has approximately 79 requirements and focuses on securing the workstation and network used to access the virtual terminal.
I'm a SaaS platform that stores card data for recurring billing
Your application stores cardholder data (even if encrypted) in your own database for purposes like recurring billing, subscription management, or one-click payments. You have direct access to primary account numbers (PANs), even if they are encrypted or tokenized using your own encryption keys.
SAQ D for Merchants is required because you store cardholder data in your environment. This is the most comprehensive SAQ with approximately 329 requirements covering the full PCI DSS standard — including encryption, key management, access controls, network segmentation, logging, and vulnerability management. Consider tokenization through your processor to reduce scope.
I operate a payment gateway or processor
Your organization processes, stores, or transmits cardholder data on behalf of other merchants or entities. You operate as a payment facilitator, payment gateway, hosting provider for payment applications, or any other service provider role in the payment ecosystem.
SAQ D for Service Providers applies because you handle cardholder data on behalf of others. This SAQ has approximately 329 requirements plus additional service-provider-specific controls around multi-tenant isolation, customer data segregation, and service provider responsibilities. Level 1 service providers must undergo a full ROC assessment by a QSA instead.
I use a PCI-validated P2PE device in my retail store
Your retail location uses payment terminals from a PCI-validated Point-to-Point Encryption (P2PE) solution. The terminal encrypts cardholder data at the point of interaction and the decryption environment is managed entirely by the P2PE solution provider. Your organization never has access to cleartext cardholder data.
SAQ P2PE is a simplified assessment with approximately 33 requirements, available only to merchants using a solution that appears on the PCI SSC's list of validated P2PE solutions. This dramatically reduces your compliance burden because the P2PE solution provider takes responsibility for the encryption and decryption of cardholder data.
Common SAQ Selection Mistakes
Choosing SAQ A when you should use SAQ A-EP
This is the most common misclassification. Many merchants believe that because they "don't store card data," they qualify for SAQ A. However, if your website uses a JavaScript-based payment form (Stripe Elements, Braintree Drop-in, etc.) that renders on your page, your website code can affect the security of the transaction. A compromised script on your site could intercept card data before it reaches the processor. These merchants need SAQ A-EP, which has significantly more requirements than SAQ A.
Confusing SAQ B with SAQ B-IP
SAQ B is specifically for standalone, dial-out terminals that connect via analog phone lines. SAQ B-IP covers IP-connected terminals (Ethernet, Wi-Fi, cellular). Many merchants with modern countertop terminals incorrectly select SAQ B, not realizing their terminals connect over their network. The distinction matters because IP-connected terminals introduce network-level risks that dial-out terminals do not have, and SAQ B-IP includes approximately twice as many requirements.
Defaulting to SAQ D when a simpler SAQ applies
Some merchants assume they need the comprehensive SAQ D and spend significant time and resources completing 329 requirements when a simpler SAQ type would suffice. Before defaulting to SAQ D, carefully evaluate your payment architecture against the eligibility criteria for simpler SAQ types. Outsourcing payment processing, using hosted checkout pages, or deploying P2PE terminals can dramatically reduce your SAQ scope and compliance burden.
Not consulting your acquirer before selecting an SAQ
Your acquiring bank has the final authority on which SAQ type you must complete. Some acquirers have specific requirements based on your merchant level, transaction volume, or industry. They may require a more comprehensive SAQ than the minimum suggested by the PCI SSC criteria, or they may accept a simpler assessment based on compensating controls. Always validate your SAQ selection with your acquirer before investing time in the wrong assessment.
Still Not Sure? Consult a QSA
If your payment environment does not clearly match one of the scenarios above, or if you have a complex setup with multiple payment channels, a Qualified Security Assessor (QSA) can evaluate your specific infrastructure and provide authoritative guidance on the correct SAQ type. QSAs are certified by the PCI Security Standards Council and have deep expertise in PCI DSS requirements and their applicability to different business models.
Even if you are fairly confident in your SAQ selection, having a QSA validate your choice provides assurance and can identify scope-reduction opportunities you may have missed. Many businesses discover they can qualify for a simpler SAQ type by making small changes to their payment architecture — such as switching from an embedded payment form to a hosted checkout page.
Learn about QSA assessmentsLet GRCTrack Determine Your SAQ Type
GRCTrack asks the right questions about your payment environment and recommends the correct SAQ type automatically. Then it guides you through every requirement with step-by-step workflows and evidence collection.