SAQ A walkthrough: fully outsourced e-commerce

By Sam Rivera, Founder, SentinelPanda · June 3, 2026 · 4 min read · PCI DSS

SAQ A is among the shortest PCI SAQs but the easiest to misuse. The eligibility bar is strict; the 4.0.1 script controls trip up almost everyone the first year.

Who SAQ A is for

SAQ A is for e-commerce-only merchants who fully outsource all payment functions to a PCI DSS validated third-party service provider (TPSP). Concretely: the customer is redirected away from your site to the TPSP's payment page, or the TPSP's page is iframed and your site has no scripts or DOM access to the payment form. You never store, process, or transmit cardholder data on any system you operate.

Common qualifying patterns: a full redirect to a hosted payment page (Stripe Checkout, PayPal full-page, Braintree Hosted Fields' redirect mode); an iframe served entirely by the TPSP where your code does not touch the iframe contents. Disqualifying patterns: direct-post forms, JavaScript-based collection that calls a tokeniser API, anything that lets your DOM see the card number.

The eligibility checklist

• You accept e-commerce payments only (no card-present, no MOTO).
• All elements of payment pages are delivered entirely by a PCI-validated TPSP.
• Cardholder data is never stored, processed, or transmitted electronically by your organisation.
• You confirm annually that your TPSP's PCI DSS compliance status is current.
• You have implemented and documented controls for any third-party scripts that load on the payment page (Req 6.4.3 / 11.6.1).

What changed in 4.0.1 for SAQ A

The big new requirement in 4.0 (now mandatory in 4.0.1) is script management. Requirement 6.4.3 says you must maintain an inventory of all scripts on payment pages and have a justification for each. Requirement 11.6.1 says you must monitor the payment page for unauthorised modifications. Both apply to SAQ A merchants even though the payment page is hosted by the TPSP — because the page that links to or embeds the payment is yours.

In practice: list every script tag, every CDN asset, every analytics tag, every chatbot widget that loads on the page containing the payment redirect or iframe. For each, document why it is needed and how you would detect a malicious change. Tag managers (GTM, Tealium) load scripts dynamically and need their own inventory of what they can inject.

The requirement subset

SAQ A is short — roughly two dozen control questions across Requirements 2, 6, 8, 9, 11, and 12. The bulk is Req 12 (programme management) — written policies, third-party agreements with the TPSP, incident response, security awareness.

Specific items to prepare evidence for: written TPSP agreement listing which PCI DSS requirements the TPSP handles for you (Req 12.8.2); a documented list of TPSPs with their PCI DSS status (Req 12.8.1); confirmation that the TPSP's compliance is current (Req 12.8.4); your script inventory and integrity monitoring (Req 6.4.3, 11.6.1); password and MFA policy for any administrative access to anything related to payments (Reqs 8.x).

Common SAQ A pitfalls

• Embedding payment fields via JavaScript (Stripe Elements, Square SqPaymentForm, Braintree Hosted Fields drop-in mode) — qualifies for A-EP, not A.
• Direct-post forms where the customer enters card data on your form and your code submits it to the gateway — A-EP at best, often D.
• Treating "we use a PCI compliant processor" as a complete answer without a written TPSP agreement (Req 12.8.2).
• Forgetting the script inventory — and being unable to demonstrate control of the page you ship to customers.
• Allowing the same shopping-cart server to ALSO accept card-present terminal traffic. Mixed channels usually mean SAQ D.

A worked example

You run a Shopify store. Checkout redirects fully to Shopify Payments (or another hosted gateway). Your site does not contain a custom payment form. Your TPSP letter from Shopify confirms PCI DSS Level 1 service provider status. Your script inventory lists Google Analytics, Hotjar, an intercom widget, and the Shopify checkout link; each has a written justification, and you monitor the storefront for unexpected script changes via your CSP report-uri or a third-party page-integrity service.

Your SAQ A walks through Req 6.4.3, 11.6.1, the Req 8 admin-account controls for your Shopify and analytics admin accounts, the Req 12 policies and the TPSP attachments. Total work: 2-3 weeks the first time, mostly spent producing the script inventory and the TPSP attestation. Half a day for revalidation if nothing changes.