What Is a PCI ASV Scan? Pass, Fail and Rescan

What the scan is, and what it looks at

An ASV scan is the vulnerability scan PCI DSS asks for from the outside. PCI DSS 11.3.2 requires external vulnerability scans at least once every three months by an ASV approved by PCI SSC. The Council's glossary defines an Approved Scanning Vendor as a “Company approved by the PCI SSC to conduct external vulnerability scanning services.” The scanner looks at your business the way an attacker on the internet would: open ports, old software, weak encryption, web pages that leak or accept more than they should.

What it covers is set in the ASV Program Guide: “all externally accessible (Internet-facing) system components owned or utilized by the scan customer that are part of the cardholder data environment (CDE), as well as any externally facing system component that may provide access to the CDE.” For a small shop that can mean the website, the mail server, the office router's public address and any remote-access door into the back office.

The list is yours to get right. The guide is blunt about what happens if you leave something off:

The ASV checks your list too. It looks up the addresses behind your domains, tries common host names such as “www” and “mail”, reads your mail (MX) records and follows redirects from your web servers. Anything it finds that you marked out of scope is printed on the report's cover sheet. If a host runs your website, it can either have its own ASV scans and give you proof that they passed, or be scanned as part of yours. Either way, the guide says, “it is the responsibility of the scan customer to ensure that their hosted / multi-tenant environment receives a passing score from an ASV scan.”

Which merchants need it

The scan travels with your yearly paperwork. Depending on the card brands' programs you file a Report on Compliance or a Self-Assessment Questionnaire, an Attestation of Compliance goes with either one, and “Quarterly submission of an ASV scan report … may also be required.” Whether it is required of you depends on your SAQ.

SAQ A is the one that surprises people. A shop whose checkout is the processor's page still has a website that sends shoppers there, and attackers go after that website. The Council says so in the SAQ instructions: “To mitigate these common breaches, Requirements 11.3.2 and 11.3.2.1 are included in SAQ A.” If you take orders only by phone or mail and have no payment page at all, ask your acquirer. Not sure which form is yours? The SAQ type finder names it, and the SAQ A guide walks the rest of that form.

Who may run it (not you)

You can often start a scan from the vendor's portal and pick the time, but “only authorized ASV Employees are permitted to configure any settings” or change the results. Each scan solution is tested in an ASV Validation Lab and approved by the Council before the vendor is listed, then tested again every year, so the scan tool itself is approved, not only the company.

Choosing the vendor is your job. Scan customers are responsible for “Selecting an ASV from the list of Approved Scanning Vendors from the Website to conduct external vulnerability scanning in accordance with PCI DSS Requirement 11.3.2.” On 2026-10-22 that list held 85 scan solutions from 81 companies. Our directory of approved scanning vendors makes it searchable by name and region, and the ASV scanning vendors compared for small merchants weighs the ones that sell to shops, including who helps after a failed scan. An ASV may also send your reports to your acquirer for you, “if agreed between the ASV and its customer.”

What a free or do-it-yourself scan counts for

Not the quarterly external scan: if the tool is not run by an ASV, it does not meet 11.3.2. It still has a place. Internal scans under 11.3.1 run at least once every three months by qualified, independent staff, and a QSA or ASV is not required for them. The external scan after a significant change under 11.3.2.1 needs qualified, independent staff but not an ASV. Running one yourself before the ASV's scan also shows you a fail coming while there is still time to fix it.

On price, we print none: each vendor sets its own. Before you buy, log in to your processor's PCI portal, because a scan may already sit inside the program you are enrolled in. If you want the year's total, the PCI compliance cost calculator adds your own scan fee to the rest.

What a pass means

A passing ASV scan has no vulnerability scored 4.0 or higher on CVSS (High = 7.0–10.0, Medium = 4.0–6.9, both fail) and nothing that breaks PCI DSS. Low findings (0.0–3.9) can pass. Fix the failures and rescan until a report passes. CVSS is the industry's 0-to-10 severity score, and the ASV takes it from the US National Vulnerability Database wherever one is published. Low findings are worth fixing, but the guide says so only as advice: you are “encouraged, but not required, to correct these vulnerabilities.”

