PCI SAQ types explained: every v4.0.1 questionnaire

Which SAQ fits which setup

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 follows the way card data moves through your business: the terminal on the counter, the checkout on your site, the way phone orders get keyed. Size decides something else, your merchant level, which your acquirer assigns from your yearly card volume for each card brand (the merchant level calculator walks through it).

Read each line as a pointer, not a ruling. 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.” Those criteria are a list you confirm line by line, and one missed line moves you to a different form.

Every SAQ in the Council's words

The SAQ filter of the Council's document library lists 10 SAQs for PCI DSS v4.0.1, published in October 2024. Each receipt quotes the Council's one-line description from the SAQ Instructions and Guidelines, the channel limit printed under it, and the page that holds the full eligibility list. Pick how you take cards and the forms the Council rules out for that channel turn grey.

SAQ SPoC is the newest; the Council marks it “New SAQ for PCI DSS v4.x.” Every form except the last is “Not applicable to service providers.” For a service provider allowed to self-assess, the only SAQ is SAQ D for Service Providers.

SAQ A vs SAQ A-EP: who builds the payment page

The two online SAQs agree on almost everything. In both, the merchant does not electronically store, process or transmit account data on its own systems, and a PCI DSS compliant processor does the processing. They split on the payment page, and the Council's test is one sentence: “If any element of a payment page delivered to consumers' browsers originates from the merchant's website, SAQ A does not apply; however, SAQ A-EP may be applicable.”

That sentence moves the workload a long way. The Council counts the PCI DSS v4.x requirements that apply to each checkout setup:

A redirect to the processor's page, or the processor's iframe on your page, can fit SAQ A. A form your site builds that posts card data straight to the processor, or a script of yours that builds the payment page, points to SAQ A-EP. Stripe's own guide draws the line the same way for its products: Checkout or Elements map to SAQ A, and “Using Stripe.js v2 to pass card data entered in a form hosted on your own site requires completing the SAQ A-EP annually.” That is Stripe's mapping, not the Council's ruling.

SAQ A gets its own guide: SAQ A line by line, with the January 2025 revision.

SAQ B vs SAQ B-IP: a phone line or an IP line

Both fit a counter or a phone-order desk with standalone terminals and no card data stored electronically. SAQ B covers imprint machines and dial-out terminals on a phone line. SAQ B-IP covers standalone terminals that reach the processor over an IP connection, and the terminal must be a PCI-listed approved PTS POI device. Card readers are out: “merchants using SCRs or SCRPs are not eligible for this SAQ.”

What breaks B-IP most often is a connection. The Council names “connections to cash register systems” and a terminal that relies on “any other device (for example, a computer, mobile phone, tablet, etc.) to connect to the payment processor.” Several approved terminals can share a network zone, as long as they are isolated from every other kind of system. And “A merchant using an expired PTS POI device should check with its acquirer or individual payment brands about acceptability of this SAQ.”

SAQ C-VT vs SAQ C: a browser or a POS

SAQ C-VT is for typing card details into a processor's virtual terminal. A virtual terminal, in the Council's words, is “a third-party solution used to submit payment card transactions for authorization to a PCI DSS compliant third-party service provider (TPSP) website,” and “Unlike physical terminals, virtual payment terminals do not read data directly from a payment card.” SAQ C is for a point-of-sale or other payment application system connected to the internet.

C-VT's criteria are strict about the computer: it is isolated in a single location, it runs no software that stores card data (“there is no software for batch processing or store-and-forward”), and “there are no card readers attached.” SAQ C's criteria are strict about the shop: the POS environment “is not connected to other premises or locations, and any LAN is for a single store only.” Neither form covers e-commerce.

SAQ P2PE vs SAQ SPoC: listed solutions only

These two depend on a list. SAQ P2PE needs a validated, PCI-listed point-to-point encryption solution, which “can significantly help to reduce the PCI DSS validation effort of a merchant's cardholder data environment.” SAQ SPoC needs a phone or tablet with a secure card reader from a validated, PCI-listed SPoC solution, and the Council says it “significantly reduces the number of applicable PCI DSS requirements for merchants using a PCI SSC listed SPoC solution.” In both, the merchant has no access to clear-text account data.

The channels differ. A phone-order business can use SAQ P2PE: the Council's example is a merchant that receives account data “on paper or over a telephone, and key it directly and only into payment terminal from a validated PCI-listed P2PE solution.” SAQ SPoC is attended card-present only, never kiosks, self-checkout, phone orders or online sales. Each also asks you to apply the provider's own instructions: every control in the P2PE Instruction Manual (PIM), or in the SPoC user guide.

SAQ D: where every other setup lands

SAQ D for Merchants is the catch-all: “All merchants not included in descriptions for the above SAQ types.” It covers all PCI DSS requirements. The Council's examples of who it may apply to (p. 23):

• “E-commerce merchants that accept account data on their website;”
• “Merchants with electronic storage of account data;”
• “Merchants that do not store account data electronically but that do not meet the criteria of another SAQ type;”
• “Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.”

The second line is the one that catches small businesses: a card number typed into a spreadsheet for repeat orders is electronic storage of account data, however tidy the terminal on the counter is. SAQ D for Service Providers is a separate form, for “all service providers defined by a payment brand as being eligible to complete a self-assessment questionnaire”, and it “now requires additional documentation in Section 2a and specifies that service providers ‘Describe Results’ for each PCI DSS requirement.”

More than one way to take cards

Most SAQs carry an “only” line in their criteria. SAQ A's reads “The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions”; SAQ A-EP's, “The merchant accepts only e-commerce transactions.” A shop with a counter terminal and a web store does not meet either line as written, even when the website alone would.

SAQ D's own list includes “Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.” Whether you file one SAQ or one per channel is not the Council's call: “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.”

What is inside every SAQ

Each SAQ has the same parts, in this order (SAQ Instructions, p. 2):

1. 01Completing the Self-Assessment Questionnaire. The eligibility criteria for that SAQ, with completion instructions and guidance.
2. 02Attestation of Compliance. “The entity’s declaration of eligibility to complete the applicable SAQ and their attestation to the results of a PCI DSS self-assessment.”
3. 03PCI DSS Requirements (Section 2). The applicable requirements with a place to record your response to each, plus appendices for compensating controls and Not Applicable answers.

The answers changed with v4.x: “‘Yes’ is now ‘In Place.’” Where you meet a requirement another way, you complete a Compensating Controls Worksheet for it and check the “In Place with CCW” column. And a form you filed years ago is no guide to this year's:

“Merchants should not assume that a particular SAQ for both PCI DSS v3.2.1 and v4.x are the same.”

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. The signed Attestation is what you send back; the Attestation of Compliance guide covers who signs it, and how to become PCI compliant walks the whole yearly loop.