PCI SAQ A for online shops: who qualifies, and what 2025 changed

SAQ A in one screen

SAQ A is the shortest self-assessment questionnaire an online shop can file. It is for “Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated and compliant third parties. No electronic storage, processing, or transmission of account data on their systems or premises.” Since 31 March 2025 the version in force no longer asks about Requirements 6.4.3 and 11.6.1, the payment-page script rules. It asks you to confirm something new instead, and it still carries the quarterly external scans.

Who qualifies for SAQ A

Eligibility is not a size threshold. It is a list of statements you confirm about one payment channel, and every one has to be true. The SAQ Instructions print them on page 15: the general lines apply to every SAQ A merchant, and the lines marked Online only apply to online sales. SAQ A is not for face-to-face channels and not for service providers.

1. 01“The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions;”No counter, no terminal in this channel.
2. 02“All processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor;”Your processor does every bit of the card handling.
3. 03“The merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a TPSP(s) to handle all these functions;”No card number is stored, processed or sent electronically on anything you run.
4. 04“The merchant has confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant;”You checked, not assumed, for the exact services you use.
5. 05“Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.”Paper only, and never a printout of an order that reached you electronically, such as by email.
6. 06“All elements of the payment page(s)/form(s) delivered to the customer's browser originate only and directly from a PCI DSS compliant TPSP/payment processor.”Online only. Every part of the card form comes from the processor.
7. 07“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”Online only. The criterion added in January 2025.

Quoted from the SAQ Instructions and Guidelines v4.0.1 r1, p. 15, read on 2026-10-22.

The paper line catches more shops than it should. A phone order written on a pad and later shredded fits; an order form that arrives by email with the card number in it does not, because that card data reached you electronically. Phone and mail orders on SAQ A answer the same general lines; this guide stays with the online channel, and the guide to every SAQ type covers the rest.

The one test: where the payment page comes from

SAQ A and SAQ A-EP share most of their facts: in both, the processor does all the processing and your systems never electronically store, process or transmit account data. They split on one point, and the Council puts it in one sentence: “If any element of a payment page delivered to consumers' browsers originates from the merchant's website, SAQ A does not apply; however, SAQ A-EP may be applicable.”

That one sentence moves the workload a long way. The Council counts the PCI DSS v4.x requirements that apply to each checkout setup, and the step from a processor's iframe to your own form is a big one:

