SAQ A (PCI DSS): Who Qualifies and What It Asks

Short answer: SAQ A is the shortest PCI DSS self-assessment for online stores. You qualify only if your payment provider handles all card data and every part of the card form comes straight from that provider, usually by redirect or iframe. The current form, SAQ A r1, has 27 requirements by our count, including quarterly ASV scans.

Dated update: checked against PCI SSC documents on 29 October 2026. Two FAQs changed in 2026: FAQ 1604 on ASV scans (June 2026) and FAQ 1331 on using SAQ criteria in a Report on Compliance (August 2026). We will update this page when PCI SSC publishes a new SAQ A revision or a new FAQ that changes it.

This guide is for small and mid-size online stores, with WooCommerce examples. It explains who can use SAQ A, what is inside the form, how it differs from SAQ A-EP and SAQ D, and what you actually have to do each year. It is general information, not a PCI assessment. Your acquirer, and a Qualified Security Assessor (QSA) if you use one, has the final word on which SAQ you use.

What is SAQ A?#

SAQ A is a Self-Assessment Questionnaire published by the PCI Security Standards Council (PCI SSC) for merchants that have handed all card handling to a compliant provider. The form's own definition, from PCI DSS v4.0.1 SAQ A r1 (January 2025):

"Self-Assessment Questionnaire (SAQ) A includes only those PCI DSS requirements applicable to merchants with account data functions completely outsourced to PCI DSS validated and compliant third parties, where the merchant retains only paper reports or receipts with account data."

The same page says SAQ A merchants "may be either e-commerce or mail/telephone-order merchants (card-not-present)", and that the SAQ "is not applicable to face-to-face channels" and "is not applicable to service providers".

A completed SAQ comes with an Attestation of Compliance (AOC), the signed summary your acquirer or payment provider asks for. "SAQ A form" usually means this whole package: Section 1 (contact details and executive summary, Parts 1 and 2 of the AOC), Section 2 (the questionnaire) and Section 3 (validation and attestation, Parts 3 and 4 of the AOC).

Who is eligible for SAQ A?#

You are eligible only if every criterion below is true for the payment channel you are assessing. The wording is from SAQ A r1; the right-hand column is our plain-English reading for an online store.

If any one of them is false, SAQ A is not the right form. The form says so itself: if PCI DSS requirements apply to your environment that SAQ A does not cover, "it may be an indication that this SAQ is not suitable for the merchant's environment."

Criterion 7 is the newest. It replaced requirements 6.4.3 and 11.6.1 in the January 2025 revision, and it is the one most WooCommerce stores have not thought about.

What changed for SAQ A in 2025 and 2026?#

Six dated events matter, all from PCI SSC's own pages:

The 30 January 2025 post was clear that the change does "not remove or diminish the underlying requirements within PCI DSS." In other words, the script risk did not go away. It moved from the questionnaire into the eligibility test.

We found no PCI SSC announcement of a new SAQ A revision or a new PCI DSS version on the PCI SSC blog as of 29 October 2026. If you read a vendor article that says SAQ A changed again in 2026, check whether it means the two FAQs above.

SAQ A vs SAQ A-EP vs SAQ D: which one applies?#

The difference is who builds the card form your shopper types into.

SAQ A-EP's own definition (v4.0, April 2022) is for "e-commerce merchants with a website(s) that does not itself receive account data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the customer's account data." One of its criteria shows the line between the two: in A-EP, "each element of the payment page(s) delivered to the customer's browser originates from either the merchant's website or a PCI DSS compliant TPSP." In SAQ A, every element must come from the provider.

For scale, Stripe's integration security guide says a business that handles card data directly "might be required to meet more than 300 security controls in PCI DSS." That is why the integration you choose matters more than any later paperwork.

How we counted: we listed every numbered requirement row in Section 2 of SAQ A r1 (27) and every unique numbered requirement in Section 2 of the PCI SSC-hosted SAQ A-EP v4.0 PDF (139, which we round to about 140 because layout can split rows). The v4.0.1 A-EP form may differ slightly; check the current one in the Document Library.

Which SAQ fits my WooCommerce checkout?#

This table is our reading of the SAQ criteria for common WooCommerce setups. It is not a QSA opinion, and your provider's own documentation and your acquirer decide. Use the right-hand column as the question to ask.

