Approved Scanning Vendors (ASVs): The Quarterly External Scan, Its Scope, and Choosing a Provider

An Approved Scanning Vendor (ASV) is a company the PCI Security Standards Council has qualified to run the external vulnerability scans PCI DSS requires. This article covers what the requirement says, how the work divides between you and the ASV, what goes into scope, and what to ask a provider before choosing one.

What 11.3.2 requires

11.3.2 requires external vulnerability scans:

• at least once every three months;
• by a PCI SSC Approved Scanning Vendor;
• with vulnerabilities resolved and the ASV Program Guide's requirements for a passing scan met;
• with rescans as needed to confirm the fixes.

The assessor checks this by looking at the ASV scan reports from the last 12 months: one at least every three months, each one passing or followed by a passing rescan, all by an ASV. The requirement's applicability note makes one allowance for a first assessment. Four passing scans are not needed if the most recent scan passed, a documented procedure requires quarterly scanning, and anything found was fixed and shown fixed by a rescan. From the second year on, a passing scan every three months is expected.

Quarterly is the minimum. The standard's guidance recommends scanning more often where the network is complex, changes often, or runs many kinds of devices and software.

Scans after a change are a separate requirement

11.3.2.1 requires external scans after any significant change, with every vulnerability scored 4.0 or higher under CVSS resolved. Those scans do not have to be run by an ASV or a QSA. They can be done by qualified staff who are organisationally independent of the systems scanned. A post-change scan run that way does not count as one of the quarterly ASV scans.

What the ASV decides and what stays with you

The ASV runs the scan, applies the ASV Program Guide, and issues the report and the Attestation of Scan Compliance. Under the Program Guide, a finding scored 4.0 or higher generally fails the scan. A finding you believe is wrong, or already dealt with, is taken up with the ASV, because the ASV is the one who decides whether the scan passes. The standard's guidance adds that an assessor may ask for more documentation to show that vulnerabilities not yet fixed are being dealt with.

What stays with you:

• Scope. You tell the ASV what to scan, and a scan only covers what it was given.
• Fixes and rescans. Resolving what the scan finds, and asking for the rescan that proves it.
• The wider programme. The standard's guidance says external scan findings belong in the same vulnerability management process as every other source, under 6.3.1.

Scope: what the ASV needs to see

The scan covers the internet-facing side of anything in scope for PCI DSS: public IP addresses and the hostnames that resolve to them, web and API endpoints, mail servers, remote access gateways, and the external interfaces of network security controls. Cloud-hosted systems count the same as ones in your own rack. A scan that misses an address simply says nothing about it, so the gaps that matter are the ones nobody listed:

• a development or staging host that is reachable from the internet;
• a domain or address range added since the last scan, after a migration or an acquisition;
• a temporary system left exposed after a project;
• a service run for you by a third party that sits in your scope.

Network segmentation changes what is in scope, not how thoroughly the in-scope side is scanned; see Using network segmentation to reduce PCI DSS scope.

Letting the scan through

Intrusion prevention systems, web application firewalls and rate limits exist to stop traffic that looks like an attack, and a vulnerability scan looks like one. If they block the ASV, the scan sees less than an attacker would and can report a clean result that is not true. The standard's guidance to 11.3.2 says specifics such as scan interference, load balancers and third-party providers should be worked out between the ASV and you, and points to the ASV Program Guide for the customer's responsibilities. In practice that means:

• getting the ASV's scanning source addresses in writing;
• allowing them through for the scan window, across every port and service in scope, not only web traffic;
• recording the change and removing it afterwards if it is not needed between scans.

Choosing an ASV

Only a company on the Council's list can produce a scan that counts. Find an assessor on this site draws on the Council's ASV listing, and the Council's own list is the authority. Questions worth asking before signing:

1. How do you help a customer confirm its scope, and what do you need from us to do it?
2. How are disputed findings and false positives handled, and how long does a decision take?
3. Are rescans included, and how quickly can one be run?
4. Which addresses will the scans come from, and when will you tell us if they change?
5. What do your report and Attestation of Scan Compliance look like? Ask for a sample.
6. Is support available during our scan windows?

An ASV scan is one of several tests the standard requires. Internal scans (11.3.1, see internal vulnerability scanning) and external penetration tests (11.4.3) are separate requirements, and an ASV scan does not satisfy either.