PCI DSS Self-Assessment Questionnaire (SAQ): which type do you need?

TL;DR: A PCI DSS SAQ is a validation tool that eligible merchants and service providers use to self-report their PCI DSS compliance, the alternative to a Report on Compliance (ROC) for those an acquirer or payment brand does not require to submit one. Which SAQ you complete is set by how you accept and handle cardholder data, not by your size and not at random: your payment channel, the terminal or integration you use, whether card data touches your own systems, and how much you outsource to compliant third parties. There are 10 current questionnaires, and you match your setup to one against PCI SSC's published criteria, then confirm it with your acquirer.

Every PCI DSS Self-Assessment Questionnaire is a description of one way card data moves through a business, so finding yours means matching how your own systems handle that data to the right description in the PCI SSC SAQ Instructions and Guidelines. That makes the questionnaire a scoping decision before it is a form: you map where card data enters, what it touches, and what a compliant third party handles for you, then scope your cardholder-data environment, answer the questionnaire, complete the accompanying Attestation of Compliance (AOC), and submit both to your acquirer. The PCI Security Standards Council (PCI SSC) and your acquiring bank are the authority on what applies to you, with a Qualified Security Assessor (QSA) for the edge cases; this page helps you read that guidance, not replace it.

The current PCI DSS v4.0.1 set runs to 10 questionnaires. The table below lines them up by how card data is handled, the typical payment channel, and the one condition that most often decides eligibility.

Compare the PCI SAQ types

SAQ A: card-not-present, fully outsourced

PCI DSS SAQ A is for eligible card-not-present merchants, including e-commerce and mail/telephone order, that fully outsource account-data functions to compliant third parties and do not electronically store, process, or transmit account data on their own systems. For e-commerce, a redirect to a provider-hosted payment page or an embedded provider-hosted iframe can qualify when all eligibility criteria are met. PCI SSC's explanation of redirects, iframes, and Direct Post makes the data-flow distinction explicit.

For a merchant webpage embedding a provider's payment form, SAQ A also requires confirmation that the page is protected against relevant script attacks. The merchant can use appropriate protections or obtain the compliant payment provider's confirmation for the solution as correctly implemented. PCI SSC FAQ 1588 limits this particular eligibility condition to embedded forms; it does not apply it to a redirect-only page. That distinction does not remove the other requirements in SAQ A.

SAQ A-EP: partially outsourced e-commerce

PCI DSS SAQ A-EP is for eligible e-commerce merchants that outsource payment processing but supply some or all of the page used to collect payment data, while sending that data directly to the compliant processor. Direct Post is the example PCI SSC uses. The merchant does not electronically store account data, but its payment-page implementation brings more of its website into scope. Having a website that redirects to a payment provider is not, by itself, the dividing line: compare the actual implementation with the current criteria.

SAQ B: imprint or standalone dial-out terminals

PCI DSS SAQ B is for merchants that take card data using only imprint machines and/or standalone, dial-out terminals, and that store no account data electronically. The deciding condition is isolation: the terminals connect to the processor over a phone line and are not connected to the internet or to any other system in the merchant environment. E-commerce is out of scope.

SAQ B-IP: standalone IP-connected terminals

PCI DSS SAQ B-IP is for merchants that use only standalone, PCI-listed approved PTS POI devices connected by IP to their processor, with no electronic storage of account data. The device must be validated to the PTS POI program (which excludes SCRs and SCRPs), isolated from other systems, and able to reach the processor on its own without relying on a computer, phone or tablet. Like SAQ B, it does not cover e-commerce.

SAQ C-VT: web-based virtual terminal

PCI DSS SAQ C-VT is for merchants whose only payment processing is through a web-based virtual payment terminal hosted by a compliant third party. The computing device used to reach it must be isolated in a single location, must not store account data, and must have no card-capture hardware such as an attached card reader. It does not apply to e-commerce.

SAQ C: internet-connected payment application

PCI DSS SAQ C is for merchants that run a payment-application system with an internet connection on the same device or local network, and that store no account data electronically. Separation decides it: the payment application is not connected to any other system, the location stands alone, and any LAN serves a single store. It does not cover e-commerce.

SAQ P2PE: validated point-to-point encryption terminals

PCI DSS SAQ P2PE is for merchants whose payment processing runs only through terminals that are part of a validated, PCI-listed point-to-point encryption (P2PE) solution, with no other electronic account data. The condition that most often decides eligibility in practice is the last one: you must have implemented all of the controls in the solution's P2PE Instruction Manual. It is not for e-commerce.

SAQ SPoC: a card reader plus a phone or tablet

