PCI DSS 4.0.1 · Merchant guide
Which SAQ do you need — A, A-EP, or D?
SAQ A, SAQ A-EP, and SAQ D are the three Self-Assessment Questionnaires under PCI DSS 4.0.1 that a small online merchant is most likely to complete. Which one applies is decided by how your payment page is built, not by your revenue, your shopping-cart platform, or which company hosts your site. Answer three honest questions about your checkout and you can work out your SAQ type in the next five minutes.
The three questions that actually decide it
Start with how you take card payments at all. If it's only in person, by phone, or by post — and you don't run an online store — your website itself carries no cardholder data, so a website SAQ doesn't apply to it. Your terminal or phone-payment provider needs its own, separate SAQ (often B, B-IP, C-VT, or P2PE depending on the device), which is a determination they're better placed to make than any hosting guide.
If you do take cards online, the next question is where the payment form actually lives: entirely on the processor's own hosted page or iframe (Stripe Checkout, PayPal, a bank redirect), or with fields embedded on your own page. A genuine hosted redirect or iframe, with nothing on your side able to influence it, is the hallmark of SAQ A — the shortest questionnaire there is.
The third question is the one people get wrong most often: can your own code touch, transmit, or influence that payment page at all — a JavaScript SDK, a styling script, custom fields you render around an embedded widget? If yes, you've moved into SAQ A-EP territory. The card number still never reaches your server, but PCI DSS now treats your page as part of the payment flow, which is why SAQ A-EP runs to roughly 139 questions instead of 24.
One more question overrides all of the above: do you store card numbers anywhere at all — in a CRM, a spreadsheet, a support ticket, a call recording? Any "yes" here forces SAQ D regardless of how clean your checkout otherwise is, because storage is exactly what SAQ A and SAQ A-EP rule out.
Quick self-check
- My payment form is a redirect or hosted iframe I don't touch → likely SAQ A.
- My own code (a JS SDK, custom fields) can influence the payment page → likely SAQ A-EP.
- I store card numbers anywhere, in any format → SAQ D, no exceptions.
- I only take cards in person, by phone, or by post → a website SAQ doesn't apply; ask your terminal provider instead.
Prefer to answer these interactively? Run the SAQ Wizard on the pci.hosting homepage — same logic, five clicks, a shareable result.
| SAQ type | Who it's for | Approx. size | ASV scan | Typical effort |
|---|---|---|---|---|
| SAQ A | Card entry fully outsourced to a validated processor's redirect or hosted iframe | ≈24 questions | Often exempt | A few focused hours |
| SAQ A-EP | Your own code can influence the hosted payment page (JS SDK, custom fields) | ≈139 questions | Usually required, quarterly | Days to weeks, often with outside help |
| SAQ D (Merchant) | Card data stored, processed, or transmitted outside a fully outsourced model | ≈300+ controls, 12 requirements | Required, quarterly, plus annual pen test | An ongoing program, not a form |
- Source: PCI Security Standards Council, SAQ Instructions and Guidelines, v4.0.1. Question counts are approximate and vary slightly by revision.
- Your acquirer makes the final determination of which SAQ you file — this table is guidance, not a formal eligibility ruling.
What PCI DSS 4.0.1 added for e-commerce
4.0.1 is a clarifying update to 4.0, not a new standard. Two requirements matter most for small online shops: 6.4.3 requires you to inventory and manage every script that loads on your payment page, including third-party tags — the same class of code that made Magecart-style skimming attacks possible. 11.6.1 requires a tamper-detection mechanism for that page, so unauthorized changes get flagged instead of shipping silently to customers.
Both fall on SAQ A-EP and SAQ D merchants directly. Pure SAQ A merchants are largely shielded, because their own page doesn't touch the payment step in the first place — one more reason a genuine hosted redirect is the simplest place to stay if your business model allows it.
What the paperwork actually costs
Costs scale roughly with SAQ tier, and the gap between tiers is large. For a typical small business with five to fifteen external IP addresses, ASV scans run about $150–$600 a year, or roughly $100–$500 per quarter, as of July 2026. SAQ A attestation help — if you use outside support to fill it in rather than doing it yourself — tends to run $300–$1,000 a year in the same market data.
Step up to SAQ A-EP and the number changes shape, not just size: outside help to complete the roughly 139-question form has run $5,000–$11,000, script-monitoring tooling to satisfy requirement 6.4.3 has run $7,000–$16,000 a year, and the wider ASV footprint has run $4,000–$9,000, all as of July 2026. SAQ D sits in a still wider $5,000–$20,000 band, reflecting the annual penetration test and the full 12-requirement control set.
These are U.S. and UK market figures, gathered as a cost anchor, not a German price list. A small EU merchant's real bill, especially for a clean SAQ A, is often at or below the low end of these ranges. What holds everywhere is the shape of the curve: SAQ A-EP costs several multiples of SAQ A, which is the single best argument for keeping your checkout on a hosted redirect if your product and conversion goals allow it.
What pci.hosting covers — and what stays yours
Whichever SAQ applies to you, your hosting environment is one control domain among several — not the whole assessment. pci.hosting runs TLS 1.2+/1.3-only connections with HSTS enforced, a defined patch SLA for the OS and server stack, retained system and access logs, host-layer file integrity monitoring, and segmented environments, and we never block your Approved Scanning Vendor.
What we can't do is complete your SAQ, secure your staff's laptops, or audit your own payment-page code — that half of the questionnaire is yours, and no hosting claim changes that. The PCI DSS small business checklist lists exactly what evidence to keep and who owns each control, SAQ type by SAQ type.
Frequently asked
What is SAQ A in plain words?
SAQ A is the shortest PCI DSS questionnaire — about 24 questions — for merchants whose website never touches cardholder data at all. Every card field lives entirely on a validated third party's page: a hosted redirect or an iframe from a processor like Stripe or PayPal. Your job is mostly to keep that handoff intact, confirm your processor's own compliance, and keep a written note of who has access to your site.
Does Stripe/PayPal redirect make me SAQ A?
Usually, yes — as long as the redirect or hosted iframe genuinely handles the whole card-entry step and nothing on your own page can rewrite, intercept, or otherwise influence that form. Mixed-content pages (an HTTP page loading an HTTPS payment iframe) or a custom checkout that just looks like a redirect can break that assumption, so it's worth checking every checkout path on your site, not only the one you tested.
What moves me to SAQ A-EP?
Any code you control that can influence the payment page moves you from SAQ A to SAQ A-EP — a JavaScript SDK, custom input fields, or a checkout page you assemble yourself around an embedded widget. The card number still never reaches your server, but PCI DSS treats your page as part of the payment flow, which is why SAQ A-EP runs to roughly 139 questions instead of 24.
What does an ASV scan cost?
For a typical small business with five to fifteen external IP addresses, Approved Scanning Vendor scans run roughly $150–$600 a year, or about $100–$500 per quarter, as of July 2026 — U.S. market figures used here as a cost anchor, not a German price list. SAQ A-EP and SAQ D merchants usually need them quarterly; pure SAQ A merchants relying on a hosted redirect are often, though not always, exempt.
Guidance, not a QSA opinion. Your acquirer has the final word — still unsure? Talk to us.