- \n
- Only a PCI SSC Approved Scanning Vendor<\/strong> can issue the attestation your acquirer accepts for Requirement 11.3.2.<\/li>\n
- A single vulnerability scoring CVSS 4.0 or higher<\/strong> fails the entire scan \u2014 and some findings fail regardless of score.<\/li>\n
- You should receive three documents<\/strong>, not a PDF: attestation, summary and vulnerability detail.<\/li>\n
- Most failures are inventory and lifecycle problems, not exotic vulnerabilities.<\/li>\n<\/ul>\n<\/div>\n
\nEvery 3 months<\/b>minimum frequency of the external scan under Requirement 11.3.2<\/span><\/div>\nCVSS 4.0<\/b>the score at which a single finding fails the whole scan<\/span><\/div>\n3 documents<\/b>attestation of scan compliance, scan report summary and vulnerability details<\/span><\/div>\n<\/div>\nWhat an Approved Scanning Vendor is<\/h2>\n
The PCI Security Standards Council defines an ASV as an organization with a set of security services and tools \u2014 an \u00abASV scan solution\u00bb \u2014 used to conduct external vulnerability scanning that validates adherence to the external scanning requirements of PCI DSS Requirement 11.3.2.<\/p>\n
The detail that matters commercially is what gets approved. The Council tests and approves the scan solution<\/em> before the vendor is added to the List of Approved Scanning Vendors. So an ASV is not simply a security firm that owns a scanner: it is a firm whose scanning solution has passed the Council’s own testing, and whose staff have been through the Council’s qualification process.<\/p>\n
Two consequences follow. First, only an ASV can issue the attestation your acquirer or your QSA will accept for Requirement 11.3.2 \u2014 an internal scan with the same tool does not substitute for it. Second, the list is public and it changes, so a vendor’s status should be verified on the Council’s list at the moment you engage them, not inferred from a logo on a website.<\/p>\n
Where the obligation comes from<\/h2>\n
Two sub-requirements of PCI DSS v4.0.1 govern external scanning, and they are frequently confused.<\/p>\n
- \n
- Requirement 11.3.2<\/strong> \u2014 external vulnerability scans are performed at least once every three months<\/strong>, by a PCI SSC Approved Scanning Vendor, and the result must be a passing<\/strong> scan.<\/li>\n
- Requirement 11.3.2.1<\/strong> \u2014 external scans are performed after any significant change<\/strong> to the environment. These do not have to be run by an ASV, but they must be performed by qualified personnel who are organizationally independent of the systems being scanned, and the result belongs in your change-control record.<\/li>\n<\/ul>\n
A \u00absignificant change\u00bb is not a term of art you can wave away: new internet-facing infrastructure, a firewall rule change that exposes a service, a change in network topology, a new public application component. If it changes your external footprint, it triggers 11.3.2.1.<\/p>\n
Since March 31, 2025 every PCI DSS v4.x requirement \u2014 including those originally published as future-dated \u2014 is mandatory, and v4.0.1 is the only active version of the standard. There is no longer a \u00abwe are still on the old version\u00bb answer available.<\/p>\n
What has to be in scope<\/h2>\n
Scope is the single most common source of disputes, and it is broader than most merchants assume. An ASV scan must cover all externally accessible system components that are in scope for PCI DSS, which in practice means:<\/p>\n
- \n
- every public IP address and range belonging to the cardholder data environment;<\/li>\n
- public-facing web, application and API endpoints, by URL, not just by IP;<\/li>\n
- the network devices that sit in front of them \u2014 firewalls, routers, load balancers, IPS;<\/li>\n
- systems that do not store card data themselves but provide a path into the CDE.<\/li>\n<\/ul>\n
Scope is declared by you<\/em> and validated by the ASV. If you hand over a short list of IPs and the ASV later finds a live host you failed to mention, that is not a technicality; it is an accuracy problem in the attestation both parties sign. An accurate inventory of your external attack surface<\/a> is a prerequisite for the scan, not a by-product of it.<\/p>\n
What \u00abpassing\u00bb actually means<\/h2>\n
The bar is defined by the ASV Program Guide, and it is stricter than most vulnerability-management policies:<\/p>\n
- \n
- No vulnerability with a CVSS base score of 4.0 or higher<\/strong> may remain anywhere in scope. A single medium-severity finding on a single host fails the whole scan.<\/li>\n
- Certain findings fail automatically, regardless of score.<\/strong> These include software or operating systems no longer supported by the vendor, SQL injection, cross-site scripting on sensitive pages, insecure remote access and default passwords on any reachable service.<\/li>\n<\/ul>\n
That second point is where organizations get caught. An end-of-life component with no CVE attached to it that quarter still fails you, because unsupported software cannot receive security patches \u2014 which is the whole premise of the requirement.<\/p>\n
Failing is not the end of the process. You remediate, and the ASV rescans. Compliance is judged on the passing scan, so the operational question is not \u00abdid we pass first time\u00bb but \u00abcan we get to a passing result before the quarter closes\u00bb.<\/p>\n
\n![\"CVSS](\"https:\/\/nordsterntech.com\/en\/wp-content\/uploads\/2026\/09\/fig-asv-fallo.jpg\")
The bar is stricter than most internal vulnerability policies: there is no \u201caccepted risk\u201d category in an ASV scan.<\/figcaption><\/figure>\n The three documents you should receive<\/h2>\n
An ASV scan report is not a PDF of findings. It is a set of three documents, and you should insist on all three:<\/p>\n
- \n
- Attestation of Scan Compliance.<\/strong> The signable record: ASV name, scan dates, the in-scope IP addresses and domains, and the overall result. It is signed by both the ASV and a representative of the scanned organization \u2014 a dual-party statement that the scan happened and the scope was accurate.<\/li>\n
- Scan Report Summary.<\/strong> Findings organized by host and component, with severity, so the compliance conversation can happen without reading raw output.<\/li>\n
- Vulnerability Details.<\/strong> The full technical record for each finding, with CVE identifiers and remediation guidance \u2014 the document your engineers actually work from.<\/li>\n<\/ol>\n
Keep the complete set for every quarter, not just the pass\/fail email you forwarded to your acquirer. Acquirers and assessors are entitled to review all three.<\/p>\n
Why quarterly scans fail, in order of frequency<\/h2>\n
The recurring causes are mundane, and none of them are exotic vulnerabilities:<\/p>\n
- \n
- Unsupported software still in production.<\/strong> An old TLS stack, an unmaintained CMS plugin, a web server release the vendor stopped supporting two years ago. Automatic failure.<\/li>\n
- Forgotten hosts.<\/strong> A staging server, a legacy VPN endpoint, a marketing microsite on the same public range. In scope whether or not anyone remembers deploying it.<\/li>\n
- Administrative interfaces exposed to the internet.<\/strong> Management consoles, database ports, remote access left reachable \u00abtemporarily\u00bb.<\/li>\n
- Certificate and protocol configuration.<\/strong> Weak ciphers and deprecated protocol versions score above the 4.0 threshold and are usually cheap to fix.<\/li>\n
- Timing.<\/strong> The scan is launched in the last week of the quarter, leaving no room for remediation and a rescan.<\/li>\n<\/ul>\n
Most of these are not detection problems. They are inventory and lifecycle problems, which is why organizations that run continuous vulnerability and exposure management<\/a> tend to treat the quarterly scan as a formality rather than an event.<\/p>\n
\nMost of these are not detection problems. They are inventory and lifecycle problems.<\/p>\n<\/div>\n
Disputes and false positives<\/h2>\n
ASVs are required to work through disputes with you rather than simply publishing a fail. If a finding is a false positive, or if the exposure is mitigated by a control the scanner cannot see, you submit evidence and the ASV reviews it: configuration output, vendor statements confirming a backported fix, or documentation of a compensating control.<\/p>\n
Two practical notes. Evidence has to be specific \u2014 \u00abwe have a WAF\u00bb is not a dispute, but a demonstration that the vulnerable code path is unreachable can be. And disputes take time, which is another argument for scanning early in the quarter.<\/p>\n
An ASV scan is not a penetration test<\/h2>\n
This confusion is expensive, because it leads organizations to buy one control and believe they have satisfied two requirements.<\/p>\n
- Forgotten hosts.<\/strong> A staging server, a legacy VPN endpoint, a marketing microsite on the same public range. In scope whether or not anyone remembers deploying it.<\/li>\n
- Scan Report Summary.<\/strong> Findings organized by host and component, with severity, so the compliance conversation can happen without reading raw output.<\/li>\n
- Certain findings fail automatically, regardless of score.<\/strong> These include software or operating systems no longer supported by the vendor, SQL injection, cross-site scripting on sensitive pages, insecure remote access and default passwords on any reachable service.<\/li>\n<\/ul>\n
- No vulnerability with a CVSS base score of 4.0 or higher<\/strong> may remain anywhere in scope. A single medium-severity finding on a single host fails the whole scan.<\/li>\n
- Requirement 11.3.2.1<\/strong> \u2014 external scans are performed after any significant change<\/strong> to the environment. These do not have to be run by an ASV, but they must be performed by qualified personnel who are organizationally independent of the systems being scanned, and the result belongs in your change-control record.<\/li>\n<\/ul>\n
- A single vulnerability scoring CVSS 4.0 or higher<\/strong> fails the entire scan \u2014 and some findings fail regardless of score.<\/li>\n