PCI DSS SAQ SPoC is for merchants taking card-present payments only, through a PCI-listed Secure Card Reader-PIN (SCRP) paired with a commercial off-the-shelf (COTS) phone or tablet as part of a validated SPoC (Software-based PIN entry on COTS) solution. Only the validated SPoC components may handle account data, the channel must be isolated from other systems, and you must implement the controls in the SPoC user guide. It does not apply to unattended, mail or telephone order, or e-commerce channels. It is a newer type in the PCI DSS v4.0.1 set, so lists built for earlier versions may not include it.

Check the solution's current status before relying on this route. PCI SSC has announced the SPoC Standard sunset period of May 1 through October 31, 2026. A listed questionnaire is not a guarantee that a particular deployment remains eligible; confirm the transition and validation approach with the solution provider and your acquirer.

SAQ D for merchants: everything the other types do not cover

PCI DSS SAQ D for Merchants applies to merchants eligible for self-assessment that do not meet another SAQ's criteria. It covers the broadest set of applicable requirements and may be appropriate when your own systems store account data. Multiple payment channels do not automatically require a single SAQ D: PCI SSC says separate eligible, adequately segmented channels may use different SAQs, or a single assessment may cover the combined requirements. Confirm the approach with the acquirer or payment brand and document the covered environments. See PCI SSC's multiple-channel guidance.

SAQ D for service providers

PCI DSS SAQ D for Service Providers applies to service providers that a payment brand has defined as eligible to complete a self-assessment. It covers the PCI DSS requirements that apply to service providers, and it is the only SAQ available to them: every other questionnaire is for merchant use. If you are a service provider and eligible to self-assess, this is your questionnaire.

SAQ types are not merchant levels

A SAQ type and a merchant level answer two different questions, and mixing them up is the most common confusion on this topic. Your SAQ type describes how you handle cardholder data, which is what the eligibility criteria above are built on. Your merchant level follows the payment brand's validation program, usually based on annual card transaction volume, and it determines the validation requirements your acquirer holds you to. The payment brands define the levels and your acquirer enforces them, so that question belongs with your acquirer rather than with the criteria on this page. You can find the thresholds in our guide to PCI DSS merchant levels 1 to 4.

How to complete and attest your PCI SAQ

Once you know your type, follow these five steps to complete and submit your SAQ.

1. Confirm the type. Check your environment against the eligibility criteria in the SAQ and in the PCI SSC SAQ Instructions and Guidelines, and confirm this is the right questionnaire before you go further. Treat this as a check you repeat whenever your payment setup changes, not only at renewal, because a change in how card data moves can change which questionnaire applies.
2. Scope your environment. Work out which systems, people and processes make up your cardholder-data environment, including any system that has unrestricted connectivity to the systems that store, process or transmit card data.
3. Assess against the requirements. Evaluate your environment against each PCI DSS requirement that applies to your SAQ, and record a response for each one.
4. Complete all sections, attestation included. Complete the assessment and the accompanying Attestation of Compliance using the current documents for your SAQ type. The attestation records the assessment scope, eligibility, and results; follow the package and submission format your acquirer or payment brand accepts.
5. Submit to your acquirer. Send the SAQ and AOC, along with anything else the recipient requests such as ASV scan reports, to the acquirer or payment brand that manages your compliance, and follow their reporting instructions.

Some types carry validation beyond the questionnaire. SAQ A includes external vulnerability scans by a PCI SSC Approved Scanning Vendor (ASV), at least once every three months, for merchant e-commerce webpages even when payment processing is fully outsourced. PCI SSC FAQ 1604 confirms that both redirect pages and pages with embedded iframes are included. Confirm the applicable scanning scope and reporting instructions with your acquirer; a Qualified Security Assessor can help resolve a genuine scoping edge case.

After you assess, anything you do not yet meet is work for a PCI DSS gap analysis, which shows where you still fall short before you attest.

For each gap, record the requirement, evidence reviewed, responsible owner and check needed to confirm closure. The worked gap-assessment examples show how those fields fit together. Fill them with your applicable PCI DSS requirements and acquirer instructions; SAQ eligibility and validation requirements still come from the relevant PCI SSC and payment-brand rules.

Your eligibility holds only as long as your data flow does

Look at what the eligibility criteria never mention: your revenue, your headcount, or how mature your program is. Every one of them is a statement about data flow, about where card data enters, which systems it touches, and how much a compliant third party handles for you. So the questionnaire you match is a claim about how your systems behave, and the Attestation of Compliance you sign records what was true on the assessment date. What happens to that data flow afterward is a separate question, and it is the one that decides whether the attestation still describes you.

