PCI DSS 11.3.1.3: Internal vulnerability scans are performed after any significant change
PCI DSS v4.0.1 control 11.3.1.3: 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
Internal vulnerability scans are performed after any significant change as follows:
- 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 conducted as needed.
- Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
Summary
Scan internally after a significant change, fix the high-risk and critical findings, and have someone independent do the scanning.
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.3.a | Examine change control documentation and internal scan reports to verify that system components were scanned after any significant changes. |
| 11.3.1.3.b | Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that all high-risk vulnerabilities and all critical vulnerabilities (defined in PCI DSS Requirement 6.3.1) were resolved. |
| 11.3.1.3.c | Interview personnel to verify that internal scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists. |
Two things surprise people here. The first is that the tester must be organisationally independent even though this is a scan rather than a penetration test: the person who made the change should not be the only person confirming it introduced nothing. The standard is explicit that this does not require a QSA or an ASV, so an internal resource from a different team satisfies it. The second is scope: "significant change" is your definition, and it comes from the change control process in 6.5.1. Procedure 11.3.1.3.a examines change control documentation against scan reports, so the assessor picks changes from your own records and looks for the scan that should have followed. A narrow definition of significant is therefore visible rather than convenient.
What to prepare
- The definition of significant change, and where it lives in the change process.
- Change records for the period, so scans can be matched to them.
- Scan and rescan reports for those changes, showing high-risk and critical findings resolved.
- Who performed the scans, and their independence from the change.
How to implement it
1. Define significant change in the change process, not in the scanning procedure. It has to be a field on the change record, or matching scans to changes is manual archaeology.
2. Trigger the scan from the change. A post-implementation step in the change workflow is what makes 11.3.1.3.a answerable, since the assessor works from the change records.
3. Use a different team, and record who. Independence is interviewed in 11.3.1.3.c, so the answer needs a name and a reporting line.
4. Rescan to close. The second element is rescans as needed, and a fix with no rescan leaves the finding open on the evidence.
Where this commonly fails
- A definition of significant change narrow enough that nothing ever qualifies.
- Scans performed by the engineer who made the change, failing the independence element.
- Quarterly scanning treated as covering this, when the trigger here is the change and not the calendar.
- Changes and scans held in systems that cannot be reconciled, so the pairing cannot be shown.
Related controls
This control refers to 6.3.1.
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.2 | External vulnerability scans… |
| 11.3.2.1 | External vulnerability scans are performed after any significant change… |
← 11.3.1.2 · All controls · 11.3.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.