Which PCI DSS SAQ do you need?

What the finder tells you

An SAQ is the Council's “Reporting tool used to document self-assessment results from an entity's PCI DSS assessment.” Which one you file depends on how card data moves through your business, not on its size. Being “SAQ-eligible” means you may self-assess under the card brands' programs and your setup “Meets the SAQ Eligibility Criteria specified in the chosen SAQ.” The finder walks those criteria, channel by channel, and quotes the line that decides each answer. The guide to every SAQ type explains each form in more depth.

It cannot make the call for you, and neither can the Council: “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.” Before you start an SAQ, confirm with the organization you submit it to (usually your acquirer, the merchant bank) that you are eligible for it. Your acquirer also assigns your merchant level from your yearly card volume for each card brand; the merchant level calculator walks through it.

How to use it

1. 01Say whose payments these are and whether a card number sits in any file, database, email or photo. Either yes ends the walk at an SAQ D, as the Council's flowchart does.
2. 02Tick every way you take cards: in person, by phone or mail, online.
3. 03For each one, pick the setup closest to yours, then answer each criterion. “Not sure” keeps the SAQ open as Confirm first; “No” moves that channel off the SAQ.
4. 04Copy or print the result and take it to your acquirer. Then work through the checklist for that SAQ.

The last step is where the PCI compliance checklist picks up, and the scope checker helps when you are not sure which devices touch card data.

Worked examples

Each row is one of the finder's examples run through the same logic, with every criterion answered yes. Load any of them from the example picker above and change one answer to see where it moves.

The last row is the one that surprises owners: a card number typed into a spreadsheet for repeat orders sends the whole business to SAQ D, however tidy the terminal is.

One business, several channels

The Council's flowchart asks its questions “for each payment channel to determine the related SAQ(s),” so a shop with a counter and a web store can land on two. It then adds: “Merchants with more than one payment channel should consult with their compliance-accepting entities (for example, payment brands and acquirers) about validation and reporting requirements.” The reason is in the criteria themselves. Most SAQs carry an “only” line:

• SAQ A“The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions”
• SAQ A-EP“The merchant accepts only e-commerce transactions”
• SAQ B“The merchant uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to the merchant processor) to take customers' payment card information”
• SAQ B-IP“The merchant uses only standalone, PCI-listed approved PTS POI devices (excludes SCRs and SCRPs) connected via IP to merchant's payment processor to take customers' payment card information”
• SAQ C-VT“The only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser”
• SAQ P2PE“All payment processing is via a validated PCI-listed P2PE solution”
• SAQ SPoC“All payment processing is only via a card-present payment channel”

A second channel on a different SAQ breaks that line, so ask your acquirer which it wants: one SAQ per channel, or SAQ D for Merchants, which the Council describes as also covering “Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.” Processors say the same about their own products. Stripe's PCI guide tells merchants that use several of its integration methods “you must illustrate compliance for them separately.”

SAQ A after January 2025

Most small online shops hope for SAQ A, and the January 2025 revision is why the finder asks one more question there. The Council removed “PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1,” and added an eligibility criterion that the merchant “confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).” The revised SAQ A took effect on 31 March 2025, when the October 2024 version was retired.

It changes what you report, not what the standard asks. The Council says the change does “not remove or diminish the underlying requirements within PCI DSS.” And SAQ A for v4.x still includes Requirements 11.3.2 and 11.3.2.1, the external vulnerability scans, for shops whose pages redirect to or embed a processor's payment page; what an ASV scan is explains that part.

The line between SAQ A and SAQ A-EP is where each element of the payment page comes from. If any element delivered to the shopper's browser comes from your own website, SAQ A does not apply; SAQ A-EP may. The Council's table counts what that costs:

SAQ A-EP carries 139 requirements; check the scan questions in your SAQ A-EP form or ask your acquirer. Whether your processor's hosted fields count as its iframe is a question for the processor; the SAQ A guide and the payment gateway comparison go through the common checkouts.

Where the rule says so

Every answer above comes from the SAQ Instructions and Guidelines for PCI DSS v4.0.1 (revision 1, April 2025), which opens from the Council's document library without the license form the SAQ forms sit behind. Here is each SAQ in the Council's words, with the criteria the finder checks. When you sign, the Attestation of Compliance is where you declare you are eligible for the SAQ you chose.