PCI DSS SAQ Guide: Which Questionnaire Fits Your Setup

Q: What is a PCI DSS SAQ?

A PCI DSS SAQ (Self-Assessment Questionnaire) is the validation tool that lets eligible merchants and service providers assess their own PCI DSS compliance instead of hiring a Qualified Security Assessor for a full Report on Compliance. Each SAQ type covers only the requirements that apply to a specific way of accepting cards. You answer every question, then sign an Attestation of Compliance (AOC) and submit both to your acquirer or payment brand.

Q: How many SAQ types are there?

Under PCI DSS v4.0.1 there are ten questionnaires: SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC, and D, which comes in two versions (one for merchants, one for service providers). All of them except SAQ D for Service Providers are for merchants only. A service provider that is eligible to self-assess always uses SAQ D for Service Providers.

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

Both apply to e-commerce merchants that outsource card processing. The difference is who controls the payment page. With SAQ A, the entire payment form is served by a PCI DSS compliant third party, through a redirect or an iframe. With SAQ A-EP, your website controls part of the flow, for example by rendering the form fields itself or posting card data straight from your page to the processor. That control puts your web server in scope, so SAQ A-EP carries a much larger set of requirements.

Q: Who decides which SAQ I complete?

Your acquirer (the bank that processes your card payments) or the payment brands. They set your merchant level, decide whether you may self-assess at all, and can require a specific SAQ or a Report on Compliance instead. The eligibility criteria printed at the front of each SAQ tell you which one fits your setup, but the acquirer has the final say. Ask them in writing before you start.

Q: Does SAQ A require ASV scans?

Yes, in most e-commerce cases. PCI DSS v4 added quarterly external vulnerability scans by an Approved Scanning Vendor (Requirement 11.3.2) to SAQ A for merchants whose website redirects to, or embeds, a third-party payment page. The scans cover the web server that hosts that page or link, because an attacker who controls it can swap the redirect or the iframe for a fake one.

Q: What happens if I complete the wrong SAQ?

Your attestation does not match your real environment, so you are not actually compliant, even with a signed AOC on file. The gap usually surfaces after a breach, when a forensic investigation compares your card data flow to what you attested. At that point the controls you skipped are the ones investigators look for, and liability for the breach costs can land on you rather than on your processor.

A PCI DSS SAQ (Self-Assessment Questionnaire) is how most merchants and smaller service providers prove they meet the Payment Card Industry Data Security Standard without paying for a full on-site audit. There are ten of them, each written for one specific way of taking card payments, and picking the right one is the most consequential decision in your whole PCI program.

This guide walks through every SAQ type, the 2025 change to SAQ A, and a simple decision path for choosing yours. If you are still working out whether PCI DSS applies to you at all, start with our PCI DSS compliance guide.

What a PCI DSS SAQ Actually Is

PCI DSS has twelve requirements and several hundred sub-requirements. Not all of them apply to every business. A merchant that never touches a card number has very little to protect, while a merchant that stores card data has a great deal.

The SAQ is the PCI Security Standards Council's answer to that difference. Each questionnaire is a filtered view of PCI DSS that keeps only the requirements relevant to one payment setup. You answer each question with "In Place," "In Place with CCW" (a compensating control), "Not Applicable," "Not Tested," or "Not in Place."

Every SAQ ends with an Attestation of Compliance (AOC). That is the signed statement your acquirer actually files. The questionnaire is the evidence behind it.

SAQ vs Report on Compliance

Not everyone may self-assess. The largest merchants and service providers must have a Qualified Security Assessor (QSA) perform an audit and produce a Report on Compliance (ROC) instead. Your merchant level, set by transaction volume, decides which path you are on:

Level 1 merchants (over 6 million transactions a year for a single card brand) complete a ROC.
Levels 2 through 4 usually complete an SAQ, though your acquirer can require more.
Service providers follow separate thresholds. Under Visa's program, a service provider handling more than 300,000 transactions a year is Level 1 and needs a ROC.

Everything below applies to the organizations that are allowed to self-assess.

The PCI DSS SAQ Types, One by One

Each SAQ has an eligibility section at the front. You must meet every criterion listed to use it. If you fail any single one, you move to a larger questionnaire.

SAQ A: Fully Outsourced, Card-Not-Present

For e-commerce and mail or telephone order merchants that have outsourced all card handling to a PCI DSS compliant third-party service provider. Card data is never stored, processed, or transmitted electronically on your systems.