PCI DSS treats scope the same way. Requirement 12.5.2 in PCI DSS v4.0.1 has you document and confirm your scope at least once every 12 months and on any significant change to the environment, which means redrawing your data-flow diagrams and re-identifying every place account data is stored, processed, or transmitted; Requirement 12.5.2.1 sets that confirmation at least once every six months for service providers. The trigger is change, not the calendar, because a data flow can move between attestations.

A script added to an embedded payment page brings SAQ A's script-attack condition into play; a standalone dial-out terminal that gains a network connection leaves the isolation SAQ B depends on; a new channel adds a data flow the last assessment never saw. A retail group that adds a click-to-pay flow on one brand's site, or an insurer that routes a call-center channel through a new virtual terminal, has changed its data flow between one attestation and the next. None of this is a team cutting corners. The model asks for a snapshot of something that does not hold still.

These conditions are not paperwork for its own sake. Eligibility tracks the data flow because the data flow is where the exposure lives: PCI DSS added payment-page script controls in version 4.0, Requirements 6.4.3 and 11.6.1, because an unauthorized script on a checkout page has become a common way card data is stolen from e-commerce sites, often while every other control still reads as compliant. A SAQ that has drifted out of step with the real data flow can be filed on time and still leave that exposure in place.

The annual attestation persists partly because assembling the evidence by hand is expensive, so it happens once and then rests until the next cycle. That is a concession to what the work costs, not a judgment about how often card data flows change. It is also why one organization can owe different SAQs across its parts: a group can have a shared internal function assessed separately as a service provider or fold it into each entity's own assessment, and a subsidiary that handles card data differently from its parent can sit under a different questionnaire. The useful question between attestations is not which SAQ you filed, but whether it still fits the way card data moves today.

How Anecdotes approaches PCI SAQ scoping

Because the questionnaire follows the data flow, keeping your SAQ honest means keeping sight of that flow as it changes, and a data-flow question is one your systems can answer directly. Rather than reconstructing where card data went when an attestation comes due, you can read where it goes now, from the systems that handle it, so a change that affects your scope, such as a new payment channel or a system that starts touching card data, appears in the evidence your team already holds instead of surfacing a year later. For a group running several entities and several frameworks at once, the same evidence answers the question for each part of the business, and one PCI DSS control's records often answer the matching ISO 27001 or SOC 2 requirement without a second collection.

Anecdotes automates the evidence collection behind a PCI DSS program. Its Data Engine brings source records together, and control mapping records where evidence can support requirements across frameworks. Confirm scope and evidence suitability for each use. The platform does not decide which SAQ you owe or act as your assessor: eligibility follows PCI SSC's criteria and the validation program your acquirer or payment brand administers. The scoping decision and attestation stay with your organization; what a live data foundation adds is the confidence that the scope you signed is still the scope you run.

Frequently asked questions

What is a PCI DSS SAQ?

A PCI DSS SAQ is a validation tool that eligible merchants and service providers use to perform and report the results of their own PCI DSS self-assessment, rather than submitting a Report on Compliance (ROC). The PCI Security Standards Council defines each questionnaire and its eligibility criteria, and your acquirer or payment brand confirms whether you may self-assess at all.

How do I know which PCI SAQ type I need?

It comes down to how you accept and handle cardholder data: the payment channel you use, the terminal or integration behind it, whether card data ever touches your own systems, and how much you outsource to compliant third parties. Match that setup to a type using the PCI SSC SAQ Instructions and Guidelines, and confirm any edge case with your acquirer or a QSA.

How many PCI SAQ types are there?

The current PCI DSS v4.0.1 set runs to 10 questionnaires: SAQ A, A-EP, B, B-IP, C-VT, C, P2PE and SPoC for merchants, plus SAQ D in a merchant version and a service-provider version. Each one maps to a specific way of handling cardholder data, which is why there is more than one.

What is the difference between SAQ A and SAQ A-EP?

For e-commerce, SAQ A can fit a provider-hosted payment page reached by redirect or embedded in an iframe, provided the merchant meets all eligibility conditions. SAQ A-EP covers implementations such as Direct Post, where the merchant supplies payment-collection page elements and the browser sends card data to the processor. Do not decide from the words “redirect” or “outsourced” alone; inspect where the collection elements originate and where the data flows.

Is the SAQ the same as a PCI DSS merchant level?

No. Your SAQ type describes how you handle card data; your merchant level follows the payment brand's validation program and determines your validation path, which your acquirer enforces.

Who has to complete a PCI DSS SAQ?

Merchants and service providers whose acquirer or payment brand allows self-assessment, rather than requiring an assessor-led Report on Compliance, complete the SAQ that matches how they handle card data. Your acquirer confirms whether self-assessment applies to you and which questionnaire to use. SAQ D for Service Providers is the only SAQ available to service providers.

‍