SAQ Selection Guide
Choosing the Right Self-Assessment Questionnaire
The SAQ you select determines the scope, effort, and cost of your PCI DSS compliance programme. There are nine SAQ types, each designed for a specific payment environment. Selecting the wrong one means wasted effort at best and a failed assessment at worst. This guide explains every SAQ type, who qualifies, and how to determine the right one for your organisation.
What Are Self-Assessment Questionnaires?
A Self-Assessment Questionnaire (SAQ) is a validation tool defined by the PCI Security Standards Council (PCI SSC) that allows merchants and service providers to self-report their compliance with PCI DSS. Rather than requiring a full on-site audit by a Qualified Security Assessor (QSA), SAQs let organisations assess themselves against a subset of PCI DSS requirements appropriate to their specific payment environment.
Who needs to complete an SAQ? Level 2, 3, and 4 merchants — those processing fewer than 6 million card transactions annually — typically validate compliance through an SAQ rather than a Report on Compliance (ROC). Some Level 1 merchants may also use an SAQ with explicit acquirer agreement, though this is uncommon. Service providers processing, storing, or transmitting cardholder data on behalf of other entities must also validate compliance, either through an SAQ D for Service Providers or a full ROC depending on their transaction volume and payment brand requirements.
Each SAQ type contains a different number of questions, ranging from approximately 22 for SAQ A to over 300 for SAQ D. The type you need depends entirely on how you accept and handle card payments. Understanding your payment architecture is therefore the essential first step. If you are unsure of your merchant level, determine that before proceeding with SAQ selection.
Card-Not-Present SAQ Types
Card-not-present (CNP) merchants — those who accept payments online, by phone, or by mail without physically handling a card — have several SAQ options depending on how their payment processing is integrated.
SAQ A — Fully Outsourced Payment Processing
SAQ A is the simplest and shortest SAQ, containing approximately 22 questions. It is designed for merchants who have completely outsourced all payment processing to PCI DSS-validated third-party providers and have no direct control over how cardholder data is captured, processed, or stored.
Eligibility criteria (all must be met):
- Your organisation does not electronically store, process, or transmit any cardholder data on your systems or premises.
- All payment processing is entirely outsourced to PCI DSS-validated third-party service providers.
- For e-commerce: customers are redirected to the payment provider's website or the payment form is loaded via iframe from the provider's domain. Your website does not serve any payment form elements.
- For mail/telephone order: card data is entered directly into the third-party provider's system, not into your own systems.
- You retain only paper reports or receipts with cardholder data, and these are not received electronically.
- Your company has confirmed that all third-party providers handling cardholder data are PCI DSS compliant.
Common examples: E-commerce sites using Stripe Checkout (redirect mode), PayPal Standard hosted buttons, Adyen's hosted payment page, or Square Online checkout. Also applies to telephone-order businesses entering card details directly into a payment provider's web portal.
SAQ A is the target for most small to mid-size merchants because it minimises compliance burden. If you are building a new e-commerce site, designing for SAQ A eligibility from the start is the single most impactful decision you can make. For detailed e-commerce integration guidance, see the PCI for E-Commerce guide.
SAQ A-EP — E-Commerce with Payment Page Influence
SAQ A-EP applies to e-commerce merchants who outsource payment processing but whose websites control or influence the security of the payment transaction. This SAQ contains approximately 139 questions — significantly more than SAQ A — reflecting the additional risk your web infrastructure introduces.
Eligibility criteria (all must be met):
- All payment processing is outsourced to a PCI DSS-validated third party.
- Your website does not receive cardholder data but does affect the security of the payment transaction — for example, by serving the page that contains the payment provider's JavaScript or by using a direct post form.
- Your systems do not electronically store, process, or transmit cardholder data.
- You have confirmed that all third-party providers handling cardholder data are PCI DSS compliant.
- E-commerce is your only payment channel (no card-present transactions).
Common examples: Merchants using JavaScript-based payment libraries where the payment form HTML is served from their own domain (e.g., custom Stripe Elements implementations where your page hosts the form container), or direct post integrations where your page's form action URL sends data to the payment provider.
The distinction between SAQ A and SAQ A-EP hinges on whether your website could be compromised to intercept payment data. If an attacker could modify your payment page to redirect card data, you need SAQ A-EP. Under PCI DSS v4.0.1, this includes complying with Requirement 6.4.3 (payment page script management) and Requirement 11.6.1 (tamper detection), which are now mandatory.
Card-Present and Terminal SAQ Types
Merchants who accept card payments through physical terminals have four SAQ options, distinguished by the terminal type and network connectivity.
SAQ B — Imprint-Only or Standalone Dial-Out Terminals
SAQ B contains approximately 41 questions and applies to merchants using imprint machines or standalone dial-out terminals that connect via telephone line (not IP). These are the oldest and simplest forms of card acceptance.
Eligibility criteria:
- You use only imprint machines and/or standalone dial-out terminals (connected via phone line to the processor).
- Standalone dial-out terminals are not connected to the internet or any other systems in your environment.
- You do not store cardholder data in electronic form.
- You do not have an e-commerce channel.
SAQ B is increasingly rare as most merchants have moved to IP-connected terminals, but it remains relevant for some small retail or hospitality businesses using legacy equipment.
SAQ B-IP — Standalone IP-Connected PTS POI Terminals
SAQ B-IP contains approximately 82 questions and applies to merchants using standalone, PTS-approved point-of-interaction (POI) terminals connected to the payment processor via IP (internet). The terminal must be on the PCI SSC's list of validated PTS devices.
Eligibility criteria:
- You use only standalone PTS-approved POI terminals connected via IP to the payment processor.
- The terminals are not connected to any other systems in your environment (network segmentation from the rest of your LAN).
- You do not store cardholder data in electronic form.
- You do not have an e-commerce channel.
The key distinction from SAQ B is the IP connectivity, which introduces network-level risks requiring additional controls around network segmentation, firewall configuration, and terminal software management.
SAQ C-VT — Virtual Terminal Merchants
SAQ C-VT contains approximately 79 questions and applies to merchants who manually enter a single card transaction at a time into a web-based virtual terminal provided by their payment processor. This is common for telephone order businesses.
Eligibility criteria:
- You process transactions one at a time via a virtual terminal accessed through a web browser.
- The virtual terminal is provided and hosted by your PCI DSS-validated third-party service provider.
- The virtual terminal is accessed via a computer isolated from other systems in your environment (or your entire network is flat but only the virtual terminal workstation handles card data).
- You do not store cardholder data in electronic form.
- You do not have an e-commerce channel.
Important distinction: SAQ C-VT applies when a human operator manually types card numbers into the provider's web-based virtual terminal. If you have built your own application that interfaces with a payment API, that is not a virtual terminal scenario and you likely need SAQ C or SAQ D.
SAQ C — Payment Application Systems Connected to the Internet
SAQ C contains approximately 160 questions and applies to merchants with payment application systems (such as a point-of-sale system) connected to the internet that process cardholder data but do not store it electronically after authorisation.
Eligibility criteria:
- Your payment application system is connected to the internet for payment processing.
- The payment application system is not connected to any other systems within your environment (i.e., it is segmented).
- The physical POS terminal/device is not connected to other devices in your environment.
- You do not store cardholder data in electronic form.
- You do not have an e-commerce channel.
SAQ C covers a broader set of scenarios than SAQ B-IP and includes software-based POS systems. The requirement for network segmentation is strict — the payment application system must be isolated from the rest of the merchant's network.
SAQ P2PE — Validated Point-to-Point Encryption
SAQ P2PE contains approximately 33 questions and applies to merchants using only PCI SSC-validated Point-to-Point Encryption (P2PE) solutions. P2PE encrypts cardholder data at the terminal, and the merchant has no ability to decrypt it — decryption occurs only at the payment processor's secure environment.
Eligibility criteria:
- All payment processing is through hardware payment terminals included in a PCI SSC-listed P2PE solution.
- You do not have access to cleartext cardholder data and do not have the ability to decrypt it.
- You do not store cardholder data in electronic form other than what is encrypted by the P2PE solution.
- You have verified that the P2PE solution is listed on the PCI SSC's approved P2PE solutions list.
- You do not have an e-commerce channel.
SAQ P2PE is attractive because of its small question count, but it requires using a validated P2PE solution — not simply a terminal that claims to encrypt data. Check the PCI SSC website for the current list of validated solutions. The investment in P2PE-approved hardware often pays for itself through reduced compliance scope. For a deeper look at how P2PE and other strategies reduce your CDE, see the CDE Scoping Tool and the Scope Calculator.
SAQ D — The Full Self-Assessment
SAQ D is the most comprehensive self-assessment questionnaire, containing over 300 questions that cover all 12 PCI DSS requirements. There are two variants: SAQ D for Merchants and SAQ D for Service Providers. If your organisation does not meet the eligibility criteria for any of the preceding SAQ types, SAQ D is your default.
SAQ D for Merchants
SAQ D for Merchants applies to any merchant that does not qualify for another SAQ type. Common scenarios include:
- Merchants who store cardholder data electronically (even if encrypted).
- Merchants who process cardholder data on their own servers (server-side payment processing).
- Merchants with multiple payment channels where no single simplified SAQ covers all channels.
- E-commerce merchants whose payment integration does not qualify for SAQ A or SAQ A-EP.
Completing SAQ D is a significant undertaking. It requires documenting compliance across network security, access controls, encryption, vulnerability management, logging, monitoring, physical security, and information security policy. Most organisations completing SAQ D benefit from using a compliance platform to track progress and manage evidence — attempting to manage 300+ controls in spreadsheets is error-prone and difficult to maintain year over year.
SAQ D for Service Providers
SAQ D for Service Providers applies to service providers eligible for self-assessment (typically those processing fewer than 300,000 transactions annually for Visa, though thresholds vary by payment brand). This variant includes additional requirements specific to service providers, such as:
- Acknowledging responsibility for the security of cardholder data they possess or otherwise store, process, or transmit on behalf of customers.
- Providing a written agreement with customers acknowledging the service provider's PCI DSS responsibilities.
- Supporting customers' requests for information about the service provider's PCI DSS compliance status.
- Additional cryptographic and key management requirements.
Service providers above certain transaction thresholds must complete a full ROC with a QSA rather than self-assessing. Check with your payment brand partners to confirm whether you qualify for SAQ self-assessment. If you need a QSA, the QSA Directory can help you find an assessor with relevant experience.
SAQ Decision Tree
Work through these questions in order to identify your SAQ type. Answer each question for every payment channel your organisation uses. If different channels qualify for different SAQs, you either complete multiple SAQs or default to the most comprehensive one (typically SAQ D) — consult your acquirer for guidance.
1. Do you store cardholder data electronically?
Yes → SAQ D. If you store PANs, even encrypted, in your own database or file system, you need SAQ D. Consider implementing tokenisation to eliminate electronic storage and qualify for a simpler SAQ.
2. Does cardholder data pass through your servers?
Yes → SAQ D. If your server receives card numbers at any point (even temporarily), you need SAQ D. Redesign to use client-side tokenisation or hosted payment pages to reduce scope.
3. Do you accept payments exclusively via validated P2PE terminals?
Yes → SAQ P2PE (~33 questions). Confirm your solution appears on the PCI SSC validated P2PE list. If it is "point-to-point encryption" but not PCI-validated, it does not qualify.
4. Do you only use imprint machines or standalone dial-out (phone line) terminals?
Yes → SAQ B (~41 questions). No internet connectivity, no electronic cardholder data storage, no e-commerce.
5. Do you only use standalone IP-connected PTS-approved terminals?
Yes → SAQ B-IP (~82 questions). The terminal must be PTS-listed, segmented from your network, and you must not store CHD electronically.
6. Do you only use a virtual terminal from your payment provider to key in one transaction at a time?
Yes → SAQ C-VT (~79 questions). Must be the provider’s hosted virtual terminal, not your own application. No e-commerce.
7. Do you use a payment application connected to the internet but store no CHD electronically?
Yes → SAQ C (~160 questions). The payment application must be segmented from other systems. No e-commerce.
8. Is your e-commerce payment fully outsourced (redirect or iframe from provider’s domain)?
Yes → SAQ A (~22 questions). Your website must not serve any payment form elements. The entire payment interaction occurs on the provider’s infrastructure.
9. Does your e-commerce website serve the page containing the payment form or load payment provider JavaScript?
Yes → SAQ A-EP (~139 questions). Your page influences the security of the payment transaction even though card data goes to the provider.
For an interactive version of this decision tree, use the SAQ Decision Engine, which walks you through the selection in under two minutes and provides a personalised recommendation with next steps.
Common SAQ Selection Mistakes
SAQ selection errors are among the most costly mistakes in PCI DSS compliance. An incorrect SAQ means you are either answering unnecessary questions or, more dangerously, missing critical controls that apply to your environment. Here are the mistakes assessors see most frequently.
Claiming SAQ A When You Host Payment Form Elements
This is the most common error for e-commerce merchants. If your website serves any part of the HTML that collects card data — even if the data is then sent directly to a third-party processor — you do not qualify for SAQ A. The fact that card data "never touches your server" is not sufficient. If a compromise of your website could allow an attacker to intercept card data (by injecting a malicious script, for example), your site influences the payment transaction security and you need SAQ A-EP at minimum.
Selecting the Wrong SAQ for Mixed Payment Channels
Many merchants accept payments through multiple channels: e-commerce, in-store terminals, and telephone orders. Each channel may qualify for a different SAQ type. You cannot simply pick the simplest one. If your e-commerce qualifies for SAQ A and your terminals qualify for SAQ B-IP, you must complete both SAQs — or you may be directed by your acquirer to complete SAQ D to cover all channels. Discuss multi-channel scenarios with your acquiring bank before starting any assessment.
Assuming "Encryption" Equals P2PE
Many terminal vendors market their products as providing "point-to-point encryption" or "end-to-end encryption." However, SAQ P2PE requires a solution validated and listed by the PCI SSC. A terminal that encrypts data is not the same as a PCI-validated P2PE solution. Before selecting SAQ P2PE, verify your exact solution on the PCI SSC's validated P2PE solution list. If it is not listed, you do not qualify for SAQ P2PE and likely need SAQ B-IP or SAQ C depending on your configuration.
Ignoring Electronic Cardholder Data Retention
Several SAQ types require that you do not store cardholder data electronically. This is stricter than it sounds. If your payment application, CRM, helpdesk system, email server, or call recording system retains PANs or other cardholder data in any electronic form, you may fail this eligibility criterion. Audit all systems thoroughly — card data often ends up in unexpected places such as log files, email inboxes, support tickets, and CSV exports. Use the CDE Scoping Tool to identify all systems that may contain cardholder data.
Not Confirming with Your Acquirer
Your acquiring bank has final authority over which SAQ you must complete. Some acquirers have stricter policies than the PCI SSC's baseline guidance — for instance, requiring SAQ D for merchants above a certain transaction volume even if they technically qualify for a simpler SAQ. Always confirm your SAQ selection with your acquirer before investing time in the assessment. Submitting the wrong SAQ type will result in rejection and wasted effort.
SAQ Quick Reference
Use this reference to compare all SAQ types at a glance. For a personalised recommendation, run through the SAQ Decision Engine. To estimate the cost and timeline for your SAQ type, use the PCI Cost Calculator and review the First PCI Assessment guide for preparation steps.
| SAQ Type | Questions | Primary Use Case | E-Commerce? |
|---|---|---|---|
| SAQ A | ~22 | Fully outsourced payment processing (redirect, iframe) | Yes |
| SAQ A-EP | ~139 | E-commerce page influences payment security | Yes |
| SAQ B | ~41 | Imprint or standalone dial-out terminals | No |
| SAQ B-IP | ~82 | Standalone IP-connected PTS POI terminals | No |
| SAQ C-VT | ~79 | Provider-hosted virtual terminal (manual key entry) | No |
| SAQ C | ~160 | Payment application connected to the internet | No |
| SAQ P2PE | ~33 | PCI-validated P2PE solution only | No |
| SAQ D (Merchant) | ~300+ | All other merchants | Varies |
| SAQ D (SP) | ~300+ | Service providers eligible for self-assessment | Varies |
Once you have identified your SAQ type, the next step is understanding the specific PCI DSS requirements that apply. Generate a tailored checklist with the PCI Compliance Checklist Generator, and if your SAQ type is D, consider engaging a QSA for guidance even if a full ROC is not required — the complexity of SAQ D makes expert input valuable.
Find Your SAQ Type in Under 2 Minutes
GRCTrack's SAQ Decision Engine determines your SAQ type, generates a personalised compliance checklist, and connects you with QSAs who specialise in your assessment type.