Which PCI-DSS SAQ Type Do You Actually Need?
Eight different Self-Assessment Questionnaires exist because eight materially different ways of accepting card payments carry eight different risk profiles. Picking the wrong one either overstates your obligations or, worse, understates your actual exposure.
Who Can Use a Self-Assessment Questionnaire at All
A Self-Assessment Questionnaire (SAQ) is a self-administered validation tool merchants use to document PCI-DSS compliance, as opposed to a formal Report on Compliance (ROC) led by a Qualified Security Assessor. Broadly, merchants processing under 6 million card transactions annually are typically eligible to self-assess with an SAQ rather than undergo a QSA-led ROC — see our merchant levels guide for exact thresholds by level and card brand. Even within SAQ eligibility, the merchant must independently qualify for a specific SAQ type based on how it actually handles cardholder data — not every eligible merchant gets to choose the shortest questionnaire.
SAQ Types and the Scenarios They Fit
The merchant fully outsources all cardholder data processing to a PCI-DSS validated third party and does not store, process, or transmit any cardholder data on its own systems or premises. Typical fit: a small e-commerce site using a hosted checkout page or redirect where the card form itself lives on the processor’s domain.
The merchant partially outsources payment processing (typically to an iframe or API-based gateway) but the merchant’s own website directly influences the security of the payment page or transmits cardholder data itself, even without storing it. This carries substantially more assessment scope than SAQ A because the merchant’s own web application is now in the trust chain.
Card-present merchants using only standalone, PTS-approved payment terminals connected via a dial-up phone line (not IP-connected) or physical imprint machines, with no electronic cardholder data storage. Legacy but still common among very small retail and service businesses.
Same as SAQ B, but the standalone terminal connects to the payment processor over the internet (IP) rather than a dial-out line, and the terminal is segmented from other systems on the merchant’s network. Common for retail counters using modern IP-based card terminals with no POS integration.
Merchants with a payment application system connected to the internet (POS systems, integrated payment terminals) but that do not store cardholder data electronically. More complex than SAQ B/B-IP because the environment includes a fuller network stack, not just an isolated terminal.
Merchants that manually enter a single transaction at a time into an internet-based virtual terminal solution hosted and provided by a PCI-DSS validated third party, with no cardholder data storage and no electronic transmission of card data other than through the virtual terminal itself. Common for phone-order businesses using a browser-based payment portal.
The catch-all SAQ for merchants that store cardholder data electronically or otherwise don’t meet the criteria for any narrower SAQ, and for service providers permitted by a payment brand to self-assess. SAQ D for Merchants covers every one of the 12 requirements in full and is by far the longest questionnaire. If none of the above fit cleanly, assume SAQ D until proven otherwise.
Merchants using a PCI SSC-listed, validated P2PE solution where the card terminal encrypts cardholder data at the point of capture and only the P2PE solution provider holds the decryption capability. Because the P2PE solution itself carries most of the compliance burden, this SAQ is dramatically shorter than the alternatives it replaces.
Self-Selecting the Wrong SAQ Is the Most Common PCI Mistake We See
Merchants routinely assume SAQ A applies because they “use a payment processor,” without verifying whether their own web page code touches the card data flow (which would actually require SAQ A-EP) or whether cardholder data lands anywhere in their own logs, CRM, or order-management system (which would push them toward SAQ D). Your acquiring bank or payment brand has the final say on which SAQ is required — when in doubt, confirm in writing before self-certifying.
Armorstack’s VERITY portfolio runs a data-flow assessment before recommending an SAQ type, tracing exactly where cardholder data enters, moves through, and exits your environment — the same exercise a QSA would perform for a Report on Compliance, scaled to SAQ-level effort.
Continue Reading
Your transaction volume determines whether an SAQ is even an option, or whether a QSA-led ROC is required.
Proper segmentation is often what pushes a merchant from SAQ D scope down to SAQ C or B-IP.
Back to the full guide on the 12 requirements and who has to comply.