ASV Scans Explained: How to Pass Your Quarterly External Scan

An ASV scan is an external vulnerability scan of your internet-facing systems, run by an Approved Scanning Vendor listed by the PCI Security Standards Council. PCI DSS requires one at least once every three months, and each quarter needs a passing result. To pass, no in-scope component can have a vulnerability with a CVSS base score of 4.0 or higher, or any finding the ASV Program Guide treats as an automatic failure. Passing consistently comes down to accurate scope, prompt patching and well-documented disputes.

This guide covers the requirement in both PCI DSS v3.2.1 and v4.0, how scoring works, and what to do when a report comes back with failures.

What is an ASV scan?

An Approved Scanning Vendor (ASV) is a company whose scanning solution has been tested and approved by the PCI Security Standards Council (PCI SSC). The Council publishes the list of approved vendors on its website. Only a scan run by one of them, using its approved solution, satisfies the quarterly external scanning requirement.

The scan runs from the internet against the addresses and domains you provide. It looks for known vulnerabilities and insecure configurations the way an outsider would, and it's designed to be non-disruptive, so it shouldn't crash systems or exploit what it finds.

The report follows a standard format set by the ASV Program Guide and has three parts:

• Attestation of Scan Compliance: a one-page summary of the result, attested by both you (the "scan customer") and the ASV.
• ASV Scan Report Summary: pass or fail for each component, with a count of findings.
• ASV Scan Report Vulnerability Details: every finding, its severity and whether it causes a failure.

Which PCI DSS requirement covers ASV scans?

The requirement was renumbered when PCI DSS v4.0 was published in March 2022, but its substance barely changed. Both versions stay valid until v3.2.1 retires on 31 March 2024, so you may see either numbering in your next assessment.

People often miss that only the quarterly scans must come from an ASV. Scans after a significant change, such as a new internet-facing server or a firewall rebuild, can be run by qualified internal staff or another provider. Findings rated 4.0 or higher still have to be resolved and rescanned.

Who needs an ASV scan?

Any organization whose PCI DSS validation includes the external scanning requirement needs one. That means almost everyone assessed with a Report on Compliance, and many merchants and service providers completing a Self-Assessment Questionnaire (SAQ). Check whether requirement 11.2.2 or 11.3.2 appears in yours.

E-commerce merchants should note one change. The v4.0 version of SAQ A, used by merchants that fully outsource their payment pages, includes external vulnerability scanning, which the v3.2.1 version didn't. If you're moving to the v4.0 questionnaire, plan for quarterly scans of the internet-facing systems behind the site that sends customers to your payment provider.

How often do you need an ASV scan?

At least once every three months, which works out to four passing scans in any 12-month period. The requirement is a passing result each quarter, not just a completed scan. A failed scan therefore needs remediation and a rescan before the quarter ends.

Your first assessment gets some leeway. You don't need four passing quarters if the most recent scan passed, you have documented policies requiring quarterly scanning, and vulnerabilities found in earlier scans were corrected and confirmed by rescans. From the second year onward, the full four quarters are expected.

Scan early in each quarter. A scan in the final week leaves no room for patch cycles, change windows, or a dispute that takes the ASV a few days to review.

What's in scope for an external ASV scan?

Scope is where most scan programs go wrong, and it's your responsibility, not the ASV's. You must give the ASV every internet-facing IP address and domain that's part of the cardholder data environment, provides a path into it, or could affect its security. The ASV runs discovery against what you provide and lists anything it found but didn't scan, and you'll need to explain why each of those is out of scope.

Build your scope list from:

• Public IP ranges assigned to you, including those at cloud and hosting providers
• Domains and subdomains, including virtual hosts that share an IP address
• Web servers, APIs and pages involved in taking payments or redirecting customers to a payment provider
• Remote access gateways and VPN endpoints
• Mail, DNS and other services that sit on the same network segments as in-scope systems
• Load balancers and the servers behind them

Segmentation can shrink the list, but only if the excluded systems are genuinely isolated from the cardholder data environment. If you exclude something on that basis, keep the evidence ready, because your assessor will ask for it.

Two practical points. Behind a load balancer, make sure the scan reaches every server in the pool, or be ready to show they're configured identically. And don't let an intrusion prevention system or web application firewall quietly block the scanner. The ASV needs an unobstructed view, so arrange for its scanning sources to be let through while protection stays on for everyone else.

How does an ASV decide whether you pass?

