PCI DSS SAQ Types: Choose the Right Self-Assessment Questionnaire and Evidence It

Merchants regularly complete the wrong PCI DSS Self-Assessment Questionnaire, usually SAQ A when their checkout page actually makes them SAQ A-EP, and discover the gap only after a skimming incident or an acquirer query. PCI DSS v4.0.1 has ten SAQs, and each one is a short-form version of the standard for a specific payment architecture with strict eligibility criteria. This guide explains what each SAQ covers, how to work out which one applies channel by channel, what changed for SAQ A in 2025, how identity and service account requirements appear in the questionnaires, and what evidence an acquirer or assessor will expect. It is written for compliance leads, e-commerce and payments engineers, and the IT providers who complete SAQs for smaller merchants. The standard itself, its twelve requirements and the defined and customised approaches are covered in the PCI DSS 4.0 Guide.

Key takeaways

• The architecture picks the SAQ. Eligibility depends on how card data flows through each payment channel, not on company size; change the architecture to change the SAQ.
• Your acquirer has the final word. PCI SSC writes the SAQs, but payment brands and acquirers set who must validate and how, so confirm the SAQ choice with the acquirer in writing.
• SAQ A is not zero work. Since 31 March 2025, merchants embedding a provider's payment form must confirm their site is "not susceptible to attacks from scripts", with their own controls or the provider's confirmation.
• Service providers have one option. SAQ D for Service Providers is the only questionnaire for service providers a payment brand allows to self-assess; every other SAQ excludes them.
• Every "Yes" needs evidence. An SAQ is a signed attestation: keep the data flow diagram, provider attestations, scan reports and configuration evidence behind each answer.

What an SAQ is and who it applies to

A Self-Assessment Questionnaire is PCI SSC's validation tool for entities that are allowed to assess themselves instead of commissioning a Report on Compliance (ROC) from a Qualified Security Assessor. Each SAQ contains only the PCI DSS requirements relevant to one type of payment environment, written in the same wording as the standard, and ends with an Attestation of Compliance (AOC) that the entity signs. The v4 SAQs align their response format and AOC sections with the v4 ROC template.

Who must validate, and how, is set by the payment brands and enforced by acquirers, not by PCI SSC. Visa, for example, assigns merchant levels by annual Visa transaction volume over 12 months: Level 1 is over 6 million transactions across all channels, Level 2 is 1 to 6 million, Level 3 is 20,000 to 1 million e-commerce transactions, and Level 4 is fewer than 20,000 e-commerce transactions or other merchants processing up to 1 million. Level 1 merchants normally need a ROC; lower levels usually self-assess, but the acquirer decides what it will accept and can require a ROC or an ISA-led assessment at any level.

Compliance and validation are different. An SAQ validates compliance for its scope; it does not reduce the PCI DSS requirements that apply to the environment. PCI SSC made exactly this point when it removed the script requirements from SAQ A in 2025: the change affects reporting, not the underlying standard.

The ten SAQ types and their eligibility

The table summarises the SAQs listed in PCI SSC's SAQ Instructions and Guidelines for v4.0.1 (revision 1, April 2025). Every SAQ except D also requires that the merchant does not store cardholder data electronically. Read the eligibility criteria in the SAQ document itself before starting: you must meet all of them.

PCI SSC's v4 changes tightened two of these. SAQ B-IP is for standalone POI devices only, and SAQ C-VT eligibility no longer allows segmentation as a way to qualify, so the virtual terminal must run on a standalone computer. SAQ SPoC was added in September 2023. Mobile payment acceptance on commercial devices is explained in the PCI Mobile Payments on COTS Guide, and P2PE solutions in the PCI Point-to-Point Encryption Guide.

Choosing the right SAQ for e-commerce

The e-commerce channel causes most selection errors because the difference between SAQ A, A-EP and D sits in technical detail that compliance teams rarely see. PCI SSC's guidelines map the integration method to the SAQ.

