Vulnerability scanning under PCI DSS is not the same as penetration testing. Scanning identifies known vulnerabilities through automated checks. Penetration testing validates whether those vulnerabilities can be exploited by an attacker. PCI DSS requires both, on different schedules, with different standards for what constitutes a passing result.
Requirement 11.3 covers vulnerability scanning. You need both internal and external scans, performed quarterly, plus scans after any significant change. External scans must be performed by an Approved Scanning Vendor (ASV). Internal scans can be performed by qualified internal staff or a third party.
External ASV Scanning
External vulnerability scans must be performed by an ASV approved by the PCI Security Standards Council. The ASV scans your internet-facing systems, including web servers, email servers, DNS servers, firewalls, and any other systems with public IP addresses that are in scope for PCI DSS.
Passing criteria
A passing ASV scan has no vulnerabilities scored at CVSS 4.0 or higher. Additionally, there must be no automatic failures, which include:
- DNS zone transfers enabled
- Unrestricted open mail relays
- SQL injection vulnerabilities
- Cross-site scripting (XSS) vulnerabilities
- Directory traversal vulnerabilities
- Default or trivial credentials detected
- Unpatched systems with known critical vulnerabilities
| Aspect | External (ASV) Scan | Internal Scan |
|---|---|---|
| Performed by | PCI SSC Approved Scanning Vendor | Qualified internal staff or third party |
| Scope | Internet-facing systems in CDE scope | All internal CDE systems and connected systems |
| Frequency | At least quarterly + after significant changes | At least quarterly + after significant changes |
| Pass criteria | No vulns CVSS 4.0+, no automatic failures | All high-risk vulns resolved per org risk ranking |
| Authentication | Unauthenticated (external perspective) | Authenticated scans recommended (v4.0: 11.3.1.2) |
| Report format | Standardized ASV scan report | Internal format, must document process and results |
Internal Vulnerability Scanning
Internal scans target all system components within the CDE and any systems connected to the CDE. Unlike ASV scans, internal scans can be performed by your own team if they have the necessary qualifications and independence from the systems being scanned.
PCI DSS v4.0 added Requirement 11.3.1.2, which specifies that internal vulnerability scans should be performed with authenticated scanning. Authenticated scans use credentials to log into systems and check for vulnerabilities from the inside, catching patch-level issues and configuration problems that unauthenticated scans miss. This was previously a best practice; it is now a dated requirement effective after the v4.0 transition.
Key distinction: Internal scan pass criteria are different from ASV scans. There is no CVSS 4.0 threshold. Instead, you must resolve all vulnerabilities ranked as high-risk according to your organization's vulnerability risk-ranking process defined in Requirement 6.3.1. You define what "high risk" means, but your assessor must agree it is reasonable.
Scan Frequency and Significant Changes
Both internal and external scans must be performed at least quarterly. But "quarterly" does not mean once every three months with flexible timing. Your four quarterly scans must cover the full year without gaps exceeding 90 days between scans. If you scan on January 15 and then not again until May 1, you have a gap and are non-compliant.
Additionally, scans must be performed after any significant change. PCI DSS defines significant changes as including: new system component installations, changes in network topology, firewall rule modifications, product upgrades, and web server configuration changes. Document what your organization considers a "significant change" and ensure scans are triggered accordingly.
Handling False Positives
False positives in vulnerability scans are inevitable. A web application firewall may mask a vulnerability the scanner detects in the underlying application. A scanner may flag a version number as vulnerable when a backported patch has already been applied.
For ASV scans, you can dispute findings with the ASV. Provide evidence that the vulnerability is a false positive (such as patch verification, WAF rules, or compensating controls), and the ASV can mark it as an exception. Document this process thoroughly, as your QSA will review disputed findings.
For internal scans, maintain a formal false positive tracking process. Each false positive must be verified, documented with evidence, and reviewed periodically to ensure it remains a false positive. Do not simply suppress findings without documentation.
Common Scanning Failures
- Incomplete scope. Scanning only web servers but missing database servers, internal APIs, or network devices within the CDE
- Unauthenticated internal scans only. Running internal scans without credentials misses a significant number of patch-level and configuration vulnerabilities
- Remediation delays. Identifying high-risk vulnerabilities in Q1 and not remediating them until Q3. Rescans after remediation must show the vulnerabilities are resolved
- Missing post-change scans. Performing quarterly scans on schedule but not scanning after significant infrastructure changes between quarters
- No vulnerability risk-ranking process. Requirement 6.3.1 mandates a process for ranking vulnerabilities by risk. Without it, you cannot define what constitutes a passing internal scan
Need PCI DSS vulnerability scanning support?
We provide both vulnerability scanning and penetration testing for PCI DSS compliance. Get your scanning program validated before your assessment.
