ASV scan: who needs one and how to pass it

An ASV scan is an external vulnerability scan of the systems your business exposes to the internet, carried out by an Approved Scanning Vendor (ASV), a company the PCI Security Standards Council (PCI SSC) has approved for the work. The scanner probes your website and other public-facing systems from outside your network and reports the known vulnerabilities it finds. For many merchants, a passing PCI ASV scan every quarter is how they meet PCI DSS Requirement 11.3.2.

Whether you need one depends on how you take cards and what your acquirer asks you to file. This guide covers who needs an ASV scan under PCI DSS v4.0.1, how often, what makes a scan pass or fail, what an ASV scan report contains, and how to dispute a finding you believe is wrong. Everything here is current as of October 2026.

What does ASV scan mean?

The meaning is in the name: ASV stands for Approved Scanning Vendor. PCI SSC describes an ASV as a company it has approved to perform external vulnerability scans of internet-facing environments (PCI SSC). An ASV scan is that company's automated check of the internet-facing systems you put in scope, judged against PCI SSC's standard for a passing scan.

Know what it isn't, too. It isn't a penetration test, where a person actively tries to break in, and it doesn't look inside your network. A clean result means the scanner found no failing vulnerabilities on the components it scanned that day. It says nothing about systems nobody put in scope.

Only a listed company can run one. PCI SSC publishes its list of approved scanning vendors and advises anyone who hires one to check the list regularly to confirm the vendor's status (PCI SSC). If your processor bundles scans into its PCI program, ask which listed vendor runs them. Our guide to the PCI compliance fee covers what those programs tend to charge for.

Which merchants need a PCI ASV scan?

Merchants whose PCI validation includes Requirement 11.3.2. That's settled by your self-assessment questionnaire (SAQ) and by what your acquirer asks for, not by whether a scan sounds like a good idea. PCI SSC writes the standard, but it says whether an organization has to validate is up to the payment brands and acquirers (PCI SSC).

The SAQ A row is new for many small online sellers. PCI SSC's resource guide on scans says SAQ A merchants are now completing the scan requirement for the first time, and that for them it applies only to the e-commerce systems hosting the redirect or embedded payment page from a PCI DSS compliant third-party provider (PCI SSC).

Take a made-up candle maker in Madison that sells from its own website and sends shoppers to its processor's hosted checkout to pay. It files SAQ A, and its quarterly scans cover the web server hosting its shop pages and the Pay button that redirects. The checkout page itself belongs to the provider, which secures and validates its own systems.

Not sure which SAQ you file? It turns on how card data reaches you, so your website and your store counter can land in different questionnaires. Our guide to what PCI compliance is walks through each SAQ and who files it.

What are the PCI ASV scan requirements?

PCI DSS v4.0.1 sets them out in two requirements. Requirement 11.3.2 calls for external vulnerability scans at least once every three months, performed by a PCI SSC ASV, with vulnerabilities resolved to the ASV Program Guide's standard for a passing scan and rescans run as needed to confirm the fixes. Requirement 11.3.2.1 adds scans after any significant change, with every vulnerability scored 4.0 or higher on the CVSS scale resolved and rescans run as needed (PCI SSC).

The first-assessment allowance comes from the notes to Requirement 11.3.2, and it helps if you're validating for the first time. You don't need a year of history to start, just a passing scan, the written policy and proof that you fixed what earlier scans found. From the second year on, every quarter has to be covered.

What if a quarter's first scan fails? Fix and scan again. PCI SSC's FAQ on quarterly scanning accepts that a new vulnerability can turn up between scans, and what it looks for is a working process for fixing what scans find, rather than repeated failures caused by poor fixes (PCI SSC). Our habit: book each scan in the first month of the quarter, so a failure leaves weeks to fix and rescan.

Ask your ASV and your acquirer what counts as a significant change for your setup. A new website platform, a move to a new host or a new server facing the internet are the obvious ones to raise.

What makes an ASV scan pass or fail?

PCI DSS hands the pass mark to PCI SSC's ASV Program Guide, and at its core is a line at 4.0 on the CVSS scale. The guide's first edition, published in 2010, said that to be considered compliant, a component generally must not contain any vulnerability with a CVSS base score of 4.0 or higher (PCI SSC). PCI DSS v4.0.1 draws the same 4.0 line for scans after a significant change.

That 2010 edition also listed findings that fail a scan whatever their score, and one kind that doesn't fail on its own:

The 2010 edition isn't the last word, so ask your ASV which edition of the guide it scans against and for its current list of automatic failures. When a scan fails, the fix is often routine maintenance: install the update, switch off the service nobody uses, or replace software its maker no longer supports.