Scoring works per component and then overall. Any component with a vulnerability that has a CVSS base score of 4.0 or higher fails, and a single failing component fails the whole scan. ASVs generally use the scores published in NIST's National Vulnerability Database where one exists.

Some findings fail the scan whatever their score. The ASV Program Guide lists them, and they include:

• SQL injection
• Cross-site scripting
• Directory traversal
• HTTP response splitting or header injection
• Backdoors or other malicious software found on the host
• Operating systems or software no longer supported by the vendor
• SSL and early TLS

The report can also carry "special notes" for things that aren't vulnerabilities in themselves but raise risk, such as remote access software reachable from the internet. A special note doesn't fail the scan by itself. You do have to confirm the business need and explain how the item is secured, and the ASV records your declaration.

Why do ASV scans fail?

The same causes come up again and again:

1. Missing patches on internet-facing web servers, VPN gateways and firewalls.
2. Old TLS versions or weak cipher suites left enabled "for compatibility".
3. Software that quietly reached end of support.
4. Services exposed that never should have been, such as database listeners or management interfaces.
5. Forgotten hosts: a test server, an old marketing site or a retired application still answering on an in-scope address.
6. Incomplete scans caused by blocking or rate limiting.

Most of these are hygiene problems rather than scanning problems. An accurate asset inventory and a working patch process do more for your pass rate than anything you do in the week of the scan.

How do you dispute a false positive on an ASV scan?

Scanners often judge a system by the version it advertises. Many Linux distributions backport security fixes without changing the version number, so a fully patched server can look vulnerable. That's the classic false positive.

The fix is a documented dispute. Submit it to your ASV with evidence, such as package changelogs showing the fix, configuration output proving a feature is disabled, or the vendor's advisory. The ASV reviews the evidence and makes the call. If it agrees, the finding is recorded in the report as an exception with the reason, and it no longer counts against you.

Keep your evidence organized by finding. If the same false positive shows up next quarter, you'll probably have to dispute it again, and a ready-made evidence pack makes that quick.

Can compensating controls resolve a failing finding?

Sometimes. If you can't fix a vulnerability directly, the ASV Program Guide lets you present a compensating control that mitigates it, and the ASV decides whether to accept it. An example is a flaw in an application you can't patch yet, where a filtering rule blocks the specific request used to exploit it.

Treat this as an exception, not a strategy. The control has to address the specific risk, you'll need documentation the ASV can verify, and your assessor may review it too. A permanent fix is almost always less work than defending a workaround every quarter.

How to pass your quarterly ASV scan: a checklist

1. Confirm scope before each quarter, including new cloud assets and domains.
2. Run your own external scan a few weeks ahead to catch problems early.
3. Patch or reconfigure anything rated 4.0 or higher and anything on the automatic-failure list.
4. Disable SSL and early TLS and review your cipher suites.
5. Make sure security controls won't block the ASV's scanning sources.
6. Schedule the ASV scan early in the quarter.
7. Submit disputes with evidence straight away, not in the last week.
8. Rescan until you have a pass, then file the report with your compliance evidence.
9. After any significant change, run a change-driven scan without waiting for the quarterly cycle.

Frequently asked questions

Can we run the quarterly scans ourselves?

Not for the quarterly requirement, which needs an ASV. You can and should run your own scans in between, and qualified internal staff can handle the scans required after significant changes.

Does one failed ASV scan make us non-compliant?

No. A failing scan is a normal step in the process. What matters is getting a passing scan for each quarter, so remediate, rescan and keep both reports.

Do internal vulnerability scans count toward this requirement?

No. Internal scanning is a separate requirement (11.2.1 in v3.2.1, 11.3.1 in v4.0) and doesn't need an ASV.

What changes for ASV scans when we move to v4.0?

Very little in practice. The quarterly ASV requirement carries over as 11.3.2, and the pass criteria still come from the ASV Program Guide. The biggest adjustment is for SAQ A merchants, whose questionnaire now includes scanning.

Key takeaways

• Quarterly external scans must come from a PCI SSC-approved ASV. Scans after significant changes don't have to.
• A pass means no findings with a CVSS base score of 4.0 or above and none of the automatic failures.
• Scope is your job. List every internet-facing IP address and domain that could affect card data.
• Disputes and compensating controls need evidence, and the ASV makes the decision.
• Scan early in the quarter so there's time to fix, dispute and rescan.