Processors map their own products to SAQs, and their maps are claims, not rulings. Stripe's guide puts Checkout and Elements at SAQ A because they “host all card data collection inputs within an iframe served from Stripe's domain (not yours),” and says “Using Stripe.js v2 to pass card data entered in a form hosted on your own site requires completing the SAQ A-EP annually” (Stripe's PCI guide). Braintree writes in its Hosted Fields overview that “Hosted Fields is built for merchants who want SAQ A eligibility.”

What changed in January 2025

The Council said it acted “in response to stakeholder feedback regarding the complexity of implementing the new e-commerce security Requirements 6.4.3 and 11.6.1” in PCI DSS v4.0.1. It removed “PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1,” and added an eligibility criterion that the merchant “confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”

The January 2025 SAQ A took effect on 31 March 2025, when the October 2024 SAQ A was retired. If an older copy of SAQ A sits in your files with 6.4.3 and 11.6.1 in it, it is the retired version: download the current form from the Council's document library before your next cycle.

Read the change for what it is. It changes what an SAQ A merchant reports, not what the standard asks:

The same post reminds merchants that the Council does not decide who files what: “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.” What you file, and anything asked beside it, is your acquirer's call, not the Council's.

The new criterion: a site not open to script attacks

The criterion exists because of e-skimming, also called Magecart or formjacking: a script on the page copies the card as the shopper types it. The Council's information supplement on 6.4.3 and 11.6.1 describes two shapes of attack:

• Silent skimming

  The malicious script runs in the background and the shopper completes the purchase without any sign that the card is being copied.

  How it shows Harder to spot: everything works for the shopper and for you, so it can run for a long time.

• Double-entry skimming

  A fake card form appears first. The shopper types the card, sees an error, then types it again into your real form.

  How it shows Often found sooner: shoppers report the odd error, or you notice it while testing your own checkout.

An iframe or a redirect keeps the card form on the processor's side, but your page is still the page around it. The supplement is plain about that: embedding a processor's form “does not completely remove the merchant's embedding page (the parent page) from scope.” Where scripts perform the redirect, the supplement applies 6.4.3 and 11.6.1 to those scripts, and it puts the scripts on a page that embeds the iframe on the merchant's side. And on a single-page app, where the browser never fully reloads, scripts loaded earlier in the visit stay in memory and can reach the embedded form.

What you can do on your own side comes from the supplement's best practices for third-party scripts. Keep checkout pages lean: the fewer scripts on the page that holds the iframe or the redirect, the less there is to attack. Limit where scripts may load from, which a Content Security Policy does with its script-src directive. Move a script you cannot drop into an isolated, sandboxed iframe. Know what each remaining script normally does, so a change stands out.

Supplement quotes and practices: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 (v1.0 r1, April 2025), pp. 5–6, 12, 14, 16, read on 2026-10-22.

What 6.4.3 and 11.6.1 ask of shops on SAQ A-EP or SAQ D

If your checkout builds its own card form, or card data reaches your server, the January change did nothing for you. The Council's supplement lists the forms that carry both requirements: SAQ A-EP, SAQ D for Merchants and SAQ D for Service Providers. Both became mandatory on 31 March 2025, after starting life in PCI DSS v4.0 as best practices.

• Req. 6.4.3Before a script runs: prevent

  • Each script on the payment page is authorized; the standard leaves how, and by whom, to you, and allows sign-off as soon as possible after a third party changes a script.
  • Each script's integrity is assured. No mechanism is mandated; the Council's examples are Content Security Policy and Subresource Integrity.
  • An inventory lists every script with a written reason it is needed. In simple setups, the Council says, a spreadsheet might suffice.

• Req. 11.6.1After a change: detect

  • A change- and tamper-detection mechanism checks the security-impacting HTTP headers and the script contents of the payment page as the shopper's browser receives them.
  • It alerts staff when a header or script newly appears, is changed or is deleted.
  • It runs at least once a week, or at a frequency set by a targeted risk analysis under 12.3.1. The Council recommends frequent or real-time monitoring where feasible.

The 6.4.3 wording, from the Council's Prioritized Approach Tool: “All payment page scripts that are loaded and executed in the consumer's browser are managed as follows,” then the jobs listed above. It covers every script on the payment page that runs in the shopper's browser. It does not cover scripts inside a processor's embedded iframe; those are the processor's job. The supplement adds one carve-out for 6.4.3: scripts from a 3-D Secure provider, used only for 3DS, do not need validating against it, and any other script stays in.

Who owns which script depends on how the checkout is built. The supplement's responsibility table, one setup at a time:

Where you choose a frequency other than weekly for 11.6.1, 12.3.1 asks you to document a targeted risk analysis (assets, threats, likelihood and impact, and why your frequency is enough) and review it “at least once every 12 months.” The supplement warns that a malicious change can sit undetected between checks, whatever the schedule.

Requirement text: Prioritized Approach Tool for PCI DSS v4.0.1, 6.4.3, 11.6.1, 12.3.1. Practice notes: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1, pp. 7–9, 12, 15. Read on 2026-10-22.

What SAQ A still carries: quarterly ASV scans

The 2025 change took script questions out, not scans. SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor's payment page. The Council added them to address common breaches targeting SAQ A merchants: the page that hands the shopper to the processor is itself a target, even though no card data lives on your server.

You cannot run the 11.3.2 scan yourself: merchants “must use only ASVs to perform external vulnerability scans at least once every three months as required by PCI DSS Requirement 11.3.2, and the ASV scan solution must be managed by the ASV.” Medium and High findings (CVSS 4.0 and up) fail; fix them and rescan until a report passes. In the first year you do not need four passing scans if the most recent scan passed, a written policy requires scans at least every three months, and fixes were confirmed by rescan.

Your processor will not do this for you by default. Stripe's FAQ is direct: “Does Stripe provide ASV scanning?” “No. If you need ASV scans, engage a PCI-approved vendor” (Stripe PCI FAQ).

Your processor's compliance is not yours

SAQ A rests on a third party doing the card handling, so the standard asks you to manage that relationship. The rule behind it: “The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity's responsibility for its own PCI DSS compliance.” In practice that means the habits of Requirement 12.8: keep a list of the providers that handle card data or could affect its security (12.8.1), check their PCI DSS status at least once every 12 months (12.8.4), and know which requirements each one manages, which you manage and which you share (12.8.5).

Sources: Prioritized Approach Tool 12.8.1 (applicability notes), 12.8.4, 12.8.5; SAQ Instructions v4.0.1 r1, pp. 2, 10, 15. Read on 2026-10-22.