Which PCI SAQ do I need? Start with who decides
PCI DSS is intended for every entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of that data. Whether an entity must comply or validate its compliance is a separate question: PCI DSS v4.0.1 says it is at the discretion of the organizations that manage compliance programs, such as payment brands and acquirers.
There are two reporting routes. A Report on Compliance (ROC) documents an assessment performed by a Qualified Security Assessor (QSA), or by an Internal Security Assessor (ISA) where accepted. A Self-Assessment Questionnaire is a validation tool the entity completes itself, with an Attestation of Compliance (AOC) signed by an executive officer.
PCI SSC gives the same advice in several places: if you are unsure whether you may self-assess or which SAQ fits, ask your acquirer (merchant bank), the payment brands, or the organization that will receive your SAQ before you start.
The ten PCI SAQ types at a glance
PCI SSC publishes the SAQs for PCI DSS v4.0.1 in its Document Library. The summaries below paraphrase each SAQ's eligibility section. The full criteria in the current version of each SAQ decide whether you qualify.
| SAQ | Who it's for | Payment channels |
|---|---|---|
| SAQ A | Merchants that fully outsource all account data functions to validated third parties and keep no electronic account data | E-commerce, mail and telephone order |
| SAQ A-EP | E-commerce merchants that partially outsource payments; their website doesn't receive account data but can affect the security of the payment transaction or page | E-commerce only |
| SAQ B | Merchants using only imprint machines or standalone, dial-out terminals, with no electronic account data storage | In person, mail and telephone order |
| SAQ B-IP | Merchants using only standalone, PCI-approved PTS point-of-interaction devices with an IP connection to the payment processor | In person, mail and telephone order |
| SAQ C | Merchants with Internet-connected payment application systems, such as a point-of-sale system, that don't store electronic account data | In person, mail and telephone order |
| SAQ C-VT | Merchants that manually key one transaction at a time into a third-party, Internet-based virtual terminal on an isolated computer | In person, mail and telephone order |
| SAQ P2PE | Merchants that accept cards only through payment terminals in a validated, PCI-listed point-to-point encryption solution | In person, mail and telephone order |
| SAQ SPoC | Merchants using a commercial off-the-shelf phone or tablet with a secure card reader in a PCI SSC-listed SPoC solution | In person only (attended, card-present) |
| SAQ D for Merchants | SAQ-eligible merchants that don't meet the criteria for any other SAQ | Any |
| SAQ D for Service Providers | Service providers that a payment brand defines as eligible to complete an SAQ | Any |
How your payment setup drives SAQ eligibility
Each SAQ's criteria are written for a payment channel, so a business with several channels should ask its acquirer how to report them. Within a channel, the question is simple: which of your systems can touch account data or change what a customer sees when paying?
Fully outsourced e-commerce: SAQ A
SAQ A fits merchants whose payment pages come entirely from a third-party service provider or payment processor that has validated its own PCI DSS compliance, typically through a redirect or an embedded payment form such as an inline frame (iframe). The merchant doesn't store, process or transmit account data electronically, and confirms from the provider's Attestation of Compliance that it covers the services used.
Mail and telephone order merchants can also qualify if all processing is outsourced and any account data they keep is on paper that wasn't received electronically. SAQ A doesn't apply to face-to-face channels or to service providers.
A website that can affect payment security: SAQ A-EP
SAQ A-EP is for e-commerce merchants whose website doesn't receive account data but controls how customers or their data reach the processor, or delivers some elements of the payment page itself. Because that website can affect the security of the payment transaction and the integrity of the payment page, SAQ A-EP includes considerably more requirements than SAQ A, such as secure configuration, malware protection and multi-factor authentication.
Terminals, virtual terminals, P2PE and SPoC
In-person and mail or telephone order merchants choose among SAQ B, B-IP, C, C-VT and P2PE, depending on the equipment they use; none of these applies to e-commerce. SAQ SPoC covers merchants that take cards on a phone or tablet using a secure card reader that is part of a solution on PCI SSC's list of validated Software-based PIN Entry on COTS (SPoC) solutions. PCI SSC says it applies to card-present transactions and not to unattended card-present, mail or telephone order, or e-commerce channels.
These SAQs depend on isolation. SAQ B, B-IP and C expect the terminal or payment system not to be connected to other systems in the merchant environment, SAQ C-VT expects an isolated computer, and SAQ P2PE expects the P2PE terminals to be the only systems handling account data. A terminal on the office network, or a virtual terminal opened on a computer that connects to other systems, can break eligibility.
Everything else: SAQ D
SAQ D for Merchants applies to merchants that may self-assess but don't meet the criteria of any other SAQ. PCI SSC's examples include e-commerce merchants that accept cardholder data on their own website, merchants that store cardholder data electronically, and merchants whose environment fits another SAQ but has additional PCI DSS requirements that apply.
Service providers have one option. PCI SSC states that SAQ D for Service Providers is the only SAQ for SAQ-eligible service providers; all other SAQs are for merchants.
SAQ A after March 31, 2025: the script eligibility criterion
PCI DSS v4.0 added two payment page requirements that became mandatory on March 31, 2025: 6.4.3, which requires each script loaded and run in the consumer's browser on a payment page to be authorized, integrity-checked and inventoried with a written justification, and 11.6.1, which requires a mechanism to detect unauthorized changes to the page's security-impacting HTTP headers and script contents.
On January 30, 2025, PCI SSC announced a revised SAQ A, effective March 31, 2025. It removed requirements 6.4.3 and 11.6.1, and requirement 12.3.1 for the targeted risk analysis that supports 11.6.1, and added an eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
PCI SSC FAQ 1588 explains that the criterion applies only to merchants whose webpage includes an embedded payment page or form from their provider, such as an iframe, not to merchants that redirect customers or fully outsource the payment function. A merchant can meet it by using techniques such as those in 6.4.3 and 11.6.1, itself or through a third party, or by getting confirmation from the provider of the embedded payment form, which must itself meet PCI DSS, that its solution, implemented according to its instructions, includes techniques that protect the merchant's payment page from script attacks.
PCI SSC was explicit that the change doesn't remove or diminish the underlying requirements in PCI DSS. It changes how SAQ A merchants report on them.
PCI scope decides which SAQ and how much work
PCI DSS v4.0.1 requirements apply to the cardholder data environment (CDE), meaning the system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, plus components with unrestricted connectivity to them. They also apply to any system components, people and processes that could affect the security of that data. Scope is what makes one SAQ fit and another fail.
Segmentation isn't a PCI DSS requirement, but the standard strongly recommends it as a way to reduce the scope, cost and risk of compliance. To be out of scope, a system must be isolated so that it couldn't affect the security of account data even if it were compromised. Without adequate segmentation, the whole network is in scope.
PCI DSS also has two requirements that keep scope honest, though whether each appears in a given SAQ depends on that SAQ. Requirement 12.5.2 asks the entity to document and confirm its scope at least once every 12 months and after significant change, covering data flows, data-flow diagrams, locations of account data and third-party connections. Where segmentation isolates the CDE, requirement 11.4.5 calls for penetration tests of the segmentation controls at least once every 12 months and after changes to them.
- Remove account data you don't need and consolidate what remains in fewer places, as PCI DSS recommends.
- Move payment pages to a validated provider's hosted page or embedded form.
- Use validated P2PE terminals, or standalone devices kept apart from other systems.
- Segment the payment environment, and test that the segmentation works.
- Confirm any scope reduction approach with your acquirer before relying on it.
Completing an SAQ well
Read the eligibility criteria and the SAQ Instructions and Guidelines first; PCI SSC asks merchants to confirm they meet every criterion before they begin. Then answer each requirement from evidence, not memory: configuration exports, policies, provider AOCs, scan reports and training records.
Every requirement gets a response. PCI SSC's guidance is that a requirement must be verified as not applicable before it is marked that way, for example by confirming there is no wireless technology before skipping wireless requirements, and each such answer needs a written explanation. A requirement met with a compensating control needs a Compensating Controls Worksheet, described in PCI DSS Appendices B and C.
SAQs can't be used to document PCI DSS's customized approach. An entity that wants to use it may be able to validate with a Report on Compliance instead; its acquirer or the payment brands decide whether that's allowed and whether a QSA or an ISA must perform the assessment. When the SAQ is done, submit it with the AOC and any other requested documents, such as ASV scan reports, to your acquirer or other requesting organization.
Readiness work doesn't validate your compliance. We don't complete or sign your Self-Assessment Questionnaire or Attestation of Compliance for you; your organization does.
A short checklist before you choose an SAQ
Work through these steps for each payment channel before committing to a questionnaire:
- List every channel you use to accept cards: online, in person, phone and mail.
- For each channel, note which systems and providers touch account data, and collect each provider's current AOC.
- Map the data flows and confirm where account data is stored, processed and transmitted.
- Read the eligibility criteria of the likely SAQ in its current version from the PCI SSC Document Library.
- Confirm the choice with your acquirer before you begin.
- Check whether your SAQ includes external vulnerability scans and, if so, schedule them with a vendor on PCI SSC's ASV list.
- Set a date to reconfirm scope after any significant change.