ASV Scans for SAQ A Merchants: Not New, Still Overlooked

Most merchants running a redirect or embedded iframe checkout assume vulnerability scanning is someone else's job. That assumption used to be closer to true. It hasn't been true since PCI DSS v4.0 came into effect, and PCI SSC just published a FAQ reminding the industry of exactly that.

FAQ 1604 answers a question directly: 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. Nothing about that answer is new. Requirements 11.3.2 and 11.3.2.1 have been part of SAQ A since v4.0. What's new is that PCI SSC felt the need to spell it out again, which tells you something about how many merchants still haven't caught up.

This Isn't a New Rule. It's a Reminder

Under PCI DSS v3.2.1, SAQ A was the lightest-touch questionnaire available. Redirect to a hosted payment page, use a third-party iframe, never touch card data on your own systems, and you were largely exempt from scanning obligations. That's exactly why SAQ A was so attractive: it avoided most of the operational overhead of compliance.

PCI DSS v4.0 added Requirements 11.3.2 and 11.3.2.1 to SAQ A specifically to address risks where a merchant's webpage could be compromised and thereby result in compromise of the payment process. That change has been in place for a while now, not something announced last month. The reasoning isn't abstract. Magecart-style skimming attacks don't touch the payment processor's systems at all. They compromise the merchant's own website, inject a malicious script, and intercept or redirect payment data before it ever reaches the outsourced payment page. Outsourcing the transaction doesn't remove that attack surface. The vulnerable part is the webpage the customer visits first, not the page where they type their card number.

Merchants with e-commerce webpages that complete SAQ A, even where payment processing is outsourced to TPSPs, still have responsibility for the PCI DSS requirements included in SAQ A, including the requirements for ASV scanning. The FAQ names two common setups explicitly:

• Merchants whose webpages redirect transactions to a third-party service provider, or to another redirection server which then redirects to a TPSP.
• Merchants whose webpages include a TPSP's embedded iframe, or an iframe that itself includes another TPSP's iframe.

If you have a webpage at all, even one that does nothing but redirect or host an iframe, you're in scope for external ASV scanning. That's been true since v4.0 took effect, not since this FAQ was published.

Why This Still Catches Merchants Off Guard

Small merchants are often surprised, and frustrated, to learn this applies to them, even years into the v4.x transition. The logic has always been simple: no stored card data, no processed card data, so PCI DSS isn't really their problem. SAQ A reinforced that logic for years under earlier versions. What FAQ 1604 does is close a gap between that old logic and the current rules, a gap that's been sitting there since v4.0 without enough merchants noticing.

For merchants who've been completing SAQ A without ASV scanning, this isn't a future obligation to plan for. It's one they may have already been out of compliance with. FAQ 1604 exists precisely because assessors, acquirers, and merchants themselves kept asking the Council to put it in writing, likely after running into the same confusion repeatedly.

What the Requirement Actually Involves

ASV scans performed to satisfy PCI DSS Requirement 11.3.2 must be carried out by a PCI Approved Scanning Vendor listed on the PCI SSC website, using that vendor's ASV scan solution. Not just any vulnerability scanner, and not a self-run open-source tool. In practice, this means:

• Quarterly external scans of the internet-facing webpage, run by an approved ASV.
• Passing scan results, or a documented remediation cycle until a passing scan is achieved.
• Rescanning after any significant change to the webpage.

PCI SSC also points merchants to its two-page ASV Resource Guide, created back in 2024, to explain how the requirement applies to merchants completing SAQ A. It's been available for a while. Worth five minutes before you talk to a scanning vendor.

The Cost Is Real. The Complexity Usually Isn't

There's no getting around it: for a merchant who's been running SAQ A without ASV scanning, catching up means a new line item. ASV scanning isn't free, and for a small business already absorbing payment processing fees, acquiring fees, and PCI SAQ overhead, one more recurring cost is a legitimate concern. Merchants tell us this directly. The reaction is rarely "that makes sense." It's usually "that's one more thing."

The operational lift, though, is smaller than the reputation of ASV scanning suggests. Modern ASV platforms are built for exactly this scenario: a single external webpage, no internal network to map, automated quarterly scheduling, remediation guidance that doesn't require a security team to interpret. For a merchant with a simple redirect or iframe checkout, running the scan is often a matter of pointing the tool at a domain and letting it run. Not the multi-day network security exercise larger enterprises go through. The cost is real. The complexity, for most small merchants, isn't.

What to Do Now

If you're completing SAQ A and haven't been running ASV scans, this isn't a wait-and-see item. It should have started when your SAQ A moved to v4.x:

1. Confirm your SAQ A version reflects PCI DSS v4.x and includes Requirements 11.3.2 and 11.3.2.1.
2. Choose a vendor from the PCI SSC's list of Approved Scanning Vendors.
3. Schedule your first external scan and build a quarterly cadence around it.
4. Keep evidence of passing scans, or remediation records, alongside your SAQ documentation.

A redirect or embedded iframe checkout still meaningfully reduces PCI DSS scope compared to handling card data directly. That hasn't changed. What's changed, or rather what FAQ 1604 makes impossible to miss, is the assumption that reduced scope means zero external obligations. The requirement has been on the books since v4.0. The webpage is yours, so securing and scanning it is too.