PCI SAQ Level Finder: which SAQ do I need?

One input decides it: how account data reaches you in the channel you are assessing. Not your revenue, not your headcount, not your processor. The PCI Security Standards Council publishes nine self-assessment questionnaires: eight for merchants, and SAQ D for Service Providers, which is the only one a service provider may ever use.

The Council's flow chart, on pages 23 and 24 of the SAQ Instructions and Guidelines, asks three things in a fixed order. Are you a service provider. Do you store any account data electronically, including legacy data. And how do you accept payments. The order is not cosmetic: storing card numbers puts you on SAQ D whatever your checkout looks like, so a tool that asks about checkout first will hand a merchant with an old order table full of card numbers the shortest questionnaire in the set. The PCI SAQ Level Finder asks in the Council's order for that reason.

One SAQ covers one payment channel, not one business. A shop that sells online and takes cards at a counter runs the finder twice and usually ends up with two different questionnaires. The Council adds that merchants with more than one channel should ask their acquirer and payment brands how to report the combination.

The eligibility criteria are attestations, not descriptions. Completing SAQ C-VT means signing that the computer running the virtual terminal is isolated in a single location, connected to no other systems, with no software that stores account data and no card reader attached. That is the criterion most often untrue in practice: the moment the back office machine also does email and sits on the shop network, SAQ C-VT stops applying and nothing tells you.

The test is one sentence in the eligibility criteria, and it is about the browser rather than the card number. For SAQ A, all elements of the payment page delivered to the customer's browser must originate only and directly from a PCI DSS compliant third-party service provider. For SAQ A-EP, each element originates from either the merchant's website or a compliant provider. Neither lets account data touch merchant systems.

The Council gives its own examples. A merchant with no access to its own website, a website that redirects to the processor, and a website that embeds the processor's payment page in an iframe are all SAQ A, carrying 11, 27 and 29 applicable requirements. A site that creates the payment form and posts the data straight from the browser, often called Direct Post, and a site that loads a script supporting creation of the payment page, are both SAQ A-EP, which is 139 requirements. Roughly five times the iframe case, and the most expensive misclassification available to a small online merchant.

In practice the trap is modern checkout tooling. Hosted card fields dropped into a form your own template renders, a payment SDK loaded from a script tag, a tag manager that can inject anything onto the checkout page: each is an element of the payment page originating from your website. The processor may still describe the integration as reducing PCI scope, which is true against taking raw card numbers, but reducing scope to SAQ A-EP is not reducing it to SAQ A.

There is a second reason the distinction matters more than it used to. SAQ A under PCI DSS v4.x carries Requirement 11.3.2, an external vulnerability scan performed at least once every three months by a PCI SSC Approved Scanning Vendor, plus 11.3.2.1 for a scan after any significant change. SAQ A required no scanning under v3.2.1, and a great deal of published guidance has not caught up. If a page tells you SAQ A means no scans, check its date.

Merchant levels are card network classifications, not PCI SSC ones, and the two networks define them in almost the same words. Visa puts Level 1 at over 6 million transactions a year across all channels, Level 2 at 1 million to 6 million, Level 3 at 20,000 to 1 million e-commerce transactions, and Level 4 at everything below. Mastercard mirrors those numbers for combined Mastercard and Maestro volume and adds that meeting Visa's criteria at a level meets Mastercard's too.

The denominator is where published calculators go wrong. Levels 1 and 2 are decided on all transactions across every channel. Level 3 is decided only on the e-commerce subset. A hardware store with 900,000 card-present sales and 400 online sales has a 900,400 total, nowhere near the 1 million line, and 400 e-commerce transactions, nowhere near the 20,000 line. It is Level 4. Read that total against the Level 3 line and you have told the shop it needs validation it does not need.

The two networks also disagree at exactly one number. Mastercard's rule is greater than 20,000 e-commerce transactions for Level 3. Visa's page describes Level 3 as 20,000 to 1 million and Level 4 as fewer than 20,000, which claims 20,000 for both. The PCI SAQ Level Finder uses the strict Mastercard reading, so exactly 20,000 returns Level 4, and it flags the tie on screen rather than pretending the boundary is crisp. If you are within a few hundred transactions of it, ask your acquirer instead of picking the answer you prefer.

