PCI DSS 5.3.1: The anti-malware solution(s) is kept current via automatic updates
PCI DSS v4.0.1 control 5.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 5.3.
Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.3
The anti-malware solution(s) is kept current via automatic updates.
Summary
Anti-malware updates itself automatically. Not on request, not when someone remembers.
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.3.1.a | Examine anti-malware solution(s) configurations, including any master installation of the software, to verify the solution is configured to perform automatic updates. |
| 5.3.1.b | Examine system components and logs, to verify that the anti-malware solution(s) and definitions are current and have been promptly deployed |
Short and mechanical, and it fails in one predictable way: the agent is deployed as 5.2.1 requires and its definitions are months old, because the machine cannot reach the update source, the licence lapsed, or the agent stopped and nothing watched for it. 5.3.1.a examines the configuration for automatic updates; 5.3.1.b examines system components to verify the solution is actually current. The second is the one that finds the gap, which is why the evidence to collect is a report of update times across the estate, not a screenshot of the setting.
What to prepare
- The configuration showing automatic updates enabled.
- A report of last-update times across system components, which is what 5.3.1.b samples.
- Evidence of alerting when a component falls behind.
How to implement it
1. Alert on staleness, not on failure. An update that never runs produces no failure event. What catches it is an agent reporting its last-update time and something noticing when that ages.
2. Check the egress path. Hosts in a segmented environment often cannot reach the vendor, and the agent degrades quietly rather than announcing it.
3. Watch licence expiry. An expired licence usually stops updates while leaving the agent apparently running, which looks correct in a screenshot and fails 5.3.1.b.
4. Sample the way an assessor will. Pick components from across the estate rather than from the managed core, since the outliers are where staleness lives.
Where this commonly fails
- Automatic updates configured and unreachable, so the setting is correct and the definitions are old.
- An expired licence silently stopping updates.
- Update health measured on the console rather than on the endpoints.
- Machines that are off for long periods never reconciled after they return.
Related controls
Others in section 5.3:
| Control | What it requires |
|---|---|
| 5.3.2 | The anti-malware solution(s)… |
| 5.3.2.1 | If periodic malware scans are performed to meet Requirement 5.3.2… |
| 5.3.3 | For removable electronic media, the anti-malware solution(s)… |
| 5.3.4 | Audit logs for the anti-malware solution(s) are enabled and retained in accordance… |
| 5.3.5 | Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented… |
← 5.2.3.1 · All controls · 5.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.