PCI DSS 5.3.2.1: If periodic malware scans are performed to meet Requirement 5.3.2
PCI DSS v4.0.1 control 5.3.2.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
If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
Summary
If you scan on a schedule, the schedule has to come from a risk analysis you wrote.
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.2.1.a | Examine the entity’s targeted risk analysis for the frequency of periodic malware scans to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1. |
| 5.3.2.1.b | Examine documented results of periodic malware scans and interview personnel to verify scans are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement. |
Conditional, and the condition is worth reading first: this applies only if periodic malware scans are the route chosen for 5.3.2. An entity relying on continuous behavioural analysis has no periodic frequency and no obligation here. Where it does apply it is the same pattern as the other five, including its sibling 5.2.3.1 in this requirement: the frequency is yours provided a targeted risk analysis under 12.3.1 exists, 5.3.2.1.a examines the analysis, and 5.3.2.1.b examines documented results of the scans against the interval you set. Requirement 5 is the only requirement carrying two of these, which is a reason to keep them in one register rather than writing them separately.
What to prepare
- Confirmation of which 5.3.2 branch you rely on, since that decides whether this applies.
- The targeted risk analysis for scan frequency specifically.
- Scan results at the chosen interval, across the at-risk estate.
- The 12-month review of the analysis.
How to implement it
1. Establish whether it applies before writing anything. Half an hour confirming the 5.3.2 branch can remove the control entirely.
2. Argue the interval from exposure. Systems handling more untrusted input warrant more frequent scanning, and saying so is what makes the analysis more than a formality.
3. Choose an interval the estate can sustain. Scans that are skipped when a machine is off are the usual reason documented results do not match the stated frequency.
4. Handle the machines that are rarely on. Laptops missing their scan window are a coverage gap that shows up directly in 5.3.2.1.b.
Where this commonly fails
- Writing the analysis when behavioural analysis means the control does not apply.
- A frequency defined centrally and not achieved on machines that are frequently powered off.
- One generic risk analysis covering both this and 5.2.3.1 without addressing either specifically.
- Scan results not retained, so the interval cannot be shown to have been met.
Related controls
This control refers to 5.3.2, 12.3.1.
Others in section 5.3:
| Control | What it requires |
|---|---|
| 5.3.1 | The anti-malware solution(s) is kept current via automatic updates |
| 5.3.2 | The anti-malware solution(s)… |
| 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.3.2 · All controls · 5.3.3 →
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.