ASV Scanning: What Payment Pages Need to Pass

When a failed ASV scan appears right before a QSA visit, there may be little time to fix the finding and verify it with a re-scan. ASV scanning is often treated as a simple PCI DSS checklist item: schedule a scan, receive the report, and give it to the QSA. In practice, scan scope, findings, and response require careful handling.

What ASV Scans Test, and What They Do Not

An Approved Scanning Vendor scan checks external IP addresses and hostnames for known vulnerabilities visible from outside your network perimeter. The ASV scanner attempts to find open ports, reachable services, and exploitable vulnerabilities across each in-scope IP address and hostname you provide.

It does not examine internal network controls or application logic, and it does not find vulnerabilities requiring authenticated access or an insider position. It does not assess your CDE as an internal attacker, compromised internal host, or authenticated user would. Those areas belong to internal vulnerability scanning under Requirement 11.3 and penetration testing under Requirement 11.4.

This distinction matters because a clean ASV result does not prove that the whole environment is secure. A passing scan means your external IP addresses and hostnames showed no exploitable vulnerabilities detectable from outside the perimeter at scan time. That is a narrower conclusion than many merchants assume.

Requirement 11.3.2: How Often to Scan

Requirement 11.3.2 calls for external vulnerability scans by an ASV at least once every three months. "At least" matters: four scans a year is the minimum, not a limit. A major deployment, cloud expansion, or newly exposed endpoint during the quarter can introduce exposure that a quarterly schedule will not find until the next scan.

Under 11.3.2, the requirement is not merely to run the scan. It must pass. A scan passes when all findings fall below the severity threshold in the ASV Program Guide, or when findings above that threshold are fixed and a re-scan verifies the fix. A report with unresolved high-severity findings is not passing, no matter when the scan ran.

Set the Right Scan Scope

Incorrect scope is a common source of misleading scan results. The scan should include every external IP address and hostname an attacker could use to reach or influence your CDE. This can include public web application servers, API endpoints, load balancers, VPN concentrators, remote access gateways, email gateways with a network path to CDE systems, and DNS servers authoritative for payment-page domains.

Common omissions include secondary server IP addresses, newly added cloud instances, internet-reachable administrative IP addresses meant to be restricted, and development or staging hostnames sharing production infrastructure. A passing report from an incomplete IP list does not represent the real external attack surface.

For an e-commerce environment in AWS, every Elastic IP tied to CDE-connected instances belongs in scope. If a CDN sits in front of checkout pages, assess both its edge IPs and the origin server IPs. The CDN may absorb some attacks, but the origin can still be reached by bypassing the CDN, so that route also needs testing.

How to Read Findings, Exceptions, and Not-Applicable Results

ASV reports sort findings by severity. PCI DSS requires level 4 and higher findings to be remediated or covered by an approved exception before the scan passes. Levels 1 through 3 are informational and do not fail the scan, though QSAs may ask about recurring lower-severity findings that indicate a wider vulnerability management gap.

A not-applicable result means the scanner detected a possible vulnerability, but your environment's configuration makes it irrelevant. You need documented justification, which the QSA will review. Examples include a version-based detection where the vulnerable feature is disabled or absent despite its version identifier, and a protocol detection where a firewall blocks the listed protocol beyond the scanner's view.

For a finding that cannot be fixed immediately, the exception process requires an agreed remediation timeline and documentation of compensating controls. An exception is not a blanket pass. A QSA will closely review evidence containing several unresolved ASV findings, including findings handled through the exception process. Reserve exceptions for genuine technical barriers, not as a replacement for patch management.

The Week-Before Timing Issue

A failed scan in the week before a QSA visit is difficult to resolve. The finding must be fixed, the fix verified through a re-scan, and that re-scan scheduled with the ASV. A high-severity issue needing five business days to remediate, followed by a re-scan with a 48-hour turnaround, may not be cleared before the assessment.

A missing scan is more serious. If the required quarterly scan was never performed, Requirement 11.3.2 has an automatic finding. A scan that did not happen has no compensating control, and the QSA cannot accept evidence that does not exist.

Automatic scans on a defined quarterly schedule remove much of this timing risk. The scan runs without someone needing to remember it, and findings appear weeks rather than days before the assessment. Remediation can then happen during normal operations instead of crisis mode.

Payment Pages, Requirement 6.4.3

PCI DSS 4.0 added Requirement 6.4.3, which sets requirements for managing payment-page scripts. ASV scanning does not test this requirement, but it concerns the same payment-page security area and is often reviewed alongside scan results. Requirement 6.4.3 requires a documented purpose for every script, integrity protection through a hash or similar method, and a process to detect unauthorized payment-page changes.

For JavaScript-heavy checkout pages using several analytics, A/B testing, and payment SDK scripts, this creates a mapping and documentation burden. Inventory every script, document its origin, and verify its integrity on each page load or with monitoring that detects changes. A payment page loading 12 third-party scripts without integrity controls has a 6.4.3 finding, even with a clean ASV scan.

ASV scanning and payment-page script management cover different layers of one risk: an exploitable path for customers entering card data. External scanning checks whether servers can be exploited from outside. Script management checks whether the page environment customers use has been tampered with. Both layers must be clean for a complete payment-page security assessment.