Does SAQ A Require Quarterly ASV Scans? Yes, Here's What Changed in PCI DSS v4.x

If you run an ecommerce store on Shopify, WooCommerce, or a custom site that redirects checkout to Stripe or PayPal, you have probably been told some version of this: "You're SAQ A. You fully outsource payments. You don't need vulnerability scans."

That advice was correct under PCI DSS v3.2.1. Under PCI DSS v4.x (v4.0 and v4.0.1), it is wrong, and following it leaves you non-compliant.

The short answer: yes, SAQ A merchants must perform quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) under PCI DSS Requirement 11.3.2, at least once every 90 days.

This is one of the most misunderstood points in all of PCI, and the confusion is entirely a product of how the standard changed between versions. This post explains exactly what changed, why fully-outsourced stores are now in scope, and what you actually need to do.

What Requirement 11.3.2 Says

PCI DSS Requirement 11.3.2 mandates external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV), a vendor specifically authorised by the PCI Security Standards Council to run these scans. The core obligations:

• Frequency: at least once every three months (90 days), and after any significant change to your internet-facing infrastructure.
• Scope: all external-facing (internet-reachable) systems in your card data environment, for most SAQ A merchants this is the web server that hosts your storefront and checkout page.
• Passing criteria: the scan must produce a passing result, generally no vulnerabilities rated CVSS 4.0 or higher, and no automatic-fail conditions. Anything in the medium (4.0 to 6.9) or high (7.0 to 10.0) range blocks a passing scan until it is remediated or successfully disputed.

Why the Confusion Exists: A Version-History Problem

Almost every piece of "SAQ A doesn't need scans" advice you'll find online is not wrong so much as out of date. Here's the actual timeline.

PCI DSS v3.2.1: SAQ A Had No ASV Requirement

Under the previous standard, SAQ A genuinely did not include external vulnerability scanning. The logic was straightforward: a merchant who fully outsourced their payment page to a compliant third party had no payment infrastructure of their own to scan. The scan requirement (then numbered 11.2.2) simply did not appear on the SAQ A form.

This is the source of the myth. A huge volume of blog posts, forum answers, and even some processor guidance was written during the v3.2.1 era and still circulates today.

PCI DSS v4.0: ASV Scanning Added to SAQ A

PCI DSS v4.0 significantly expanded SAQ A, growing it from roughly two dozen requirements to around 31. Among the additions was Requirement 11.3.2, quarterly ASV external scans, which became applicable to SAQ A merchants for the first time.

Why the change? Because the original assumption no longer held. Attackers spent years demonstrating that "fully outsourced" ecommerce stores were anything but safe: Magecart-style skimming attacks compromise the merchant's own web pages, the very pages that load the third-party payment form, to steal card data in the browser before it ever reaches the processor. The merchant's web server is an attack surface, and v4.0 brought it back into scope.

January 2025 SAQ A Revision: Scanning Stayed, Scripts Changed

In January 2025, the PCI SSC published a revised SAQ A in response to merchant feedback about the difficulty of the new payment-page script controls. This revision removed three requirements from SAQ A: 6.4.3 (script inventory and integrity), 11.6.1 (payment-page change/tamper detection), and 12.3.1 (the supporting risk analysis), and replaced them with a self-attestation eligibility criterion.

So the net effect for SAQ A merchants as of the March 31, 2025 mandatory date: you no longer have to maintain a formal script inventory under 6.4.3/11.6.1 to file SAQ A, but you do still owe a passing quarterly ASV scan.

"But I Fully Outsource Checkout: How Am I in Scope?"

This is the fair question. The answer is that the page that loads the payment form is itself in scope, even when the form is hosted by Stripe, Shopify, or PayPal.

The PCI SSC's own guidance is explicit that the ASV scanning requirement in SAQ A applies to the merchant system(s) that host the webpage which either:

1. Redirects the customer to a PCI DSS compliant third-party processor, or
2. Embeds a payment page/form from a compliant processor (an iframe).

In practice, that means your storefront's web server. If a customer ever loads a page on your domain on the way to paying, and they do, that server is internet-facing and in scope for 11.3.2.

SAQ A-EP and SAQ D: Always Required

For completeness, and because mis-classification is a major driver of confusion:

• SAQ A-EP (your site controls how the payment page loads, even though a third party processes the card, e.g. a direct-post or JavaScript integration on your own page): ASV scans have always been required, under both v3.2.1 (11.2.2) and v4.x (11.3.2). SAQ A-EP also still carries the 6.4.3 and 11.6.1 script requirements.
• SAQ D (card data touches your environment directly): the most comprehensive SAQ; includes 11.3.2 and essentially every other requirement.

A great deal of "do I need scans?" confusion is really SAQ A vs SAQ A-EP confusion. The two sound nearly identical but have very different scope. If you are not certain which one you file, that is the first thing to resolve, as it changes everything downstream.

Three Reasons Smart People Get This Wrong

1. Stale guidance. Pre-2022 content written under v3.2.1 still dominates search results and says "SAQ A = no scans."
2. SAQ A vs A-EP conflation. Merchants assume they're SAQ A when their integration actually puts them in A-EP, or vice versa.
3. The January 2025 headlines. "Requirements removed from SAQ A" was read as "SAQ A got easier / scanning dropped." Only the script requirements were removed; scanning stayed.

There's also a fourth, orthogonal reason: many acquiring banks and payment processors contractually require ASV scans from all ecommerce merchants regardless of SAQ type. So some merchants received scan requests for years and assumed it was a bank quirk, when in fact, under v4.x, it's now baseline PCI.

What You Actually Need to Do

1. Confirm your SAQ type. SAQ A (redirect/iframe to a compliant processor) vs SAQ A-EP (your page controls the payment form) vs SAQ D. This determines your full obligation set, not just scanning.
2. Engage an ASV. Only scans from a PCI SSC Approved Scanning Vendor satisfy 11.3.2. A generic vulnerability scanner is not an ASV scan.
3. Identify your external scope. The domains, IPs, and internet-facing systems that serve your storefront and checkout.
4. Scan at least every 90 days, and after significant infrastructure changes, and remediate to a passing result (no CVSS 4.0+ findings).
5. Retain the passing scan reports as evidence for your annual SAQ and for any processor or bank request.

Where CyberShield Studio Fits

We built CyberShield Studio specifically for SME merchants navigating exactly this kind of moving target, where the rules changed, the old advice is wrong, and there's no security team in-house to catch it.

• Start free: our Website Security Checker flags external risk signals on any merchant URL, and the SAQ Readiness tool helps you confirm where you stand, no account required.
• Our PCI Compliance Readiness Platform runs your recurring vulnerability scans, keeps the passing results on file, and manages your evidence and documentation month over month.
• For complex scope (SAQ A-EP, SAQ D, or a remediation backlog), our consultancy maps your environment and gets you audit-ready.

For the related payment-page script requirements that still apply to SAQ A-EP and SAQ D, see our companion post: PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1.

Summary

Under PCI DSS v4.x, SAQ A merchants must perform a passing quarterly ASV external vulnerability scan (Requirement 11.3.2). The "SAQ A means no scans" belief is a leftover from v3.2.1, accurate then, wrong now. v4.0 added the requirement, and the January 2025 SAQ A revision kept it even while removing the script-management mandates.

If you accept cards online and haven't run an ASV scan in the last 90 days, treat that as your most urgent open item. Start by confirming your SAQ type, as everything else follows from knowing which form you actually file.