An Approved Scanning Vendor (ASV) is a company certified by the PCI Security Standards Council to perform the external vulnerability scans that PCI DSS requires at least quarterly. ASV scans probe your internet-facing systems for known vulnerabilities from the outside, and the passing scan report is part of the compliance evidence merchants submit with their SAQ or Report on Compliance.
What does an ASV scan actually check?
An ASV scan runs from the vendor's infrastructure against your public-facing footprint: web servers, exposed services, TLS configurations, known-vulnerable software versions, and common misconfigurations. The vendor operates under the Council's ASV Program Guide, which standardises scoring — vulnerabilities rated CVSS 4.0 or higher generally fail the scan — and requires the ASV to attest the results.
Under PCI DSS 4.0.1, requirement 11.3.2 mandates these scans at least once every three months and after significant changes. Fail, and you remediate and rescan until you pass.
ASV scan vs internal scan vs penetration test
| ASV scan | Internal vulnerability scan | Penetration test | |
|---|---|---|---|
| Who performs it | PCI SSC-certified vendor | Your team or any qualified tool | Qualified testers (internal or external) |
| Vantage point | Outside, internet-facing | Inside the network | Either, goal-driven |
| Method | Automated scanning | Automated scanning | Manual exploitation |
| PCI requirement | 11.3.2, quarterly | 11.3.1, quarterly | 11.4, at least annually |
| Output | Attested pass/fail report | Ranked findings for remediation | Narrative report of exploited paths |
All three are network- and system-level controls. None of them executes your website the way a customer's browser does.
What an ASV scan cannot see
An ASV scan never renders your checkout page. It cannot observe the JavaScript that actually executes in a customer's browser — which is precisely where e-skimming happens. A Magecart script injected through a compromised third party passes every quarterly scan, because from the network edge, nothing about your servers changed.
That blind spot is why PCI DSS 4.0.1 added two browser-layer requirements: 6.4.3, an authorized inventory of every script on payment pages with business justification, and 11.6.1, tamper detection for the headers and script contents the consumer's browser receives. Those requirements need evidence from real sessions, not network probes — which is what cside's PCI Shield produces, in the format QSAs actually accept.
How the pieces fit
Think of the quarterly ASV scan as perimeter hygiene, the penetration test as an adversarial exercise, and 6.4.3/11.6.1 as runtime protection for the payment page itself. A complete PCI DSS 4.0.1 posture needs all three layers, and the cost of each scales differently: ASV scanning is commoditized and cheap; browser-layer evidence is where merchants most often discover a gap during their first 4.0.1 assessment.