Decision guidance: moving from a merchant-built form (A-EP) to a provider-hosted iframe or redirect (A) is the largest scope reduction most online merchants can make. A redirect removes the script criterion entirely; an iframe keeps the parent page in play because a malicious script on it can overlay or replace the frame. Page script controls are covered in the PCI DSS for E-commerce Payment Page Scripts Guide. Under FAQ 1588, an SAQ A merchant can meet the criterion either with its own techniques "such as, but not limited to" those in 6.4.3 and 11.6.1, or with confirmation from a PCI DSS compliant provider that its embedded form, implemented according to its instructions, includes script protections. Keep that confirmation on file.

Several channels: a merchant that takes online, telephone and in-store payments assesses each channel against the eligibility criteria. PCI SSC tells merchants with more than one channel to consult their acquirer or payment brands on validation and reporting; some accept one SAQ per channel, others require SAQ D across the business. Never answer an SAQ for one channel while ignoring another that falls outside its eligibility.

Structure and key requirements

Every v4 SAQ follows the same pattern: completion guidance and eligibility criteria, Section 1 assessment information, Section 2 the requirement responses grouped under the twelve PCI DSS requirements, Section 3 validation and attestation details, and appendices for compensating controls and requirements marked not applicable. Responses align with the ROC template; any requirement answered "Not Applicable" must be explained in the appendix.

• Targeted risk analysis: several v4 requirements let the entity set a frequency through a targeted risk analysis (for example how often to evaluate malware protection needs or review certain logs), and Requirement 12 requires documenting any TRA the SAQ includes. See the PCI DSS Customised Approach and Targeted Risk Analysis Guide.
• SAQ A-EP growth in v4: PCI SSC lists new A-EP requirements including secure configuration policies (Requirement 2), anti-malware and anti-phishing measures (5), bespoke software inventories and automated detection of web attacks (6), MFA for all access into the cardholder data environment (8), automated log review (10), and phishing training and 24/7 incident response staff (12).
• SAQ C-VT additions: configuration policies, data retention and media protection for paper records, anti-malware for removable media, password rules and social engineering awareness.
• Third-party service providers: SAQs that rely on outsourcing still include the Requirement 12.8 duties to keep a list of providers, hold written agreements and monitor their compliance status, typically through their AOCs. The PCI DSS for Service Providers and Responsibility Matrix Guide explains how to split responsibilities.
• Scans and testing: SAQs that include internet-facing merchant systems include quarterly external vulnerability scans by an Approved Scanning Vendor (Requirement 11.3.2), and some include penetration testing. Check your SAQ's requirement list rather than assuming.

Identity and NHI requirements in the SAQs

Requirement 7 and 8 items in an SAQ are often the hardest to evidence because they cover accounts the merchant does not think of as "users": payment provider dashboard logins, e-commerce platform admin accounts, API keys and the service accounts behind integrations.

• Provider and platform consoles: even SAQ A merchants control accounts that can change payment settings, redirect URLs or embedded scripts. Use named accounts, MFA and prompt removal of leavers; a compromised admin login can turn an SAQ A site into a skimming site. See the MFA Guide.
• MFA into the cardholder data environment: v4 requires MFA for all access into the CDE (Requirement 8.4.2), which PCI SSC lists among the new SAQ A-EP requirements. For A-EP that means the web servers that serve payment pages.
• Default and shared accounts: vendor default accounts must be changed or disabled (2.2.2), and shared or generic accounts are allowed only by exception with documented controls.
• System and application accounts: Requirements 8.6.1 to 8.6.3 govern interactive use of service accounts, hard-coded passwords and password rotation for application and system accounts. They apply in SAQ D and anywhere your SAQ includes them. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6).
• API keys for payment providers: keys that create charges or refunds are as powerful as an admin login. Store them in a secrets manager, scope them to the minimum, and rotate them when staff or suppliers change.

Implementation steps

