PCI-DSS SAQ Guide: Which Self-Assessment Questionnaire Do You Need?

When PCI SSC published updated SAQ A eligibility criteria alongside PCI DSS v4.0.1, it quietly disqualified a significant chunk of e-commerce merchants who'd been using the simplest self-assessment form for years. The issue wasn't that they were doing anything wrong with card data — it's that any JavaScript loading on their checkout page, including analytics trackers and chat widgets, could technically affect payment transaction security. That makes SAQ A-EP the right form, not SAQ A.

This isn't a technicality. SAQ A has roughly 22 requirements. SAQ A-EP has roughly 191 — including the new script integrity monitoring requirements (6.4.3 and 11.6.1) that specifically target the Magecart-style e-skimming attacks that have been targeting checkout pages since 2022. If you're on the wrong SAQ, you're certifying compliance against the wrong controls.

Here's how to pick the right one.

The short version: a decision tree

Before getting into each SAQ type, here's the logic that determines which one applies to you.

SAQ A — the shortest form, with stricter eligibility than you think

SAQ A is for merchants who fully outsource all card processing to a PCI DSS-compliant third party. In the v4.0.1 version published in early 2025, it carries about 22 requirements — the smallest of any SAQ type.

To qualify, every single one of these must be true:

• Your business accepts only e-commerce or mail order/telephone order (MOTO) payments — no card-present transactions
• All payment processing is handled by a PCI DSS-compliant third-party service provider
• Your systems do not store, process, or transmit any cardholder data electronically
• The payment form is entirely hosted on the third-party's domain — customers enter card data on a page you don't serve
• Your site is confirmed not susceptible to attacks from scripts that could affect your e-commerce systems

That last bullet is the v4.0.1 addition. PCI SSC removed Requirements 6.4.3 and 11.6.1 from the SAQ A form itself — but added a new eligibility confirmation requirement that merchants must verify their site is protected from script attacks. You can meet this by either implementing the techniques described in Requirements 6.4.3 and 11.6.1, or by obtaining written confirmation from your payment processor that their embedded solution already does this.

SAQ A-EP — for e-commerce merchants in the gray zone

SAQ A-EP applies when you sell online, redirect customers to a third-party processor for actual card data entry, but your website can influence the payment transaction in any way. "Influence" is the operative word — if your pages load JavaScript that runs on the same origin as the payment form, or if your server generates any part of the checkout flow, SAQ A-EP almost certainly applies.

SAQ A-EP has roughly 191 requirements in v4.0.1, and it includes both Requirements 6.4.3 and 11.6.1:

• Requirement 6.4.3: Maintain an inventory of all scripts on payment pages, document the business justification for each, and implement integrity checks (via Subresource Integrity hashes or behavior monitoring)
• Requirement 11.6.1: Implement a tamper-detection mechanism that alerts on unauthorized changes to HTTP headers and scripts on payment pages — assessed at least weekly

These exist because of e-skimming. Attackers compromise a third-party JavaScript library — an analytics tag, a chat widget, an A/B testing script — that loads on your checkout page, then inject code that silently exfiltrates card numbers as customers type. Your payment processor never sees the attack because the data is stolen before it reaches them.

If your checkout page loads Google Analytics, Meta Pixel, a Zendesk widget, or anything similar, you probably need SAQ A-EP.

SAQ B and SAQ B-IP — physical payment terminals

SAQ B covers merchants who accept cards through imprint machines or standalone dial-out terminals — the kind that aren't connected to the internet and transmit data over a phone line. No electronic storage of cardholder data, no internet connection. About 41 requirements.

SAQ B-IP is for merchants using standalone, IP-connected payment terminals that are not connected to any other systems in the merchant's environment. Think a countertop terminal that talks directly to the processor over the internet, with no integration to your POS software. About 83 requirements — more than SAQ B because the IP connection expands the attack surface.

Both SAQ B types require that the terminals are not connected to any other system and don't store cardholder data. If your terminal is integrated with your point-of-sale software, you're out of SAQ B territory and into SAQ C or SAQ D.

SAQ C — internet-connected payment apps without card storage

SAQ C is for merchants whose payment application connects to the internet for processing but doesn't store cardholder data. A restaurant using a POS system that processes payments through an internet connection, or a retail store using a payment application integrated with their checkout system, typically falls here.