The score is not the whole test. Some findings break PCI DSS outright, and the ASV must mark them as automatic failures at any score. SSL 3.0 is the classic case: the NVD scores its best-known flaw, CVE-2014-3566, at 3.4, a Low, yet a server that still offers SSL fails the scan.

The ASV can also move a score, but only for listed reasons: the flaw is not in the database, it disagrees with the database's score (and must print both), the flaw is purely denial-of-service, or it breaks PCI DSS. And a pass proves one thing. Before every report is finalized you attest, among other things, that “ASV scan results only indicate whether scanned systems are compliant with the external vulnerability scan requirement (PCI DSS 11.3.2) and are not an indication of overall compliance with any other PCI DSS requirements.”

Read your own report

Copy each finding from the summary page of your report: its CVSS score, whether it is marked an automatic failure, and what you believe about it. Each line says Pass or Fail and what to do next.

Rules: ASV Program Guide v4.0 r2, §6.2, Table 1, Table 2, §7.5, §7.7, §7.8; example scores from the NIST NVD, read on 2026-10-22. Requirement text: PCI DSS v4.0.1 Prioritized Approach Tool.

After a failed scan: fix, dispute, rescan

A failed scan is the start of the work, not the end of the quarter: you only ever submit a passing report, and it can come after several fails. The guide sorts every finished scan into one of these outcomes:

Fix and rescan

For a failing scan you fix the failing vulnerabilities (and “may seek help from the ASV or other security professional as needed”), ask the ASV for another scan, and repeat until a scan passes. The passing report does not have to come from one clean run: it can be built from several failed scans that together show every finding from the first one was dealt with. Leave weeks, not days, before your deadline.

Dispute with the ASV

You can dispute false positives, a CVSS score, a finding covered by a compensating control, the report's exceptions or conclusions, the parts you marked as cut off from your card systems, and scans that could not finish. Disputes go to the ASV, never the Council: the ASV “must explicitly inform the scan customer that disputes in scan results are NOT to be submitted to the PCI SSC,” and it is “REQUIRED to investigate false positives with a CVSS Base score at or above 4.0.”

Evidence means proof your systems produced: screen captures, configuration files, software versions, the list of installed patches, with a note of when, where and how you took each one. You attest that it is accurate and complete. A won dispute does not carry over: the evidence is verified, resubmitted and judged again for each scan period, so keep it in a folder you can send again next quarter.

When your own firewall blocks the scan

Security tools that change their behaviour on the fly, such as an intrusion prevention system or a web firewall that shuts out an address after a burst of requests, can block the ASV halfway through. An unresolved inconclusive scan is reported as a fail. The fixes: switch the blocking off for the ASV's scan, show the ASV written evidence that the scan was not blocked, or agree a method the ASV runs, such as a secure tunnel or its approved scan appliance on your site.

What you send your acquirer

Every ASV report is built from the same parts, and the cover sheet can travel without the others:

Which parts go is your acquirer's or the card brand's call. “Scan reports must be submitted according to each Participating Payment Brand's requirements. Scan customers should contact their acquiring bank or each Participating Payment Brand to determine to whom results should be submitted.” Your ASV may send it for you if you agree that between you.

The attestation on the cover sheet is yours to make. The Scan Customer Attestation “may not be outsourced to a third party,” a fresh one is made for every scan period, and in it you confirm the scope was complete, any excluded parts are walled off from your card systems, and your dispute evidence is accurate. You cannot change the final report, and nor can anyone but the ASV, so never edit the PDF before you send it. Keep every passing report with your SAQ: it is the proof behind your 11.3.2 answer and the Attestation of Compliance you sign each year.

Internal scans, ASV scans and pen tests

Requirement 11 asks for more than one kind of testing, and only the quarterly external scan needs an ASV. A scan is automated: it lists known weaknesses. A penetration test is a person trying to get in, using those weaknesses and others. Your SAQ decides which of these are yours to do.

The practical upshot for a small shop: the ASV handles the quarterly outside view, and everything else can be done by a qualified person who is independent of the systems being tested, from your own team or a hired firm. A penetration test is a bigger, yearly job with its own tester, covered in the guide to PCI penetration testing cost.

The ASV scan on one receipt