PCI DSS 11.3.2: External vulnerability scans
PCI DSS v4.0.1 control 11.3.2: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 11.3.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.3
External vulnerability scans are performed as follows:
- At least once every three months.
- By a PCI SSC Approved Scanning Vendor (ASV).
- Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.
- Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
Summary
Have an approved external scanning vendor scan your internet-facing systems every three months, fix what they find, and rescan until you pass.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.3.2.a | Examine ASV scan reports from the last 12 months to verify that external vulnerability scans occurred at least once every three months in the most recent 12-month period. |
| 11.3.2.b | Examine the ASV scan report from each scan and rescan run in the last 12 months to verify that vulnerabilities are resolved and the ASV Program Guide requirements for a passing scan are met. |
| 11.3.2.c | Examine the ASV scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV). |
The one control most merchants meet a supplier for, and the wording is exact in ways that catch people. The scan must be by a PCI SSC Approved Scanning Vendor: your own scanner, however good, does not satisfy this. The requirement is not "scan quarterly" but achieve a passing scan per the ASV Program Guide, so a quarter where you scanned, found issues and did not rescan is a quarter without a passing scan. Rescans are named explicitly for that reason. 11.3.2.a examines the reports for the last twelve months, 11.3.2.b verifies they were performed by an ASV, and 11.3.2.c examines evidence of rescans. Distinguish it from 11.3.1, the internal scans, which you may run yourself.
What to prepare
- Four passing ASV scan reports covering the last twelve months, with dates showing the intervals.
- The scope: every internet-facing IP address and domain in scope, agreed with the ASV.
- Rescan reports for any quarter where the first scan did not pass.
- Documentation of any disputed findings and how the ASV resolved them.
How to implement it
1. Agree the scope with the ASV in writing and revisit it. The commonest way to fail is a passing report that did not cover an address added since the scope was set. New environments, a marketing subdomain and a staging host reachable from the internet are the usual omissions.
2. Book the scan early in the quarter. The obligation is a passing scan, and passing may take a remediation cycle and a rescan. Scanning in the last fortnight leaves no room for that, which is how an otherwise compliant entity ends a quarter without a pass.
3. Read the failing findings for false positives before remediating. The ASV Program Guide has a dispute process, and configurations that mimic a vulnerability without being one are common. Disputing with evidence is legitimate and faster than changing something that was correct.
4. Keep the reports. The assessor examines the last twelve months, so this is one of the few controls where the evidence is simply a set of files, and the failure is having lost them.
Where this commonly fails
- Using an internal or commercial scanner that is not an approved ASV, which fails 11.3.2.b however thorough the scan.
- A quarter with a scan but no passing scan, because remediation happened and no rescan followed.
- Scope agreed once and never updated as the estate grew.
- Scans four times a year but clustered, leaving a gap much longer than three months between two of them.
- Assuming a compliant hosting provider covers this for addresses the merchant is responsible for.
Related controls
Others in section 11.3:
| Control | What it requires |
|---|---|
| 11.3.1 | Internal vulnerability scans… |
| 11.3.1.1 | All other applicable vulnerabilities… |
| 11.3.1.2 | Internal vulnerability scans are performed via authenticated scanning… |
| 11.3.1.3 | Internal vulnerability scans are performed after any significant change… |
| 11.3.2.1 | External vulnerability scans are performed after any significant change… |
← 11.3.1.3 · All controls · 11.3.2.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.