What Is a PCI ASV Scan, and What Happens If You Fail One?

An ASV scan is an external vulnerability scan performed by a company the PCI Security Standards Council has approved to run them. The Council's own definition: "An ASV is an organization with a set of security services and tools ('ASV scan solution') to conduct external vulnerability scanning services to validate adherence with the external scanning requirements of PCI DSS Requirement 11.3.2." That requirement calls for external vulnerability scans at least once every three months, and the pass line under the Council's ASV Program Guide is strict enough to surprise people: a single vulnerability at or above a CVSS base score of 4.0 fails the entire scan. Failing a scan is not itself a violation. Failing to remediate, rescan and reach a passing result within the quarter is.

Which is why the most useful operational habit in this whole area is scheduling the scan in the first two weeks of each quarter rather than the last. The rest of this explains who actually needs ASV scanning, what a failing result means in practice, and the distinction that costs the most money when it is confused: scanning is not penetration testing, and the standard requires both, separately.

Key takeaways

• An ASV scan is an external vulnerability scan performed by a vendor the PCI Security Standards Council has approved, tied to Requirement 11.3.2 and due at least once every three months.
• A single vulnerability at or above CVSS 4.0 fails the entire scan, and some categories fail automatically regardless of score.
• Failing is not the violation. Failing to remediate, rescan and reach a passing result within the quarter is, which is why the scan belongs in the first two weeks of a quarter rather than the last.
• The asset list decides whether any of it means anything. Reconcile scan targets against DNS and your cloud provider's public-address inventory each quarter, before the scan.
• Scanning is not penetration testing. The 11.3.x family and the 11.4.x family are separate requirements, and a QSA will not accept either report as evidence for the other.

Which requirement says what

Three numbers do most of the work, and one of them is misquoted constantly.

11.3.1 covers internal vulnerability scans, at least once every three months. This one is where the misreading happens. PCI DSS v4.x introduced genuine risk-based flexibility in several places, and people reach for it here. It does not apply to the internal scan cadence. What 11.3.1.1 makes risk-based is narrower: a targeted risk analysis can define how quickly non-high-risk, non-critical findings must be remediated and rescanned. The three-month cadence itself stands. Our guide to the v4 future-dated requirements sets out the targeted risk analysis machinery under Requirement 12.3.1 that any customer-defined frequency depends on.

11.3.1.2 requires internal scans to be authenticated. Unauthenticated internal scanning sees what an outsider without credentials sees, which is a small fraction of what is actually present. This became mandatory with the March 31, 2025 future-dated deadline.

11.3.2 covers external scans, and this is the ASV requirement. External scans at least once every three months, performed by an Approved Scanning Vendor, plus rescans after any significant change until a passing result is achieved.

Note what follows: an internal scanning tool you run yourself can satisfy 11.3.1. It cannot satisfy 11.3.2, because 11.3.2 is about who performs the scan as much as what the scan does.

Who actually needs ASV scanning

Not everyone, and this is the part that vendors selling scans are least motivated to lead with.

The obligation follows your validation type, and under PCI DSS v4 the lightest questionnaire is no longer an automatic exemption. The Council's own resource guide states that "ASV scan requirements in SAQ A apply only to an e-commerce merchant system(s) that hosts the webpage that either 1) redirects payment transactions to a PCI DSS compliant third-party service provider (TPSP) or 2) includes an embedded payment page/form from a PCI DSS compliant TPSP." Read that in both directions: if you run an e-commerce page that redirects or embeds an iframe, the system hosting that page is in scope for quarterly ASV scanning even on SAQ A; if you have no such page, because your card acceptance is fully outsourced by some other route, there is nothing for the scan to cover. The Council maintains an FAQ on exactly this point, numbered 1604 and titled "Do ASV scans in SAQ A apply to merchants with webpages that redirect to TPSPs or include TPSPs' embedded iframes?", in its FAQ library. Read the answer in the original rather than taking a scanning vendor's word for it.

The reliable way to settle it: work out which questionnaire your environment qualifies for, using which PCI SAQ do you need, then confirm the validation requirements with your acquirer, since the Council itself directs merchants to their acquirer or payment brand for validation questions.

Service providers are a separate case, and generally a heavier one. If your product handles or can affect the security of cardholder data for other companies, see merchant or service provider.

What "failed" actually means

Two things surprise people about a failing ASV result.

One finding fails the whole scan. The report is not scored on a curve. Under the ASV Program Guide, any vulnerability at or above CVSS 4.0 produces a failing result for the component it was found on, and certain categories fail automatically regardless of score. Check the current edition of the guide in the Council's document library, because the guide is versioned and the automatic-failure list is the part that changes.

A fail is a normal step, not an incident. The requirement is not that every scan passes on the first attempt. It is that you remediate what was found, rescan, and hold a passing scan for the period. A quarter that contains three failing scans and one passing scan at the end is a compliant quarter. A quarter with one failing scan and no follow-up is not.

Two nuances worth knowing before you argue with a report. Findings you believe are false positives, or that are mitigated by a compensating control, go through the ASV's dispute process, and the ASV has to review and document the evidence you provide. And the scan has to cover all externally reachable components in scope, so an incomplete asset list produces a passing scan that proves nothing. The asset inventory is the input that decides whether the whole exercise is meaningful.

