PCI DSS 11.3.1: Internal vulnerability scans
PCI DSS v4.0.1 control 11.3.1: the requirement in full, the 4 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
Internal vulnerability scans are performed as follows:
- At least once every three months.
- Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
- Rescans are performed that confirm all high-risk and all critical vulnerabilities (as noted above) have been resolved.
- Scan tool is kept up to date with latest vulnerability information.
- Scans are performed by qualified personnel and organizational independence of the tester exists.
Summary
Scan internally every three months, fix everything your own ranking calls high-risk or critical, and rescan to prove it.
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.1.a | Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period. |
| 11.3.1.b | Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk vulnerabilities and all critical vulnerabilities (defined in PCI DSS Requirement 6.3.1) are resolved. |
| 11.3.1.c | Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information. |
| 11.3.1.d | Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists. |
The internal counterpart to 11.3.2, and the differences matter: you may run these yourself, no approved vendor is required, and the pass condition is your own risk ranking from 6.3.1 rather than an external programme guide. That makes 6.3.1 load-bearing here: a ranking that never produces a critical produces nothing to resolve. Four procedures, and the fourth covers the qualification and independence of whoever scans. As with the external scan, the obligation is not "scan quarterly" but scan, resolve and rescan.
What to prepare
- Four quarters of internal scan reports.
- The risk ranking from 6.3.1 that decides what must be resolved.
- Rescan evidence showing high-risk and critical findings were fixed, not just noted.
- The scanner’s scope against the system inventory, and the scanner operator’s qualification.
How to implement it
1. Scan authenticated where you can. Unauthenticated internal scans see a fraction of what is there, and the missing part is usually where the criticals are.
2. Reconcile scope with the inventory each quarter. New components are the ones most likely to be unpatched and least likely to be in a scan profile written a year ago.
3. Let 6.3.1 decide, and keep them consistent. If your ranking and your scanner’s severity labels disagree, write down which governs. An assessor will ask, and "the tool said medium" is not a ranking.
4. Schedule the rescan when you schedule the scan. The requirement is a passing state, not an activity, and remediation without verification leaves the quarter unevidenced.
Where this commonly fails
- Quarterly scans with no rescan, so nothing shows the criticals were resolved.
- Unauthenticated scans presented as full internal coverage.
- Scanner severity used in place of the entity’s own ranking, which the requirement names.
- Segments excluded from scanning because they are "out of scope", without the segmentation evidence to support it.
Related controls
This control refers to 6.3.1.
Others in section 11.3:
| Control | What it requires |
|---|---|
| 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 | External vulnerability scans… |
| 11.3.2.1 | External vulnerability scans are performed after any significant change… |
← 11.2.2 · All controls · 11.3.1.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.