About 160 requirements. The key distinction from SAQ D: no electronic cardholder data storage. If transactions are processed and card data is never written to disk or a database, SAQ C may apply. If there's any card storage — even temporary buffering that isn't cleared — you're looking at SAQ D.

SAQ C also applies to e-commerce merchants who process card data through an internet-connected payment application — but not to those who handle cardholder data only through a fully outsourced third-party solution (that would be SAQ A or SAQ A-EP).

SAQ P2PE — the shortest path for card-present merchants

If you've deployed a validated Point-to-Point Encryption solution from PCI SSC's approved P2PE solutions list, SAQ P2PE is for you. It carries about 35 requirements — the second-shortest form after SAQ A.

P2PE encrypts card data at the point of swipe or tap, before it ever enters the merchant's environment. The merchant never has access to unencrypted card data, which dramatically reduces the cardholder data environment (CDE) scope.

The catch: the P2PE solution must be on PCI SSC's validated P2PE solution list, and you must be implementing it exactly as described in the vendor's P2PE Instruction Manual (PIM). Any deviation — including connecting the terminal to unapproved network segments — takes you out of P2PE eligibility.

SAQ D — the catch-all (and the most common)

SAQ D Merchant is the full questionnaire. It covers all 12 PCI DSS requirements and includes roughly 285 individual controls in v4.0.1. It applies to any merchant who doesn't qualify for one of the shorter forms — which is most merchants who store any cardholder data electronically, run integrated e-commerce + card-present operations, or operate complex payment environments.

If you're unsure which SAQ applies to you, SAQ D is the safe default. Completing it means you're certifying against the complete standard. The risk of using a shorter SAQ incorrectly (certifying against fewer controls than apply to your environment) is worse than the administrative burden of completing SAQ D when a shorter form might have applied.

The complete SAQ comparison

The most common SAQ mistakes

Mistake 1: Using SAQ A when SAQ A-EP applies

This is by far the most common. A merchant uses Stripe, PayPal, or a similar processor, correctly identifies that they're "using a third-party processor," and picks SAQ A. But their site loads Google Tag Manager, which loads half a dozen third-party scripts on every page including checkout. That breaks SAQ A eligibility under v4.0.1 unless they can confirm none of those scripts can affect the payment system.

The test: open your checkout page, open your browser's network tab, and look at every script that loads. Can you account for every one? Do you have integrity hashes or monitoring for all of them? If not, SAQ A-EP is more likely correct.

Mistake 2: Assuming SAQ B applies to modern POS systems

If your point-of-sale system integrates with inventory management, customer loyalty, or any other software — it's almost certainly not SAQ B territory. SAQ B requires the terminal to be completely standalone with no connections to other systems in the merchant environment. Modern integrated POS setups typically land in SAQ C or SAQ D.

Mistake 3: Not asking your acquiring bank

Your acquiring bank (the bank that processes card payments for you) often specifies which SAQ you must complete. Many banks provide guidance based on your merchant category code and processing setup. If you're uncertain, ask them before self-selecting a form. They have the final say on what validation they'll accept.

Mistake 4: Treating SAQ completion as the compliance finish line

The SAQ is how you certify compliance — it's not what makes you compliant. Filling out the form without actually implementing the required controls is check-the-box compliance that will fail in an investigation after a breach. The controls in the SAQ (MFA, script inventory, penetration testing, log monitoring) need to actually be in place, documented, and operational.

After you pick your SAQ: what comes next

Determining the right SAQ is step one. The actual compliance work happens before you complete it. The SAQ itself asks you to attest to controls that should already be in place — not controls you plan to implement.

For most merchants, the highest-friction items in 2026 assessments are:

• MFA for all CDE access (Requirement 8.4) — mandatory under v4.0.1, not just for remote access
• 12-character minimum passwords (Requirement 8.3.6) — up from 7 characters in older versions
• Script inventory and monitoring (Requirements 6.4.3 and 11.6.1) — applies to SAQ A-EP and SAQ D merchants
• Quarterly ASV scans — required for all merchant levels as a condition of SAQ completion
• Information security policy documentation (Requirement 12) — must be reviewed annually and cover all 12 requirement areas

If your security policy documentation is incomplete or hasn't been updated to reflect v4.0.1 controls, that's where to start. Auditors — and the SAQ itself — will ask you to confirm those policies exist and are current.

Frequently asked questions