In practice, this means a full redirect to a hosted payment page, or payment fields served entirely inside the processor's iframe. Hosted checkouts and iframe-based field libraries from the major processors are built to land you here.

SAQ A is the shortest questionnaire, and for almost every SaaS company it is the target.

SAQ A-EP: E-Commerce With a Partly Controlled Payment Page

For e-commerce merchants that outsource processing but whose website controls how card data reaches the processor. Typical examples are a JavaScript form rendered by your own page, or a "direct post" form that sends card data from the browser straight to the processor.

Your servers never store the card number. But because your page builds the form, an attacker who compromises your site can skim cards. So your web environment comes into scope, and SAQ A-EP includes a large share of the full PCI DSS requirements.

SAQ B: Imprint Machines and Dial-Out Terminals

For merchants that take cards only through manual imprint machines or standalone terminals connected by phone line. No electronic card data storage. This is rare today.

SAQ B-IP: Standalone IP-Connected Terminals

For merchants using standalone, PCI-approved payment terminals that connect to the processor over IP. The terminals must not be connected to any other system in your environment.

SAQ C-VT: Virtual Terminal Only

For merchants that key card details by hand into a processor's web-based virtual terminal. The computer used must be isolated and used only for that purpose, and no card data is stored electronically.

SAQ C: Payment Application Connected to the Internet

For merchants with a payment application system (such as a point-of-sale system) connected to the internet, with no electronic card data storage. The scope is larger because the payment application sits on your network.

SAQ P2PE: Validated Point-to-Point Encryption

For merchants that accept card-present payments only through hardware terminals that are part of a PCI-listed, validated P2PE solution. The card is encrypted inside the terminal, so your network never sees readable data. SAQ P2PE is short, but only if the solution is on the PCI SSC's list and you follow its implementation manual.

SAQ SPoC: Software-Based PIN Entry on COTS

For merchants using a commercial off-the-shelf device, such as a phone or tablet, with a secure card reader that is part of a PCI-listed Software-based PIN entry on COTS (SPoC) solution.

SAQ D for Merchants

For every merchant that does not qualify for any other SAQ. That includes anyone who stores card data electronically. SAQ D covers all applicable PCI DSS requirements, which in practice means a full security program.

SAQ D for Service Providers

The only SAQ a service provider may use. If your business stores, processes, or transmits card data on behalf of other companies, or can affect the security of their card data, this is your questionnaire.

What Changed in SAQ A for 2025

PCI DSS v4.0 added two requirements aimed at web skimming attacks on payment pages. Requirement 6.4.3 covers managing the scripts that run on payment pages. Requirement 11.6.1 requires a mechanism to detect unauthorized changes to those pages. Both became mandatory on March 31, 2025.

The first v4 version of SAQ A included both, which caught many small merchants by surprise. In January 2025 the PCI SSC published a revised SAQ A, effective March 31, 2025, that made two changes:

Removed Requirements 6.4.3 and 11.6.1, along with 12.3.1 (the targeted risk analysis that supported 11.6.1).
Added an eligibility criterion. The merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

That second point is the part teams miss. The SAQ A merchant no longer has to document the script controls, but it still has to be able to confirm its site cannot be used to attack the payment flow. The practical ways to support that confirmation are to embed the processor's iframe using protections that stop scripts on your page from reaching into it, or to use a full redirect.

If you cannot make that confirmation, you are not SAQ A eligible.

ASV Scans Still Apply

Separately, SAQ A under v4 includes Requirement 11.3.2: quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). This applies to the web server that hosts the page with your redirect or iframe. The logic is simple. If an attacker takes over that server, they can point your customers at a fake payment page, and the processor's controls never see it.

Budget for passing quarterly scans even at SAQ A.

How to Choose the Right PCI DSS SAQ

Work through these questions in order. Stop at the first "yes."

Are you a service provider? If you handle card data on behalf of other businesses, you use SAQ D for Service Providers (or a ROC if you are Level 1). Stop here.
Do you store card data electronically? SAQ D for Merchants.
Are all your payments e-commerce or mail/telephone order?
- Is the entire payment form served by the processor, through a redirect or iframe, and can you confirm your site is not susceptible to script attacks? SAQ A.
- Does your own page render or post the card fields? SAQ A-EP.
Are all your card-present payments through a listed P2PE solution? SAQ P2PE.
Do you use a listed SPoC solution on phones or tablets? SAQ SPoC.
Do you use standalone IP terminals, isolated from other systems? SAQ B-IP.
Do you key payments into a virtual terminal on an isolated machine? SAQ C-VT.
Do you run a payment application connected to the internet? SAQ C.
None of the above fit cleanly? SAQ D for Merchants.

