ScopeHunter · Reference
PCI DSS SAQ A: the small-merchant path, explained
If your customers pay through a hosted checkout like Stripe and card data never touches your systems, SAQ A is the PCI DSS validation you actually owe. Here is what it covers, what it does not, and how to finish it honestly.
Who qualifies
SAQ A is for merchants whose card handling is fully outsourced to a PCI DSS compliant third-party service provider. In practice, for e-commerce:
You take only card-not-present payments · all processing is handled by a compliant processor (a Stripe-hosted checkout or redirect qualifies; so do similar hosted flows) · your systems never electronically store, process, or transmit account data · every element of the payment page delivered to the customer''s browser comes directly from the processor · any card data you retain is on paper only.
You do NOT qualify if your own site''s code builds the payment form (that is SAQ A-EP), if you take cards over the phone into your own systems, or if card data ever lands in your databases, logs, or email. When in doubt, ask your acquirer which SAQ they expect — the SAQ is their instrument, not ours.
What SAQ A actually asks
The v4.0 questionnaire holds 29 requirements drawn from 7 of PCI DSS''s 12 — the slice that still matters when the processor holds the card data:
| Area | Requirements | What it means for you |
|---|---|---|
| Secure configuration | 2.2.2 | No vendor default accounts on the webserver that links customers to the processor. |
| Paper account data | 3.1.1, 3.2.1, 9.4.x | Only if you print or store card data on paper. Fully digital merchants mark these Not Applicable with one sentence. |
| Vulnerability management | 6.3.1, 6.3.3 | Watch for vulnerabilities affecting your web stack; install critical patches within 30 days. |
| Access control | 8.2.x, 8.3.x | Unique accounts, real authentication, revocation on departure, sane password rules for anyone who can touch that webserver. |
| External scanning | 11.3.2, 11.3.2.1 | Quarterly external scans by a PCI SSC Approved Scanning Vendor — see the honest limit below. |
| Service providers | 12.8.1–12.8.5 | A real list of your TPSPs, written agreements, due diligence, annual compliance checks, and a responsibility split. |
| Incident response | 12.10.1 | A plan that includes who calls your acquirer and the payment brands — the PCI-specific line generic IR plans miss. |
The v4.0.1 r1 update (January 2025) removed payment-page script management (6.4.3) and tamper detection (11.6.1) from SAQ A for merchants meeting the new script-security eligibility confirmation — and URL-redirect merchants were already entitled to mark 11.6.1 Not Applicable under the SAQ''s own completion guidance. If your acquirer still requests the older form, both remain assessable.
How ScopeHunter helps — and its one honest limit
ScopeHunter tracks all 29 requirements with plain-language assessment guidance on every control — what the words mean, what an assessor checks, when Not Applicable is legitimate. Several derive from evidence the platform already measures if your hosts report to it: patch currency and vulnerability identification (6.3.1/6.3.3, fed by a nightly correlation against 140,000+ mirrored vendor advisories), authentication configuration (8.x), and your third-party register (12.8.1/12.8.4, checked for the processor''s presence and annual review recency). The result is the working record behind the Attestation of Compliance you sign.
The limit, stated plainly: requirement 11.3.2''s quarterly external scans must be performed by a PCI SSC Approved Scanning Vendor. ScopeHunter is not an ASV, and no compliance platform that is not one can satisfy that requirement for you. What ScopeHunter does is track the quarterly schedule and hold each passing ASV report as evidence. Many acquirers bundle an ASV — ask yours first.
We filled one out ourselves
ScopeHunter takes card payments through Stripe''s hosted checkout, which makes us an SAQ A merchant too — so the SAQ A support in the product exists because we needed it. Our own working record runs through the same screens yours would: most paper-media requirements are one-line N/As, the vulnerability and access requirements ride the same automated evidence our CMMC hardening produces, and the TPSP register holds Stripe and Google Cloud with their agreement citations.
See the compliance workspace · Compliance FAQ · CUI guide (for the defense-contract side of the house)
Educational, not a QSA''s advice; your acquirer''s instructions control. Last reviewed September 2026 against PCI DSS v4.0.1.