1. Inventory payment channels: list every way the business accepts cards: websites, apps, phone, mail, terminals, kiosks, payment links and third parties acting for you.
2. Draw the data flow per channel: show where card data enters, which systems touch it and which providers process it. This diagram drives SAQ choice and is evidence in its own right.
3. Collect provider evidence: obtain current AOCs for every payment service provider and, for embedded forms, the provider's written statement on script protection.
4. Map each channel to an SAQ: test every eligibility criterion; where any fails, move to the next SAQ up or change the architecture.
5. Confirm with the acquirer: send the diagram and proposed SAQs; record the acquirer's answer, including how to report multiple channels.
6. Close gaps before attesting: implement missing controls and remediate scan failures. If a control cannot be met for a documented constraint, prepare a compensating control worksheet and expect scrutiny.
7. Complete and sign: answer every requirement, explain each "Not Applicable" in the appendix, and have an officer sign the AOC who understands what is being attested.
8. Diarise the cycle: annual SAQ, quarterly ASV scans where applicable, provider AOC renewals, and a re-check whenever the checkout or terminal estate changes.

Small and large merchants: a small online shop on a hosted platform can often complete SAQ A in a day once provider evidence is in hand. A larger merchant with several brands and channels should keep a channel register, assign an owner per channel and treat any change to checkout code as a trigger to re-check SAQ eligibility.

Evidence and assessment

Measure it: track the share of channels with a current, acquirer-confirmed SAQ; provider AOCs older than 12 months; quarters with a passing ASV scan; days from a checkout change to an eligibility re-check; and the number of "Not Applicable" answers without an appendix explanation. Acquirers increasingly ask for evidence behind answers, and a breach investigation will compare the signed SAQ with what was actually running.

Mapping to other frameworks

CIS Controls v8.1 Control 15 (Service Provider Management) covers the same provider inventory and monitoring. For a full control-level crosswalk, see the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Common pitfalls

• Choosing SAQ A for a merchant-built form: a JavaScript or direct post form makes the site SAQ A-EP, which brings web server hardening, script controls and scanning. The wrong SAQ leaves those controls missing.
• Assuming the iframe makes the parent page irrelevant: the script criterion exists because attackers inject code into the page that hosts the frame. Without provider confirmation or your own controls, SAQ A eligibility is not met.
• Running a virtual terminal on a shared office PC: since v4, C-VT requires a standalone computer; a segmented but shared machine no longer qualifies.
• Ignoring a channel: the online shop is on SAQ A, but a phone team keys card numbers into a spreadsheet, which is electronic storage and breaks every SAQ except D.
• Expired provider evidence: the SAQ relies on a provider whose AOC lapsed, or whose services changed, so the outsourcing claim no longer holds.
• Service provider on a merchant SAQ: a business that stores, processes or transmits card data for other merchants completes SAQ D for Service Providers or a ROC, as its brand requires.

Practitioner checklist

• Keep a register of every payment channel with an owner and a data flow diagram.
• Map each channel to its SAQ using the full eligibility criteria in the current SAQ document.
• Confirm the SAQ choice and multi-channel reporting with your acquirer in writing.
• For embedded payment forms, hold the provider's script protection confirmation or run your own 6.4.3 and 11.6.1 controls.
• Collect and diarise renewal of provider AOCs and the responsibility matrix.
• Enforce named accounts and MFA on payment provider consoles, platform admin and CDE access.
• Run quarterly ASV scans where the SAQ includes them and keep passing reports.
• Explain every "Not Applicable" answer and have an informed officer sign the AOC.
• Re-check eligibility after any change to checkout code, terminals or providers.

Standards and references

• PCI SSC: PCI DSS Self-Assessment Questionnaire Instructions and Guidelines v4.0.1 r1 (Spanish edition, acquirer-hosted copy)
• PCI SSC: Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A
• PCI SSC: FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants
• PCI SSC: PCI DSS v4.0, What's New with Self-Assessment Questionnaires
• PCI SSC: Document Library
• Visa: Security Compliance for Small Businesses (merchant levels)
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · Card Payments Security for Small Merchants Guide · PCI DSS Scoping and Network Segmentation Guide · PCI DSS Readiness Checklist