Multiple Payment Channels

Many businesses take cards in more than one way, for example an online store plus a phone line. Each SAQ's eligibility criteria describe a single way of accepting cards, and your acquirer decides how to handle the mix. Some accept a separate SAQ for each channel. Others want a single, larger questionnaire that covers everything. Ask before you start, and get the answer in writing.

Where SaaS Companies Get the PCI DSS SAQ Wrong

Most SaaS platforms land in one of three places. We cover the full merchant versus service provider analysis in PCI DSS for SaaS, but these are the common mistakes.

Assuming "we use Stripe" means SAQ A. The processor matters less than the integration. A hosted checkout or iframe fields put you in SAQ A. A custom form that collects the card number in your own JavaScript and passes it along can push you into SAQ A-EP, even with the same processor.

Ignoring the service provider role. If your platform lets your customers take payments, and your systems can affect how their card data is handled, you may be a service provider to them. That means SAQ D for Service Providers, not a merchant SAQ. Your customers will ask you for that AOC during their own assessments.

Letting card data leak into logs and support tools. Even with a clean SAQ A integration, card numbers pasted into support tickets, chat transcripts, or debug logs put that data on your systems. One unmanaged leak breaks your SAQ A eligibility.

Treating the SAQ as a once-a-year form. Scope changes whenever engineering changes the checkout. A new payment page, a switch from redirect to embedded fields, or a new marketing script on the checkout can all change which SAQ applies. Tie a PCI scope check to any change in your payment flow.

Completing the SAQ and AOC

Once you know which questionnaire applies, the process is the same:

Confirm eligibility. Read every criterion at the front of the SAQ and document why you meet each one.
Confirm your third parties. Collect current AOCs from your processor and any service provider that touches the payment flow.
Answer each requirement. Mark each one In Place, Not Applicable, or Not in Place, and keep the evidence behind every answer.
Run required testing. Quarterly ASV scans and, for larger SAQs, internal scans and penetration testing. Our guide to SOC 2 penetration testing covers how to scope a test that serves both frameworks.
Remediate gaps. Anything marked Not in Place needs a remediation plan and date.
Sign the AOC. An executive officer attests to the results.
Submit the SAQ and AOC to your acquirer or payment brand, in the format they require.

Repeat this every year, and whenever your payment flow changes in a way that affects scope.

For the full picture of PCI requirements and merchant levels, see the PCI DSS compliance guide and our PCI DSS service page. If you run a platform that handles payments for your customers, read PCI DSS for SaaS next.

Frequently Asked Questions

What is a PCI DSS SAQ? A self-assessment questionnaire that lets eligible merchants and service providers validate their own PCI DSS compliance. Each type covers only the requirements that apply to one way of accepting cards. You finish by signing an Attestation of Compliance and submitting both to your acquirer.

How many SAQ types are there? Ten under PCI DSS v4.0.1: A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC, D for Merchants, and D for Service Providers. Only the last one is for service providers.

What is the difference between SAQ A and SAQ A-EP? Who controls the payment page. SAQ A means the processor serves the entire form through a redirect or iframe. SAQ A-EP means your website renders or posts the card fields, which puts your web server in scope and adds many more requirements.

Who decides which SAQ I complete? Your acquirer or the payment brands. The eligibility criteria tell you which SAQ fits, but the acquirer sets your level and can require a specific SAQ or a full Report on Compliance. Confirm with them in writing.

Does SAQ A require ASV scans? Yes, for most e-commerce merchants. Requirement 11.3.2 calls for quarterly external scans by an Approved Scanning Vendor of the web server that hosts your redirect or iframe.

What happens if I complete the wrong SAQ? You are not actually compliant, even with a signed AOC. The mismatch usually surfaces after a breach, when investigators compare your real card data flow to what you attested, and breach costs can shift to you.

Not Sure Which SAQ Fits Your Payment Flow?

ShieldKey Solutions maps how card data actually moves through your product, confirms which PCI DSS SAQ applies, and where it makes sense, helps re-architect the checkout so you qualify for a smaller one. Then we take you through the questionnaire and Attestation of Compliance.

Schedule a scoping call →