Redirect to a Third Party? You Still Need ASV Scans: PCI SSC FAQ 1604 Explained

There is a sentence we hear from e-commerce merchants more than almost any other: “We redirect customers to our payment provider, so we do not need vulnerability scans.” It sounds logical. The card details are typed on someone else’s page, the money flows through someone else’s systems, so surely the scanning obligation belongs to someone else too.

It is also wrong, and the PCI Security Standards Council has now said so explicitly. In FAQ 1604, published in June 2026, the Council confirms that external vulnerability scans by an Approved Scanning Vendor (ASV) apply to SAQ A merchants whose webpages redirect to a third-party service provider or embed a provider’s iframe. Outsourcing the payment page does not outsource the scan.

This article explains what the Council said, why the requirement exists, and exactly what a merchant on SAQ A now needs to do about it.

What the Council actually said in FAQ 1604

The question the Council answered is precise: do ASV scans in SAQ A apply to merchants whose webpages redirect transactions to a third-party service provider (TPSP), or whose webpages include a TPSP’s embedded iframe? The answer is yes, and it rests on three points.

• SAQ A for PCI DSS v4.x includes ASV scanning. Requirements 11.3.2 and 11.3.2.1 are part of the questionnaire, even for merchants whose payment processing is fully outsourced.
• The redirect itself is the risk. These requirements were added to SAQ A because a merchant’s webpage can be compromised even when it never touches card data. That includes pages that redirect to a TPSP, pages that redirect through another third-party redirection server which then passes the customer on to the TPSP, and pages that embed the TPSP’s iframe.
• SAQ A responsibility is complete, not partial. A merchant validating with SAQ A is responsible for every requirement in that questionnaire, and ASV scanning is one of them.

The Council also points merchants to its ASV Resource Guide for practical detail on how the scanning programme works.

Why your redirect page matters to an attacker

The reasoning behind the requirement becomes obvious once you think like an attacker. Your webpage may never see a card number, but it decides where your customer goes to type one.

If an attacker compromises the server hosting your website, they do not need to break into your payment provider at all. They can simply change the destination of your “Pay now” button so it sends customers to a convincing fake payment page, harvest the card details there, and then pass the customer along to the real provider so the transaction completes and nobody notices. If your page embeds an iframe, the attacker can swap or overlay that iframe. Either way, the customer believed they were paying you safely, and the weakness that made the theft possible lived in your infrastructure, not your provider’s.

None of this is theoretical. It is a well documented attack pattern with named victims.

• Tupperware (March 2020). Attackers planted a malicious iframe on tupperware.com that displayed a fake payment form at checkout, while the legitimate hosted payment iframe was hidden on the page. Shoppers who entered their card details saw an error message, after which the page reloaded with the genuine form and the purchase completed normally. Malwarebytes documented the attack, which is almost exactly the iframe-swap scenario described above.
• Fake payment page before the redirect. Security firm Sansec has documented skimmers on Shopify, BigCommerce, Zen Cart and WooCommerce stores that inject a counterfeit payment form into the checkout flow before the customer is redirected to the external payment page. After the form is submitted, the victim is shown an error and passed on to the real payment provider, so the order goes through and nothing looks wrong.
• Around 100 Magento stores in one night (April 2026). In a mass campaign, a skimmer hidden inside an invisible SVG element intercepted the checkout click, displayed a full-screen fake “Secure Checkout” overlay complete with a lock icon and real-time card validation, then silently sent the shopper to the real checkout once the details were captured. Sansec’s analysis notes that most victims never notice.

In every one of these cases the payment provider’s own systems were never breached. The weakness was in the merchant’s website, exactly the exposure that Requirements 11.3.2 and 11.3.2.1 are there to catch.

This is the same family of risk that led the Council to add the payment page script requirements we covered in our article on client-side security under Requirements 6.4.3 and 11.6.1. The webpage that hosts or launches the payment journey is part of the attack surface, whoever processes the card. An unpatched content management system, an exposed administration panel, or a vulnerable plugin on that page is a direct path to payment fraud, and external vulnerability scanning is the control that finds those weaknesses before an attacker does.

What Requirements 11.3.2 and 11.3.2.1 require

The two requirements in question are straightforward to state.

• Requirement 11.3.2: external vulnerability scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor, vulnerabilities are resolved and the ASV Program Guide requirements for a passing scan are met, and rescans are performed as needed to confirm the fixes.
• Requirement 11.3.2.1: external scans are also performed after any significant change to the environment, with vulnerabilities scored 4.0 or higher by CVSS resolved and rescans run as needed.

Three practical points matter here. First, the scan must come from a genuine ASV: a company listed on the PCI SSC website and using its approved scan solution. An ordinary vulnerability scanner run by your IT provider, however competent, does not satisfy the requirement. Second, “at least once every three months” is a floor, and a failed scan is not a completed obligation: you remediate and rescan until you achieve a passing result. Third, a significant change (a new server, a re-platformed website, a major upgrade) triggers a scan regardless of where you are in the quarterly cycle.