Two traps we see often on WordPress stores:

1. A plugin that "saves cards" on your site. If card numbers are stored in your database, you are not eligible for SAQ A. Saved cards should be tokens held by the provider.
2. A custom checkout field that asks for card details (for example, a "pay later, enter your card here" field added with a form plugin). That puts card data on your server and moves you out of SAQ A.

What does SAQ A actually ask?#

SAQ A r1 has 27 requirement rows by our count, across seven PCI DSS principal requirements. For each one you answer In Place, In Place with CCW (a compensating control), Not Applicable (with an explanation in Appendix C) or Not in Place.

The form says requirements 2, 6, 8 and 11 apply to the merchant webpage "upon which the redirection mechanism is located" or that "includes a TPSP's/payment processor's embedded payment page/form". For a WooCommerce store, that is your WordPress site. So the patching, login and scanning rows are about your WordPress server, not about Stripe or PayPal.

If you have no paper with card data at all, the rows under requirements 3 and 9 are usually Not Applicable, with an explanation in Appendix C.

How do I meet the script criterion?#

FAQ 1588 (February 2025) answers this. First, who it applies to:

"The above SAQ A eligibility criteria only applies to e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes))."

It does not apply to a full redirect ("an HTTP 30x redirect, a meta redirect tag, or a JavaScript redirect") or to merchants that fully outsource payment, for example by emailing a pay link.

Then, two ways to confirm your page "is not susceptible to script attacks":

1. Route 1, your own controls. "Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant's webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party."
2. Route 2, your provider's confirmation. "Obtaining confirmation from the merchant's PCI DSS compliant TPSP/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP's/payment processor's instructions, the TPSP's/payment processor's solution includes techniques that protect the merchant's payment page from script attacks."

FAQ 1588 also says a company that only supplies scripts "not related to payment processing", which "cannot impact the security of cardholder data", is not a TPSP for SAQ A. So your analytics vendor does not become a payment provider just because its script is on your checkout. But its script is still on the page, which is exactly what route 1 is about.

Route 2 is cheaper if you can get it. Ask your provider for a written statement in those terms and keep it with your SAQ. If the provider will not give one, route 1 is what is left. For what 6.4.3 and 11.6.1 ask in detail (a script inventory with written reasons, integrity checks, and change alerts at least weekly or at the frequency your risk analysis sets), see our guide to PCI DSS 6.4.3 and 11.6.1 for WooCommerce.

Do SAQ A merchants need ASV scans?#

Yes, if you have a webpage that redirects to a provider or embeds a provider's iframe. FAQ 1604 (June 2026) answers the question directly:

"Yes. SAQ A for PCI DSS v4.x includes requirements for external vulnerability scanning by a PCI SSC Approved Scanning Vendor (ASV) for merchant e-commerce webpages, even where payment processing is fully outsourced to a third party."

It explains why: requirements 11.3.2 and 11.3.2.1 "were added to SAQ A to address risks where a merchant's webpage could be compromised and thereby result in compromise of the payment process." It covers pages that redirect to a provider (or to another redirection server that then redirects) and pages that include a provider's iframe (or an iframe that includes another provider's iframe).

What 11.3.2 asks, from SAQ A r1:

• scans "at least once every three months",
• by a "PCI SSC Approved Scanning Vendor (ASV)",
• vulnerabilities resolved until the scan passes, with rescans as needed.

For your first assessment, the form says four passing scans in 12 months are not required if the latest scan passed, you have a documented policy to scan every three months, and findings were fixed. After the first year, passing scans "at least every three months must have occurred."

Ask your acquirer or payment provider whether its compliance program includes ASV scanning before you buy one separately. FAQ 1604 says the ASV must be listed as an Approved Scanning Vendor on the PCI SSC website.

How do I complete SAQ A, step by step?#

The form lists five completion steps. Here they are with what each looks like for a WooCommerce store.