What the level changes is the validation route, not the security. A Level 1 merchant undergoes an annual assessment producing a Report on Compliance signed by a Qualified Security Assessor or a certified Internal Security Assessor. Levels 2, 3 and 4 complete a questionnaire, though Mastercard requires a Level 2 merchant completing SAQ A, A-EP or D to additionally engage a QSA or ISA. Your acquirer assigns the level, per brand, so you can be Level 2 at one network and Level 4 at another. Mastercard also reserves the right to deem any merchant Level 1 at its discretion, including after a confirmed compromise.

PCI DSS v4.0.1 is the only active version of the standard. It was published as a limited revision in June 2024 with no new or deleted requirements, v4.0 was retired at the end of December 2024, and the Council opened a request for comments on v4.0.1 in June 2026 to begin the next iteration. The date that matters more than the version number is 31 March 2025, when the future-dated requirements in v4.x stopped being best practice and became mandatory.

Two of them are about the payment page, and they are why the SAQ A question got sharper. Requirement 6.4.3 makes a merchant manage every script loaded and executed in the consumer's browser on the payment page: authorize it, justify it, keep an inventory. Requirement 11.6.1 requires a change and tamper detection mechanism that alerts on unauthorized modification to the payment page and its HTTP headers. Requirement 12.3.1 requires a targeted risk analysis supporting the frequency chosen for 11.6.1. Together they are the standard's answer to digital skimming.

SAQ A was revised twice in quick succession because of them. The October 2024 version included all three. The January 2025 revision, effective 31 March 2025, removed them and added an eligibility criterion instead: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems. FAQ 1588 says a merchant confirms that either by deploying protections itself, using techniques such as those in 6.4.3 and 11.6.1, or by getting written confirmation from its processor that the embedded solution includes them. It applies to embedded payment pages, not full redirects. Removing a requirement from a questionnaire does not remove it from the standard.

Requirement 11.3.2, the quarterly Approved Scanning Vendor scan, is the other v4.x change worth knowing before you budget. It appears in Section 2 of SAQ A, A-EP, B-IP, C and D for Merchants, and not at all in SAQ B, C-VT or P2PE, which contain no Requirement 11 entries. That is the clearest commercial argument for a listed point-to-point encryption solution or a genuinely dial-out terminal: not only a shorter questionnaire but a recurring scanning bill you never open.

Most of the time it means do nothing. If the PCI SAQ Level Finder names the questionnaire you already file, your acquirer agrees, and you can genuinely confirm every criterion on the eligibility list, you are done for the year. A single-location shop on a validated PCI-listed P2PE solution is the cleanest case in the standard: SAQ P2PE touches three of the twelve requirement families and carries no external scanning.

Act if the finder says SAQ A-EP and you have been filing SAQ A. There are two honest routes. You can re-scope, moving to a full redirect or an iframe you add nothing to, and become genuinely eligible for SAQ A. Or you can accept SAQ A-EP and work through 139 requirements, which is a real project and a real budget. The third option, filing SAQ A because nobody has asked, holds up until a forensic investigator reads your checkout page after an incident, at which point the attestation you signed is the problem.

Act if you have crossed a level line. Mastercard gives an explicit grace period: when a merchant transitions from one level to another because volume grew, the acquirer must ensure compliance with the new level as soon as practical and in any event within one year of the event that caused it. A merchant who went from 18,000 to 26,000 online transactions has that year, not forever.

Finally, act if a line on your statement is doing the work instead of you. A monthly PCI non-compliance fee is not a compliance program and paying it does not validate anything. Neither does a bundled breach insurance product sold as PCI protection. Work out which questionnaire you are actually eligible for first, then decide what you are buying, and price the fees separately. The junk fee calculator on this site itemizes what those lines usually are.