What is in scope for the scan

For a SAQ A merchant, the scan targets the internet-facing infrastructure that delivers the webpages involved in the payment journey: the systems that host the pages which redirect customers to the provider or serve the page containing the provider’s iframe. In practice that usually means the public IP addresses and domains of your website hosting environment.

A few situations deserve care.

• Third-party hosted websites. If your website runs on a hosting provider or e-commerce platform, the infrastructure may be scanned under their programme, but you need to confirm that and understand what their responsibility covers. Hosting arrangements do not automatically discharge your SAQ A obligations.
• Multiple redirection hops. The Council’s FAQ explicitly covers pages that redirect to another third-party redirection server before reaching the TPSP. If your checkout flow chains through intermediate services, the webpage that starts that chain is still yours to secure.
• Forgotten assets. Old subdomains, staging sites, and abandoned landing pages that still reference your checkout are easy for attackers to find and easy for merchants to forget. Your scan scope should reflect what is actually exposed to the internet, not what the network diagram says.

The wider lesson: outsourcing narrows your obligations, it does not remove them

The ASV question is one instance of a pattern we see constantly. Merchants hear “fully outsourced” and conclude “fully exempt”. The reality is that outsourcing card handling to a compliant provider dramatically narrows your PCI DSS footprint, which is exactly why we recommend it, but the questionnaire that remains is still a real obligation with real controls in it.

Under the current SAQ A, alongside ASV scanning, you retain duties around things like secure passwords for the systems you control, managing your provider relationships, and confirming your eligibility for the questionnaire in the first place. The January 2025 revision of SAQ A, which we explain in our client-side security article, added an eligibility criterion about script attacks precisely because the merchant webpage remains a live part of the risk picture. FAQ 1604 continues the same theme: the Council is telling merchants, plainly, that a webpage in the payment journey is never “someone else’s problem”.

If you are unsure what your questionnaire actually asks of you, our overview of the PCI DSS v4.0.1 requirements now in force and our PCI DSS services hub are good places to start, and your acquirer has the final say on which SAQ applies to you.

What to do now: a short checklist

1. Confirm your validation route. If you complete SAQ A (or your acquirer requires it), Requirements 11.3.2 and 11.3.2.1 apply to you.
2. Identify the internet-facing systems that host your redirect or iframe pages, including any forgotten subdomains and staging environments.
3. Engage an Approved Scanning Vendor from the official PCI SSC list. Confirm the scan solution they will use is their approved one.
4. If your site is hosted by a platform or agency, obtain written clarity on who scans what, and keep the evidence.
5. Run the first scan, remediate anything scored 4.0 or higher under CVSS, and rescan until you pass.
6. Diarise quarterly scans, and add a trigger to your change process so significant changes prompt an additional scan.
7. Retain passing scan reports with your Attestation of Compliance; your acquirer may request them.

Frequently asked questions

We fully redirect to our payment provider. Do we really need ASV scans?

Yes. PCI SSC FAQ 1604 confirms that SAQ A for PCI DSS v4.x includes external vulnerability scanning under Requirements 11.3.2 and 11.3.2.1, and that this applies to merchants whose webpages redirect to a third-party provider, redirect through an intermediate redirection server, or embed the provider’s iframe. The page that sends your customer to the payment provider is part of the payment journey and can be compromised, so it must be scanned.

Can our IT company run the scan instead of an ASV?

No. The requirement specifically calls for scans by a PCI SSC Approved Scanning Vendor using their approved scan solution. Internal scans by your own team or a general IT provider are good practice, but they do not satisfy Requirement 11.3.2. The current list of ASVs is published on the PCI SSC website.

How often do the scans need to run, and what counts as passing?

At least once every three months, plus after any significant change to your environment. A passing result must meet the ASV Program Guide criteria, which include resolving vulnerabilities scored 4.0 or higher under CVSS. A failed scan means remediating and rescanning until you achieve a pass, not filing the report and waiting for next quarter.

Our website is hosted by a third party. Whose job is the scan?

Responsibility for the SAQ A requirement stays with you, but the scanning itself may be covered by your hosting provider or platform if they scan the infrastructure that serves your pages. Do not assume: ask the provider exactly what is scanned and by whom, get it in writing, and make sure the arrangement genuinely covers the systems delivering your redirect or iframe pages.

How Cianaa can help

Cianaa is an independent PCI QSA practice serving businesses across New Zealand and Australia. We help merchants confirm the right SAQ, define an accurate scan scope, work with ASVs, and close out remediation so the quarterly cycle runs without drama. If FAQ 1604 has changed your understanding of your obligations, talk to our assessors and we will give you a straight answer on where you stand.