Settle one more thing with your ASV before scan day: your security tools. PCI SSC's 2010 guide noted that intrusion detection and prevention systems may react differently to an automated scan than to a targeted attack, which can make a report inaccurate. Ask your ASV how it wants those systems handled during the scan window. And never hide a system from the scanner to get a pass. You'll complete an attestation about scope, and leaving systems out on purpose makes it untrue.

What's in an ASV scan report?

Findings, a pass or fail result and two attestations. In PCI SSC's 2010 guide, the ASV scan report has three parts (PCI SSC):

1. The Attestation of Scan Compliance, a cover sheet with the overall result: whether your infrastructure received a passing scan and met the scan validation requirement.
2. An executive summary that lists findings by component (IP address), with the dates the scan was completed and expires, each finding's severity, CVSS score and pass or fail status, and a remediation plan for each IP address.
3. Vulnerability details, sorted by vulnerability instead of by host, with severity, scores, industry reference numbers and a pass or fail status for each.

You and the ASV each complete an attestation on that cover sheet. Yours covers whether every in-scope component was included and whether anything left out is properly segmented from the cardholder data environment. Read yours line by line before you complete it, because it's a statement about your network, not a formality.

Before you file a report, check four things:

• The IP addresses and domains match everything in scope that faces the internet.
• The scan date falls in the quarter you're filing for.
• The overall result says pass.
• Any finding you disputed shows the ASV's decision.

Then send your acquirer what it asks for and keep every quarter's report. Our guide to PCI compliance levels explains how much paperwork each card brand expects at your size.

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

Send your ASV written evidence and let it decide. Under PCI SSC's 2010 guide, scan customers can dispute findings, including false positives. The evidence has to be written and preferably system-generated, the ASV must investigate claimed false positives that score 4.0 or higher, and its conclusion goes in the report's section on exceptions, false positives or compensating controls (PCI SSC).

Here's how we'd put a dispute together:

1. Read the finding, its reference numbers and the component it names.
2. Ask your web host or developer whether it's real for your setup.
3. Collect system-generated proof: the software's own version output, a configuration export, or the vendor's advisory showing your version includes the fix.
4. Submit it through your ASV's dispute process.
5. If the ASV accepts it, check that the report records the decision. If it doesn't, fix the issue and rescan.
6. File the evidence with the report, so it's ready if the same finding shows up next quarter.

Disputes exist for cases like this one. A scan of a made-up dental lab's website in Albuquerque flags an old version of its web server software. The host's records show the security fix was applied, but the version number the server reports never changed. Send the host's patch record and the server's own output, and let the ASV rule.

Don't dispute what you can fix in an afternoon, though. A dispute means back-and-forth with the ASV; an update usually doesn't.

How do hosted checkout, P2PE and tokenization change your scans?

They shrink what's in scope, which can mean fewer systems to scan, but under v4.x a hosted checkout doesn't make scans disappear. The site that sends shoppers to the payment page, or embeds it, still needs them. Our hosted payment page guide compares redirects, embedded forms and custom checkouts.

At the counter, PCI SSC says merchants who use a PCI-listed point-to-point encryption solution have fewer PCI DSS requirements to meet (PCI SSC), and our point-to-point encryption guide covers the questionnaire that comes with it. For saved cards, PCI SSC's tokenization guidelines recommend keeping the number of system components that store, process or transmit card numbers to a minimum (PCI SSC), and our payment tokenization guide explains how that works in practice.

Clearo's online payments include hosted checkout, our POS terminals read chip and tap, and phone orders can go through a virtual terminal instead of a notepad. Fewer places where card data lives means a shorter questionnaire and, often, fewer systems for the scanner to cover. If you also sell at a counter, our PCI compliance page covers terminal checks alongside ASV scans.

ASV scan checklist

1. Open your SAQ and look for Requirement 11.3.2, then ask your acquirer whether it wants anything more.
2. Pick an ASV from PCI SSC's list, or confirm the one your processor uses is on it.
3. List every internet-facing IP address and domain that's in scope.
4. Agree with the ASV on how your firewall and intrusion prevention will handle the scan.
5. Book the scan early in each quarter.
6. Fix failures and rescan until the result passes.
7. Dispute false positives with written, system-generated evidence.
8. Read your attestation and complete it only if every statement in it is true.
9. Send your acquirer what it asks for, and keep every report.
10. Scan again after significant changes, such as a new host or website platform.

PCI DSS doesn't change from state to state, so this checklist holds for merchants anywhere in the United States. Canadian merchants can find what's different for them in our guide to PCI compliance in Canada.

Your next step

If your statement shows PCI or scan fees and you can't match them to a real scan report, send us a recent statement for a free statement review. We'll point out every compliance charge and what it's paying for. Clearo offers PCI compliance support, so if you'd like to talk through your SAQ and scan schedule first, contact us.