PCI DSS 5.2.1: Run anti-malware everywhere, except on systems you have specifically evaluated and concluded are not at risk, and be able to show that evaluation.
PCI DSS v4.0.1 control 5.2.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 5.2.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.2
An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware.
Summary
Run anti-malware everywhere, except on systems you have specifically evaluated and concluded are not at risk, and be able to show that evaluation.
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.1.a | Examine system components to verify that an anti-malware solution(s) is deployed on all system components, except for those determined to not be at risk from malware based on periodic evaluations per Requirement 5.2.3. |
| 5.2.1.b | For any system components without an anti-malware solution, examine the periodic evaluations to verify the component was evaluated and the evaluation concludes that the component is not at risk from malware. |
The exception is the whole control. "All system components" is the default and the only way out is the periodic evaluation in 5.2.3, which has to be documented, reasoned and repeated. 5.2.1.a examines system components to verify the solution is actually deployed on them; 5.2.1.b examines the periodic evaluations for any component without one, to verify it was evaluated and found not at risk. An entity that decided Linux servers do not need anti-malware, and never wrote down why, fails both the evaluation and this control. Note that the standard does not demand signature-based antivirus specifically: 5.2.2 asks for a solution that detects and addresses all known types of malware, by whatever technique. The evaluation route exists because some systems may not currently be commonly targeted or affected by malware.
What to prepare
- An inventory of system components with, for each, either the deployed solution or a reference to the evaluation that excluded it.
- The periodic evaluations required by 5.2.3, with dates, reasoning and the conclusion.
- Evidence of deployment on a sample of components, not just a purchase record for the product.
How to implement it
1. Decide the exception list from the inventory, not the other way round. The control is written so the default is coverage. Listing what you excluded and why is defensible; discovering at assessment time that a class of systems was never considered is not.
2. Keep the evaluation specific. "Linux is not commonly affected by malware" is an assertion. An evaluation names the evolving malware threats to those systems, their exposure and any other controls that reduce it, and reaches a conclusion. That is what 5.2.3 asks you to repeat.
3. Check deployment rather than licensing. 5.2.1.a examines system components. A licence count matching the server count proves procurement, not deployment, and agents fail quietly.
4. Include the systems that are not servers. Workstations that access the environment, virtual desktops and build agents are system components too, and are often where malware actually arrives.
Where this commonly fails
- An exclusion that was never evaluated, only assumed, which fails this control and 5.2.3 together.
- Agents installed but not running or not updating, so deployment evidence and reality differ.
- An evaluation performed once at the last assessment, when 5.2.3 asks for it periodically.
- Coverage measured against a server list that predates the last three months of provisioning.
Related controls
This control refers to 5.2.3.
Others in section 5.2:
| Control | What it requires |
|---|---|
| 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.1 | The frequency of periodic evaluations of system components identified as not at risk… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 5.1.2 · All controls · 5.2.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.