1. Confirm SAQ A is right. Check the seven criteria above against your real checkout, including every payment plugin that is active, not just the main one. Open the checkout in a private window and look at where each card field comes from.
2. Scope your environment. Write down which systems are in scope: your WordPress web server and anything that can change the checkout page (hosting control panel, deployment tool, CDN settings, tag manager).
3. Assess each requirement. Go through the 27 rows. Gather evidence as you go: a screenshot of user accounts, your update log, your password policy, your ASV scan reports, your provider list.
4. Complete all sections. Section 1 (AOC Parts 1 and 2), Section 2 (the questionnaire), Section 3 (AOC Parts 3 and 4). Add Appendix C explanations for every Not Applicable answer.
5. Submit to whoever asked. The form says to submit the SAQ and AOC, with any other requested documents "such as ASV scan reports", to "the requesting organization", which the form describes as "those organizations that manage compliance programs such as payment brands and acquirers".

Then put a reminder in your calendar. Stripe's security guide says merchants must "annually attest" to PCI compliance, and the ASV scans and the provider compliance check (12.8.4, "at least once every 12 months") recur through the year.

Where do I get the SAQ A form?#

From the PCI SSC Document Library (opens in a new tab), filtered to SAQs. The library asks you to accept a licence agreement before a PDF downloads, so direct links to the PDF often fail. The current version is "PCI DSS v4.0.1 SAQ A r1", publication date January 2025.

If your provider or acquirer has a compliance portal, it may walk you through the same questions online and file the result for you. That is often easier, but check that the portal uses the r1 version with the script criterion.

What about large merchants and FAQ 1331?#

FAQ 1331 (updated August 2026) is for merchants that are assessed with a Report on Compliance (ROC), usually larger merchants, rather than an SAQ. It says SAQs "should not be used as a 'guide' for determining the applicability of PCI DSS requirements unless explicitly reviewed, discussed and agreed upon with the merchant's compliance accepting entity (e.g., payment brands and acquirers)."

For a small store filing SAQ A this changes nothing. If a QSA assesses you with a ROC, do not assume that "we would qualify for SAQ A" lets you skip requirements; agree it with your acquirer in writing.

Common SAQ A mistakes on WooCommerce stores#

1. Ignoring the second payment plugin. A store passes on Stripe iframes, then adds a "buy now, pay later" or a legacy gateway that builds its own card form. The channel is no longer SAQ A.
2. Shared admin logins. "admin" used by three people fails 8.2.1 and 8.2.2.
3. Slow plugin updates. Requirement 6.3.3 wants critical patches within one month. Abandoned plugins with known holes are a problem here.
4. No ASV scans, on the belief that iframes take you out of scope. FAQ 1604 says otherwise.
5. No incident response plan. 12.10.1 needs a written plan that names who calls the acquirer and payment brands.
6. Ticking criterion 7 with no evidence. If you cannot show either a provider confirmation or your own script controls, you have not "confirmed" anything.
7. Thinking a plugin or a badge makes you compliant. No tool answers the questionnaire for you, and using a compliant provider does not make you compliant: SAQ A's note on 12.8.1 says it does not remove your own responsibility.

Where ChargeWarden fits, and where it does not#

ChargeWarden helps with route 1 of the script criterion. Its payment page script monitor lists every script on your checkout and pay for order pages (from WordPress, from shoppers' browsers and from a daily scan), asks you to authorize each with a written reason, hashes them, and emails you when a script appears or changes. It also records the checkout page's security headers and exports a CSV you can keep as evidence with your SAQ.

What it does not do:

• It does not make your store PCI DSS compliant and it is not a QSA assessment.
• It is not an ASV and does not run the quarterly external scans 11.3.2 requires.
• It cannot see inside your provider's iframe or hosted page. Your provider is responsible for those.
• It records and alerts; it does not block scripts.

The same plugin also stops card testing on the WooCommerce checkout and Store API and scores every order, which is the fraud side of running card payments. See it working on the live demo, read the getting started guide, or buy ChargeWarden.

Related: PCI DSS 6.4.3 and 11.6.1 for WooCommerce, WooCommerce card testing and AVS mismatch explained.

This guide is general information, not a PCI DSS assessment or legal advice. Quotations are from PCI SSC documents as checked on 29 October 2026. PCI DSS is a trademark of the PCI Security Standards Council, LLC. Stripe, PayPal and WooCommerce are trademarks of their owners. PluginLoom is not affiliated with or endorsed by any of them.