The ten PCI DSS self-assessment questionnaires, who each one is for, the SAQ A change that caught e-commerce merchants in 2025, and how to land on the right one.
PCI DSS v4.0.1 has ten self-assessment questionnaires, and the one you complete is decided by how card data reaches your business, not by how big your business is. Most small e-commerce merchants using a fully hosted payment page or a third-party iframe complete SAQ A, the shortest questionnaire. Merchants taking payments on standalone dial-out terminals complete SAQ B. Any environment that does not match a specific SAQ falls to SAQ D, which carries the full PCI DSS requirement set. Service providers have one option only: SAQ D for Service Providers.
A PCI DSS self-assessment questionnaire, or SAQ, is a validation tool published by the PCI Security Standards Council that lets an eligible merchant or service provider report its own PCI DSS assessment rather than pay a Qualified Security Assessor for a Report on Compliance. Each SAQ carries only the requirements for one type of payment environment, which is why SAQ A is short and SAQ D is not. You complete it, sign the Attestation of Compliance at the back, and send both to your acquiring bank.
The PCI Security Standards Council publishes the questionnaires but does not set validation requirements. Those are set by the brands, acquirers and payment facilitators, so your acquirer has the final say on which SAQ you may use.
The right PCI DSS SAQ follows from one question: what actually touches the card number in your business? Work down the table to the row where every condition holds for the channel you are assessing. Run two channels and you may need two SAQs, or one SAQ D covering both.
| SAQ type | Who it is for | E-commerce? |
|---|---|---|
| SAQ A | Card-not-present merchants with all account data functions outsourced to compliant third parties, retaining data on paper only | Yes |
| SAQ A-EP | E-commerce merchants who partially outsource. The site takes no account data but controls or affects the payment page | Yes, only |
| SAQ B | Imprint machines or standalone dial-out terminals on a phone line, no electronic storage | No |
| SAQ B-IP | Standalone PCI approved terminals with an IP link to the processor, isolated from other devices in the same network zone | No |
| SAQ C | An internet-connected payment application system, no electronic storage of account data | No |
| SAQ C-VT | Transactions keyed one at a time into a web-based virtual terminal on a standalone computer | No |
| SAQ P2PE | Hardware terminals within a validated, PCI listed point-to-point encryption solution | No |
| SAQ SPoC | A phone or tablet with a secure card reader from a validated SPoC solution on the PCI SSC list | No |
| SAQ D for Merchants | Merchants eligible to self-assess who meet no narrower SAQ. Carries all PCI DSS requirements | Yes |
| SAQ D for Service Providers | The only SAQ for service providers. Carries all requirements, including service provider only ones | Yes |
SAQ A is the PCI DSS questionnaire for card-not-present merchants who have handed every account data function to a compliant third party. To use SAQ A you confirm that you take only card-not-present transactions, that all processing of account data is entirely outsourced to a PCI DSS compliant provider, that you never electronically store, process or transmit account data, that you have reviewed your provider's Attestation of Compliance, and that anything you retain is on paper. For e-commerce, every element of the payment page must reach the customer's browser only and directly from that provider.
In January 2025 the PCI Security Standards Council changed SAQ A after industry feedback on Requirements 6.4.3 and 11.6.1, the payment page script controls. It removed 6.4.3 and 11.6.1 from SAQ A, along with Requirement 12.3.1 for the targeted risk analysis supporting 11.6.1, and added an eligibility criterion asking merchants to confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems. The October 2024 version retired on 31 March 2025 and the January 2025 version took effect that day.
That change is regularly misreported as a reprieve. The Council was explicit that the modifications affect how merchants report on those requirements and do not remove or diminish the underlying requirements within PCI DSS. If your checkout is an iframe or a redirect, script tampering on your pages is still your problem.
SAQ A and SAQ A-EP both cover e-commerce merchants who do not touch card data, and the line between them is who controls the payment page. Under SAQ A, every element of that page reaches the browser directly from a PCI DSS compliant provider. Under SAQ A-EP, the merchant's website does not receive account data but does control how customers or their data are redirected to the provider, or serves part of the payment page itself.
The consequence is size. SAQ A-EP pulls in network security controls, secure configuration, malware protection, software inventory, secure development, access management, multi-factor authentication and log review, none of which appear in SAQ A. A merchant who assumes SAQ A because a provider supplies the card fields, but builds and hosts the checkout page around them, is very often an SAQ A-EP merchant.
SAQ D is the catch-all PCI DSS questionnaire, in two versions. SAQ D for Merchants applies to any merchant eligible to self-assess who meets no narrower SAQ, and carries the full requirement set. SAQ D for Service Providers is the only SAQ available to service providers, and adds the requirements marked for service providers only.
You land in SAQ D more easily than most people expect. Storing a primary account number anywhere, even in an old spreadsheet or a support ticket, takes you there, and so does a mix of channels no single SAQ covers. Where a requirement genuinely does not apply, SAQ D lets you mark it Not Applicable and explain why in Appendix C.
Your PCI DSS merchant level is set by annual card transaction volume, and it decides whether you may self-assess at all. Each payment brand publishes its own thresholds, they do not match, and only your acquirer or the brand can set your level. The table below uses Visa's published thresholds.
| Level | Annual Visa transactions | How you validate |
|---|---|---|
| Level 1 | Over 6 million across all channels | Annual Report on Compliance by a QSA, plus an Attestation of Compliance |
| Level 2 | 1 million to 6 million across all channels | Annual SAQ plus an Attestation of Compliance |
| Level 3 | 20,000 to 1 million e-commerce transactions | Annual SAQ plus an Attestation of Compliance |
| Level 4 | Under 20,000 e-commerce, or up to 1 million across all channels | Annual SAQ, or an alternative exercise set by the acquirer |
Two things catch people out. Mastercard requires Level 2 merchants completing SAQ A, SAQ A-EP or SAQ D to have the assessment validated by a QSA or an internal security assessor, so a Level 2 SAQ is not always purely internal. And merchant agreements typically treat you as Level 1 after a breach regardless of volume. For what each path costs, see our PCI DSS compliance cost breakdown.
Completing a PCI DSS SAQ is a documentation exercise sitting on a controls exercise, and the second one is the real work. The PCI Security Standards Council sets out the sequence: confirm the SAQ suits your environment, confirm the environment is properly scoped, assess it, complete the questionnaire and attestation, then submit both with anything else requested, such as ASV scan reports.
A small merchant needs a scope statement naming the systems and people in the cardholder data environment, a written policy set because Requirement 12 will not accept a verbal answer, evidence for every requirement answered Yes, and a quarterly ASV scan where the SAQ calls for one.
CertAssist lays out PCI DSS v4.0.1 as every requirement broken into its sub-requirements, with editable policy and evidence templates against each one and read-only access for whoever reviews your assessment, for a flat US$225 per month as of September 2026. CertAssist does not connect to your systems and does not pull your data, so there is no cloud admin role to grant and nothing to breach.
Be clear about the limits. CertAssist does not run your quarterly ASV scan, and no software can, because that scan has to come from a PCI SSC Approved Scanning Vendor. CertAssist does not decide which SAQ you are eligible for, and it does not replace a QSA where your level or your brand requires one. If you are a Level 1 merchant heading for a Report on Compliance, engage an assessor early. If you are a small merchant who needs to work through a questionnaire properly and keep the evidence somewhere sensible, that is the job it does well.
What is PCI DSS SAQ A-EP?
PCI DSS SAQ A-EP is the self-assessment questionnaire for e-commerce merchants who partially outsource their payment channel. The merchant's website does not receive account data, but it affects the security of the payment transaction or the integrity of the page that accepts the customer's card details, for example by hosting the checkout page a provider's fields sit inside. SAQ A-EP applies only to e-commerce and is substantially longer than SAQ A.
What is the difference between SAQ A and SAQ D?
SAQ A carries only the PCI DSS requirements that apply to a card-not-present merchant who has outsourced every account data function and keeps any retained data on paper. SAQ D carries the entire requirement set, because it is the questionnaire for merchants who meet no narrower SAQ, and it is the only one available to service providers. The deciding factor is your environment, not your volume.
How often must PCI DSS compliance be validated?
PCI DSS validation is annual for merchants who self-assess, meaning a completed SAQ and a signed Attestation of Compliance each year, usually submitted to the acquiring bank. Where your SAQ requires them, external vulnerability scans by a PCI Approved Scanning Vendor are quarterly. Your acquirer sets the deadlines, because the PCI Security Standards Council publishes the tools but does not set validation requirements.
Does PCI DSS require MFA?
Yes. PCI DSS v4.0.1 Requirement 8.4 requires multi-factor authentication for all non-console administrative access into the cardholder data environment, for all access into that environment, and for all remote access originating outside the entity's network that could reach it. The requirement covering all access into the cardholder data environment took effect on 31 March 2025. Which parts appear in your questionnaire depends on which SAQ you complete.
How many PCI DSS requirements are there?
PCI DSS v4.0.1 has 12 principal requirements grouped under six control objectives, and each breaks down into a large number of individually testable sub-requirements. That is why the questionnaires vary so much in length: SAQ A includes only the sub-requirements relevant to a fully outsourced card-not-present merchant, while SAQ D includes all of them. Counting the 12 headline requirements badly understates SAQ D.
Sources: the PCI SSC SAQ document library and its 2025 SAQ A announcement.
CertAssist lays out every PCI DSS v4.0.1 requirement with editable policy and evidence templates, and gives your reviewer read-only access, for a flat $225 a month. No integrations, so there is nothing to connect and nothing to breach.
See pricing FrameworksFlat $225 a month, or $2,475 a year (12 months for the price of 11). All prices in USD.
