PCI DSS 11.3.1.1: All other applicable vulnerabilities
PCI DSS v4.0.1 control 11.3.1.1: the requirement in full, the 2 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
All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows:
- Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
- Rescans are conducted as needed.
Summary
The vulnerabilities you did not call high-risk or critical still have to be dealt with, on a timescale you have justified.
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.1.a | Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1. |
| 11.3.1.1.b | Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed. |
This closes the gap 11.3.1 leaves. That control says fix everything your own ranking calls high-risk or critical; this one says the remainder cannot simply be left, and that how you treat them is decided in a targeted risk analysis performed according to all elements specified in 12.3.1. It is the fourth control built on that pattern, alongside 8.6.3, 10.4.2.1 and 12.10.4.1. The common position it is written against is "we fix criticals and highs", with nothing at all said about the mediums and lows that make up most of any scan. Note the dependency on 6.3.1: the ranking that decides which bucket a finding lands in is defined there, so a weak ranking pushes work into this control without anyone deciding to.
What to prepare
- The targeted risk analysis defining how the remaining vulnerabilities are addressed.
- The risk ranking from 6.3.1 that decides what falls into this control.
- Scan results showing lower-ranked findings being handled at the pace the analysis sets.
- Rescan evidence where a fix was applied.
How to implement it
1. Write the analysis before choosing the timescale, as with the other three controls of this shape. It is the artefact 11.3.1.1.a examines.
2. Set something you will meet. 11.3.1.1.b interviews personnel and examines scan results against your own definition, so a generous timescale honoured beats a strict one ignored.
3. Check the ranking in 6.3.1 first. If everything lands in medium, this control carries the entire remediation programme, which is probably not what was intended.
4. Let ageing drive it. A rule that a medium unaddressed for a defined period escalates is easier to evidence than a promise to address them by risk.
Where this commonly fails
- Only high and critical findings tracked, with the rest accumulating unexamined.
- A timescale asserted with no targeted risk analysis behind it.
- One generic risk analysis cited for every frequency the standard leaves open, addressing none specifically.
- A risk ranking that classifies almost nothing as high, quietly moving the whole programme into this control.
Related controls
This control refers to 6.3.1, 12.3.1.
Others in section 11.3:
| Control | What it requires |
|---|---|
| 11.3.1 | Internal vulnerability scans… |
| 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.3.1 · All controls · 11.3.1.2 →
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.