The asset list is the part that decides whether any of this means anything

A scan proves something about what it looked at. Everything else about it is presentation.

The requirement covers the externally reachable components in scope, which is not the same as the list of hostnames someone typed into a portal two years ago. In our experience the gap between those two lists is where the real risk sits, and it opens in predictable ways: a marketing subdomain stood up for a campaign, a staging environment that became semi-production, an API gateway added during a re-architecture, a load balancer with a public address nobody meant to expose, an acquired company's infrastructure that has not been folded into anyone's inventory.

Two practices close it. Reconcile the scan target list against your DNS records and your cloud provider's inventory of public addresses each quarter, before the scan rather than after. And treat the significant-change trigger as real: 11.3.2 calls for rescanning after significant changes, and the changes that matter most are exactly the ones that add external surface.

The related discipline is reducing what there is to fail on. Every externally reachable service is a thing that can pick up a finding at 4.0 or above and fail a quarter for you. Turning off what nobody uses, moving administrative interfaces behind a private path, and putting a genuine reason behind each remaining open port shortens every future scan, every future dispute, and every future remediation window. It is the same argument as scope reduction, applied to the perimeter.

Scanning is not penetration testing, and PCI requires both

This confusion is expensive in both directions: companies who buy a pentest and think it covers 11.3.2, and companies who buy quarterly scans and think they have satisfied 11.4.

They are different requirements with different numbers. The 11.3.x family covers vulnerability scanning, internal and external. The 11.4.x family covers penetration testing: a documented methodology under 11.4.1, internal and external testing at least every 12 months and after significant change under 11.4.2 and 11.4.3, verification of fixes by retesting under 11.4.4, and segmentation testing under 11.4.5, tightened to every six months for service providers under 11.4.6. Our how often to run a penetration test article covers that family in full, and penetration testing versus vulnerability scanning covers why the two find different classes of problem.

A QSA will not accept a scan report as evidence for 11.4, and will not accept a penetration test report as evidence for 11.3.2. The standard was written to prevent exactly that substitution.

The honest version, since we sell testing and not scanning

Top Floor is not an Approved Scanning Vendor. We cannot run your 11.3.2 scans and we have no product to sell you here, which makes this the easiest against-interest section we will ever write.

Buying ASV scanning is close to a commodity purchase. The scan engines are broadly similar, the program requirements are set by the Council, and the differentiators that matter are unglamorous: how good the dispute process is when you have a genuine false positive, how easy rescanning is, and whether the portal produces the attestation document your acquirer wants without a support ticket. Price it accordingly and do not pay a premium for a dashboard.

What is worth paying for is the work around the scan: getting the asset inventory right, reducing the external surface so there is less to fail on, and closing findings rather than re-disputing them each quarter.

Where Top Floor fits

Our PCI DSS work is the readiness and remediation side: scope reduction, asset inventory, fixing what the scans surface, and preparing the evidence. Our penetration testing practice covers the 11.4.x obligations, which are a different requirement family and a different engagement.

How to decide this week

Confirm whether 11.3.2 applies to you at all. Your validation type answers it, and your acquirer confirms it. If it does not apply, stop here and do not buy a scan.

If it does, put the scan date in the first fortnight of each quarter, permanently. The remediation window is the reason.

Then compare the scan's target list against your actual external footprint, including anything spun up since the last review. A scan of a stale asset list is the most reassuring useless document in compliance.

Frequently asked questions

What is an ASV scan?

It is an external vulnerability scan run by an Approved Scanning Vendor. The PCI Security Standards Council defines an ASV as an organization with a set of security services and tools, an ASV scan solution, to conduct external vulnerability scanning services to validate adherence with the external scanning requirements of PCI DSS Requirement 11.3.2. The scanning is external only, and the requirement is about who performs it as well as what it covers, which is why an internal scanning tool you run yourself cannot satisfy it.

How often are PCI ASV scans required?

At least once every three months under Requirement 11.3.2, plus rescans after any significant change, and rescans as needed until a passing result is achieved. The internal scanning requirement at 11.3.1 is also at least once every three months. The risk-based flexibility PCI DSS v4.x introduced does not apply to that internal cadence: what 11.3.1.1 allows a targeted risk analysis to define is how quickly non-high-risk, non-critical findings must be remediated and rescanned.

What happens if we fail an ASV scan?

Failing is not itself a violation. Under the ASV Program Guide any vulnerability at or above a CVSS base score of 4.0 fails the scan for the component it was found on, and some categories fail automatically regardless of score, so failing a first attempt is common. What matters is the loop: remediate, rescan, and achieve a passing result within the period. If you believe a finding is a false positive or is addressed by a compensating control, the ASV has a dispute process and must review the evidence you supply. Scheduling the scan early in each quarter is what makes that loop fit.

Does a penetration test satisfy the PCI scanning requirement?

No, and the reverse is also false. Vulnerability scanning sits in the 11.3.x requirements and penetration testing in the 11.4.x requirements, and they are assessed separately. A QSA will not accept a scan report as evidence for penetration testing under 11.4, and will not accept a penetration test report as evidence for external scanning under 11.3.2. You need both: quarterly scanning, and testing at least every 12 months plus after significant change, with segmentation testing every six months for service providers.