What PCI ASV Scans Require
On 1 April 2025, a class of online merchants that had never run an external vulnerability scan inherited a quarterly one.
Under PCI DSS v4.0.1, SAQ A merchants whose checkout embeds or redirects to a third party's payment form now fall under Requirement 11.3.2. Many of them still attest as if nothing changed. The first they hear of it is a submission bounced back by their acquirer.
Here is what trips teams up: an ASV scan is pass or fail, and the line is not generous. Under the ASV Program Guide, a single vulnerability scored 4.0 or higher on CVSS fails the whole scan. Not just critical. Not just high. Medium fails it too. PCI DSS v4.0.1 requires this scan at least once every three months, and the result has to be a passing one, confirmed by rescan. Running a scanner is not the control. Producing a passing report is.
Three tests a passing scan must clear
A scan becomes a passing scan only when it clears three separate tests. Operators tend to satisfy one, assume they have met all three, and find out otherwise at submission. Understanding why each test exists is what keeps you out of that position.
The first test is the vendor. Only a company on the PCI SSC List of Approved Scanning Vendors can run the quarterly scan and issue the attestation an acquirer will accept. An internal Nessus instance, an OpenVAS box, or your own Qualys licence does not satisfy Requirement 11.3.2, no matter how capable the tooling is. The reason is independence and consistency: an ASV passes an annual remote test against PCI SSC's own deliberately vulnerable infrastructure, so a passing report means the same thing whoever issued it. Check the legal entity name, because vendors often appear on the list under a parent company you will not recognise.
The second test is the pass line. Every vulnerability scored 4.0 or higher on CVSS has to be remediated or formally disputed before the report passes. Some findings fail automatically regardless of score, including detected backdoors, malware, and unsupported software. Pure denial-of-service findings, where CVSS confidentiality and integrity impact are both "none," are the narrow exception the Program Guide carves out. The line sits at medium severity, not high, because an externally reachable medium is something an attacker can find from the open internet without effort. That is the whole point of an external scan.
The third test is the scope, and this is the one you own, not the vendor. Every public IP routed to your in-scope environment and every URL pointing at those IPs must be in the scan. Miss a subdomain, a stale cloud IP, or a new CDN endpoint and the scan can still come back passing, while the report quietly fails to reflect reality. A clean scan of the wrong scope is more dangerous than a failing scan of the right one, because it reads as compliant right up until someone looks closely.
It also helps to know what the deliverable looks like before it arrives. A compliant ASV report is three documents, not one: an Attestation of Scan Compliance that states whether you passed, a Scan Report Summary listing findings by component, and the full Vulnerability Details. Acquirers and assessors read all three. A vendor-issued "pass certificate" outside the PCI SSC templates is supplemental and does not stand in for the required report. Where a finding looks vulnerable from the outside but is not, such as a backported patch or a compensating control, you dispute it directly with your ASV, not the PCI SSC, and you keep the evidence.
Why a clean scan still gets rejected
The failure mode is rarely a breach. It is a stalled attestation. A merchant submits, the acquirer reads the ASV report, the scope looks incomplete or a finding is unresolved, and the submission goes back. Card processing privileges depend on that attestation clearing, so a rejected report is an operational problem, not a paperwork one.
The newly exposed SAQ A population feels this hardest. If your site embeds an iframe or redirects to a hosted payment page, the 1 April 2025 change likely moved you under 11.3.2 for the first time. Fully outsourced merchants, where cardholder data never touches your systems, may still be exempt, but that is a question for your acquirer, not an assumption to carry into a renewal.
There is a second gap worth understanding, because most teams walk straight into it. Requirement 11.3.2.1 calls for an external scan after any significant change: new infrastructure, firewall rule changes, network topology shifts. That scan does not need an ASV, only qualified personnel with organisational independence and the same 4.0 threshold. Teams that deploy continuously but scan only at quarter-end can sit out of compliance for weeks without realising it. Compliance here is not a date on a calendar. It is triggered by how your environment changes.
Building a scan cycle that holds up
Confirm your SAQ type with your acquirer in writing. If your checkout embeds or redirects to a third party's payment form, ask directly whether 11.3.2 now applies to you. Do not infer it.
Draw your own external scope before the vendor does. List every public IP routed to the in-scope environment and every URL pointing at them. Over-scope on the first pass, because trimming a scope is easier than explaining an omission after the report ships.
Verify your vendor on the PCI SSC ASV list by legal entity name. If the name is not on the list, the attestation will not hold, regardless of the scanner behind it.
Book the scan early in the cycle. A failing scan you fix on day 89 still needs a passing rescan inside the same 90 days. Leave remediation room before the window closes.
Wire scan-after-significant-change into change management. Make the 11.3.2.1 scan a step that must complete before a change is marked done. That scan can run on a qualified internal resource, but it has to run.
Before your next attestation
The SAQ A merchant whose renewal bounced did everything they had done the year before. The rules moved under them. That is the transferable lesson, and it reaches well past PCI: last year's answer is not automatically this year's answer, and the cheapest moment to confirm scope and applicability is before you attest, not after a rejection. A passing ASV scan is a specific artifact, issued by a vendor on one specific list, clean of every finding at CVSS 4.0 and above, and run against a scope you are responsible for drawing. Get one of those three wrong and you have a scan, not a passing scan. The single decision worth making before your next attestation is the simplest one: confirm, in writing, whether Requirement 11.3.2 applies to you at all.
Sources
Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1, PCI Security Standards Council (June 2024). https://www.pcisecuritystandards.org/document_library/
Approved Scanning Vendors (ASV) Program Guide, PCI Security Standards Council. https://www.pcisecuritystandards.org/document_library/
FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants, PCI Security Standards Council Blog (28 February 2025). https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants
List of Approved Scanning Vendors, PCI Security Standards Council. https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors/
Self-Assessment Questionnaire A and Attestation of Compliance, PCI DSS v4.0, PCI Security Standards Council. https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-A.pdf
Disclaimer
This article is provided for general informational and educational purposes only and does not constitute legal, regulatory, or compliance advice. PCI DSS requirements, SAQ eligibility criteria, and ASV Program Guide provisions are subject to revision by the PCI Security Standards Council, and their application depends on your specific environment, merchant level, and acquirer arrangements. Organisations should validate their scanning obligations and scope directly with their acquiring bank, a Qualified Security Assessor, or the PCI Security Standards Council before relying on any statement in this article. AKATI Sekurity accepts no liability for actions taken on the basis of this content.
Frequently Asked Questions
The practical answers behind a passing external scan: who can run it, what clears the line, and when the obligation applies to you.
A passing scan has no vulnerabilities scored 4.0 or higher on CVSS and no automatic-failure conditions, confirmed by a rescan after any remediation. The ASV issues a formal attestation only once those criteria are met.
Only a vendor on the PCI SSC List of Approved Scanning Vendors can run the quarterly scan and issue a compliant attestation. Internal scanners such as Nessus, OpenVAS, or a private Qualys instance do not satisfy Requirement 11.3.2.
At least once every three months, and again after any significant change to your external environment. The quarterly scan must be performed by an ASV; the significant-change scan under 11.3.2.1 can be run by qualified internal personnel.
As of 1 April 2025, SAQ A merchants whose sites embed or redirect to a third party's payment form generally fall under Requirement 11.3.2. Fully outsourced merchants where cardholder data never touches their systems may be exempt, but should confirm with their acquirer.
No. For an initial assessment, the requirement is met if the most recent scan is passing, a documented policy requires scanning at least every three months, and any findings were corrected as shown in a rescan. Subsequent years require passing scans at least every three months.
