The PCI ASV scan requirements are the obligation most likely to quietly fail a programme. External vulnerability scans must be run at least quarterly by an Approved Scanning Vendor listed by the PCI Security Standards Council, and the evidence an assessor wants is four passing quarterly scans spread across the compliance year. That evidence cannot be manufactured late.
Almost everything else in PCI DSS is annual or continuous-but-undated. You can write a policy in March for an assessment in April. You cannot produce a passing scan dated January in April. The dates on the reports are the control.
So a team that starts scanning two months before its assessment has already failed this one, whatever its security posture looks like. It has one scan, possibly two, and no way to recover the quarters it skipped.
What PCI ASV Scan Requirements Actually Demand
What the PCI ASV scan requirements demand is narrower than people assume and harder to satisfy than it looks. Vulnerability scanning sits under Requirement 11, and the external half of it has three components: a qualified vendor, a complete scope, and a passing result at least once every quarter.
The current standard is PCI DSS v4.0.1, and this requirement differs from the rest of it in one way that matters: it generates dated artefacts you either have or do not have. A gap in access reviews can be explained. A missing quarter cannot.
Why the Scanning Vendor Must Be Council Listed
The scanning vendor must be Council listed because Requirement 11 names the qualification, not just the activity. An Approved Scanning Vendor is an organisation qualified and listed by the PCI Security Standards Council, and the Council maintains that list on its own site.
Using a vendor that is not on the list does not satisfy the obligation. This holds no matter how good the scanner is. Teams run excellent commercial or open-source external scanning as part of their own security programme and assume it counts; it does not, and the assessor will ask for the ASV's report specifically.
So you need two things running: whatever continuous external scanning your security team wants, and an ASV engagement that produces the quarterly report with the vendor's attestation on it. The first is good practice. The second is the evidence.
Check the list before you sign, and check it again at renewal. A vendor's listing is a current status, not a permanent badge.
Not sure your external scan scope matches your real attack surface?
Share your work email and we will walk your internet-facing inventory against what your ASV is actually scanning, and flag the addresses nobody handed over.
What Gets Scanned, and Who Decides
What gets scanned under Requirement 11 is every external-facing in-scope component — all the IP addresses and domains an attacker can reach that are in scope or provide a path into scope. Not a representative sample. Not the three hosts the team thinks are interesting.
And the decision about what that list contains is yours, not the vendor's. The entity is responsible for giving the ASV a complete and accurate inventory of in-scope external-facing components. If the inventory is short, the scan is clean and the compliance position is still broken. An incomplete scope handed to the scanning vendor is the entity's failure, every time.
That inverts how most teams treat the engagement. They buy scanning as a service and assume the service works out the targets. The ASV scans what you give it.
Build the inventory deliberately: public application endpoints, API hosts, admin and management interfaces, VPN and remote-access endpoints, mail and DNS hosts you operate, anything in a cloud account with a public address, and every domain and subdomain that resolves to something you run. Then have someone other than the person who built it try to find something missing. Reducing what sits in scope in the first place — the subject of PCI DSS scope reduction — is the only way to make this inventory small enough to be reliably correct.
The Quarterly Cadence and What a Passing Scan Means
The quarterly cadence means a quarterly external vulnerability scan PCI assessors can see dated in each of the four quarters, and under PCI DSS v4.0.1 the expectation over a compliance year is four passing scans. A passing ASV scan is one where the vendor confirms the result meets the passing criteria — not one where the scan merely completed.
That distinction catches people. A scan that ran, produced findings and was filed is a failed scan with a report.
The normal path through a quarter looks like this: the initial scan fails, the team remediates, a rescan returns a passing result, and the passing rescan is the quarter's evidence. Nobody expects a first-attempt pass every time. What they expect is that each quarter closes with a pass in it.
So the real deadline is not the scan date; it is the scan date plus however long remediation and rescanning take. Scheduling the first scan of a quarter in its final week leaves no room for the normal path.
Rescans After Remediation
Rescans after remediation are what converts a fix into evidence. Remediation must be followed by a rescan demonstrating a passing result; a remediation ticket marked done is not a substitute for the vendor confirming the finding is gone.
Keep the chain intact for each failed finding — the scan that found it, what changed, the rescan that cleared it — across all 4 quarters. A tidy chain does more for your credibility than a lucky first-attempt pass.
Disputing a Finding as a False Positive
Disputing a finding as a false positive is a defined route, not a workaround. Where a finding is genuinely a false positive, or where a compensating control applies, the entity can raise the dispute with the ASV supported by evidence — and the ASV decides. You do not get to dismiss your own findings.
Evidence that works is specific and verifiable: configuration output showing the vulnerable function is not present, version and patch detail that contradicts a banner-based detection, or documentation of the compensating control and why it addresses the risk the finding describes. Evidence that does not work is an assertion that the finding looks wrong.
Budget time for it. A disputed finding stays open until the vendor accepts the dispute, so a dispute raised in the last week of a quarter has the same problem as a scan scheduled there.
Scanning After Significant Change
Scanning after significant change is a separate trigger that sits alongside the quarterly cadence rather than replacing it. Scans must be repeated after significant change, which means a material change to the external-facing environment restarts the question of whether your last passing scan still describes reality.
The hard part is not the rule. It is deciding what counts, and deciding it in advance. Write the definition down before you need it: new internet-facing hosts or services, changes to perimeter controls, a new public domain or endpoint, migration of a public workload between accounts or providers. Then wire the trigger into the change process so it fires without anyone remembering.
Teams that leave this undefined end up arguing about it during an assessment — the worst time to discover that a significant change landed in month 2 and nobody rescanned.
How Internal Vulnerability Scanning Differs
Internal vulnerability scanning PCI expects is also at least quarterly, but it differs in who may perform it. Internal scans can be run by qualified internal staff or by a third party — no ASV required. The qualification bar applies to the external obligation only.
This asymmetry is useful: internal scanning can live inside your own engineering workflow and tooling, as long as it clears the quarterly floor and you can show it ran. The documentation burden is yours rather than a vendor's.
It also means two sets of evidence, not one. Teams that buy an ASV engagement and consider vulnerability scanning handled are missing half of it. The PCI DSS compliance checklist treats these as distinct line items because assessors do.
Where ASV Scanning and Penetration Testing Part Ways
ASV scanning and penetration testing part ways completely — they are different obligations with different evidence, and neither substitutes for the other. ASV scanning does not satisfy the penetration testing requirement, and a penetration test does not satisfy the scanning obligation.
The confusion usually runs one way: a team with a recent external penetration test assumes it has covered the ground a quarterly scan would. It has not — the requirement asks for the ASV's quarterly attestation specifically. The reverse mistake also happens, with four passing scans offered in place of a test.
Plan and budget them separately. PCI DSS penetration testing has its own scope, cadence and provider conversation, and the two programmes share almost nothing beyond the word "testing".
Five Failures That Cost Teams a Quarter
These five failures account for most lost quarters, and all of them are failures of operations rather than security.
- The IP inventory is incomplete. Someone compiled it once, from memory, and the scan has been running against that list ever since. Everything downstream is clean and wrong.
- Cloud addresses rotate. Public addresses assigned dynamically, or workloads that scale and move, mean the target list drifts from the real surface between quarters. Scan by domain where you can, and reconcile the address list every quarter rather than annually.
- Load balancers and CDNs mask origins. The scanner sees the edge and reports on the edge. If an origin is independently reachable, it is in scope and the edge scan does not cover it.
- WAF rules block the scan window. Protective controls rate-limit or block the scanner, the scan returns partial or clean results, and nobody notices until someone reads the report closely. Coordinate the window and confirm the scan reached its targets.
- A failed scan is treated as a scheduling problem. The most expensive one. A failed scan is a finding with a clock on it, not a calendar item to move. Teams that reschedule instead of remediating discover at assessment that they have four reports and no passes.
PCI ASV Scanning Questions Teams Ask
These are the PCI ASV scanning questions teams ask most often once they realise the quarterly evidence cannot be produced retroactively.
Four passing scans. The expectation over a compliance year is a passing quarterly external scan in each quarter, and a scan that ran but did not meet the passing criteria is not evidence of anything except that you scanned. The normal path is an initial failing scan, remediation, and a passing rescan within the same quarter — that passing rescan is what the quarter contributes.
Not for the external obligation. External scans must be performed by an Approved Scanning Vendor qualified and listed by the PCI Security Standards Council, and a vendor not on that list does not satisfy the requirement regardless of the tool's quality. Your own scanner is still worth running continuously, and it can serve the internal scanning expectation, which does not require an ASV.
You are. The entity is responsible for providing the ASV with a complete and accurate inventory of in-scope external-facing components. If an internet-facing host that should have been scanned was never handed over, that is the entity's failure, not the vendor's — and a passing report over an incomplete scope does not help you.
You dispute it with the ASV and support the dispute with evidence, either demonstrating the finding is a false positive or documenting the compensating control that applies. The ASV decides. Until the dispute is accepted the finding remains open, so raise it early in the quarter rather than against the deadline.
No — it adds an obligation rather than replacing one. Scans must be repeated after significant change, and that rescan sits alongside the quarterly cadence. Define in advance what counts as significant for your environment and wire the trigger into your change process, because reconstructing which changes were material months later is an argument you will lose.
Keep four quarters of scanning evidence together in one place
Book a demo and we will show how Konfirmity tracks your external and internal scanning cadence, the remediation and rescan chain behind each failed finding, and the quarters where evidence is still missing.
Book a demo
Start the Scanning Clock Before You Need the Evidence
The scanning clock is the only part of PCI DSS that genuinely cannot be caught up. Start it the quarter you decide to pursue compliance, not the quarter before your assessment, and the rest of the obligation becomes routine: scan early in each quarter, remediate, rescan, file the pass.
Two things separate a programme that produces four passes from one that produces four reports: an external inventory someone owns and reconciles every quarter, and treating a failed scan as a finding with a deadline so the remediation path exists before the scan runs rather than after it.
Get the inventory right first. An honest external surface tells you how much scanning you are actually buying and what your assessment will cover, and it feeds directly into the broader picture in the PCI DSS requirements — where the scanning obligation stops being the one that surprises you.
