PCI DSS 5.2.3: Any system components that are not at risk for malware are evaluated periodically
PCI DSS v4.0.1 control 5.2.3: the requirement in full, the 3 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
Any system components that are not at risk for malware are evaluated periodically to include the following:
- A documented list of all system components not at risk for malware.
- Identification and evaluation of evolving malware threats for those system components.
- Confirmation whether such system components continue to not require anti-malware protection.
Summary
If you decided some systems do not need anti-malware, re-examine that decision periodically and write down what you concluded.
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.a | Examine documented policies and procedures to verify that a process is defined for periodic evaluations of any system components that are not at risk for malware that includes all elements specified in this requirement. |
| 5.2.3.b | Interview personnel to verify that the evaluations include all elements specified in this requirement. |
| 5.2.3.c | Examine the list of system components identified as not at risk of malware and compare to the system components without an anti-malware solution deployed per Requirement 5.2.1 to verify that the system components match for both requirements. |
This is the exception route out of 5.2.1, and it is a live obligation rather than a one-off exemption. Three elements: a documented list of the excluded components, identification and evaluation of evolving threats to them, and a confirmation that the exclusion still holds. The word doing the work is evolving: the evaluation exists because the threat landscape moves, so an assessment written years ago and never revisited fails even if its reasoning was sound at the time. 5.2.3.a examines the policy, 5.2.3.b the evaluations themselves, 5.2.3.c the list against the current environment.
What to prepare
- The documented list of system components excluded from anti-malware protection.
- Dated evaluations, each naming the threats considered and the conclusion reached.
- The frequency defined for the evaluation, and evidence it has been met.
- A reconciliation of the list against the current system inventory.
How to implement it
1. Write the evaluation as an argument, not an assertion. Name the malware threat relevant to that platform, say why the component is not at risk, and note what would change the answer. That last part is what makes the next evaluation cheap.
2. Tie the frequency to something that already recurs. The requirement leaves the period to your targeted risk analysis; in practice attaching it to an existing quarterly or annual cycle is what makes it actually happen.
3. Re-check the list against the inventory, not against last year’s list. New components inherit no decision at all, and copying the previous list forward is how a class of systems ends up excluded without anyone ever having evaluated it.
4. Revisit when the platform changes. A new package manager, a new scripting runtime or a new file-sharing path can change whether a component is at risk, and those are the changes the evaluation is meant to catch.
Where this commonly fails
- Treating the exclusion as permanent, so 5.2.1 passes on paper and this control has nothing dated to examine.
- A list that names platforms rather than components, so nobody can tell which machines it covers.
- An evaluation that repeats the same sentence each period, which shows the process ran but not that anything was considered.
- New systems added to the excluded class by default because they resemble ones already on the list.
Related controls
This control refers to 5.2.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.1 | The frequency of periodic evaluations of system components identified as not at risk… |
← 5.2.2 · All controls · 5.2.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.