PCI DSS 5.2.3.1: The frequency of periodic evaluations of system components identified as not at risk
PCI DSS v4.0.1 control 5.2.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 5.2.
Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.2
The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Summary
You choose how often the not-at-risk decisions are re-examined, and you have to justify the interval with a risk analysis.
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 | |
|---|---|
| 5.2.3.1.a | Examine the entity’s targeted risk analysis for the frequency of periodic evaluations of system components identified as not at risk for malware to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1. |
| 5.2.3.1.b | Examine documented results of periodic evaluations of system components identified as not at risk for malware and interview personnel to verify that evaluations are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement. |
The frequency behind 5.2.3, and one of six controls in the standard built on the same pattern: the interval is yours provided a targeted risk analysis under 12.3.1 exists. The others are 8.6.3, 10.4.2.1, 11.3.1.1, 12.10.4.1 and 5.3.2.1 alongside it in this requirement. Each has a procedure that examines the analysis and a second that checks the interval was actually met, and each requires an analysis performed for that requirement rather than one general document cited six times. What makes this instance worth doing carefully is that the underlying judgement ages: a system component genuinely not at risk in one threat landscape may not stay that way, which is the whole reason 5.2.3 asks for re-evaluation at all.
What to prepare
- The targeted risk analysis for this frequency specifically.
- The documented list of components deemed not at risk, from 5.2.3.
- Documented results of the periodic evaluations at the interval chosen.
- The 12-month review of the analysis that 12.3.1 requires.
How to implement it
1. Write the analysis before choosing the number, as with the other five. It is the artefact 5.2.3.1.a examines.
2. Let the threat landscape drive the interval. The argument that makes this analysis real is about how quickly malware targeting those component types is evolving, not about how much effort a review costs.
3. Set an interval you will meet. 5.2.3.1.b examines documented results against your own number.
4. Keep it with the other five. One register of targeted risk analyses makes the annual 12.3.1 review a single task rather than six.
Where this commonly fails
- A sensible interval with no analysis behind it, which fails on the evidence rather than the decision.
- One generic risk analysis cited for every frequency the standard leaves open, addressing none specifically.
- Evaluations performed and not documented, leaving 5.2.3.1.b nothing to examine.
- The not-at-risk list itself never revisited, so the frequency governs a review that changes nothing.
Related controls
This control refers to 12.3.1.
Others in section 5.2:
| Control | What it requires |
|---|---|
| 5.2.1 | An anti-malware solution(s) is deployed on all system components… |
| 5.2.2 | The deployed anti-malware solution(s)… |
| 5.2.3 | Any system components that are not at risk for malware are evaluated periodically… |
← 5.2.3 · All controls · 5.3.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.