Requirement 5: Protect All Systems and Networks from Malicious Software
PCI DSS v4.0.1 Requirement 5: anti-malware coverage, the risk-analysis route for systems not commonly affected, and the new anti-phishing control.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 5 moved with the threat. Since v4.0, the standard accepts that signature-based antivirus is not the only defensible answer, but leaving a component without anti-malware needs a documented evaluation behind it (5.2.3).
PCI DSS v4.0.1 breaks this requirement into 4 sections containing 13 individual controls.
What this requirement is actually asking
Where a system component is "not at risk for malware", you can omit anti-malware software, but only on the back of a documented periodic evaluation (5.2.3), repeated at a frequency set by a targeted risk analysis (5.2.3.1). Skipping the analysis and simply asserting Linux does not get malware is a finding.
5.4 is new in v4: anti-phishing mechanisms protecting personnel. This is a technical control, not just training. Think email authentication (SPF, DKIM and DMARC) and link protection, with training covered separately under Requirement 12.
Does it apply to you?
All in-scope system components, with the risk-analysis exemption available per component type.
The controls
Requirement 5 contains 13 controls across 4 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.
5.1: Governance for anti-malware processes
| Control | What it requires | Guidance |
|---|---|---|
| 5.1.1 | All security policies and operational procedures that are identified in Requirement 5… | Yes |
| 5.1.2 | Roles and responsibilities for performing activities in Requirement 5 are documented, assigned… | Yes |
5.2: Malware is prevented or detected across in-scope components
| Control | What it requires | Guidance |
|---|---|---|
| 5.2.1 | An anti-malware solution(s) is deployed on all system components… | Yes |
| 5.2.2 | The deployed anti-malware solution(s)… | Yes |
| 5.2.3 | Any system components that are not at risk for malware are evaluated periodically… | Yes |
| 5.2.3.1 | The frequency of periodic evaluations of system components identified as not at risk… | Yes |
5.3: Mechanisms stay active, current, and generate audit logs
| Control | What it requires | Guidance |
|---|---|---|
| 5.3.1 | The anti-malware solution(s) is kept current via automatic updates | Yes |
| 5.3.2 | The anti-malware solution(s)… | Yes |
| 5.3.2.1 | If periodic malware scans are performed to meet Requirement 5.3.2… | Yes |
| 5.3.3 | For removable electronic media, the anti-malware solution(s)… | Yes |
| 5.3.4 | Audit logs for the anti-malware solution(s) are enabled and retained in accordance… | Yes |
| 5.3.5 | Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented… | Yes |
5.4: Anti-phishing protection for personnel (new in v4)
| Control | What it requires | Guidance |
|---|---|---|
| 5.4.1 | Processes and automated mechanisms are in place to detect and protect personnel against… | Yes |
Evidence your assessor will ask for
- Coverage report showing every in-scope component against its anti-malware status
- The documented risk analysis for any component type where anti-malware is not deployed, dated within the review period
- Evidence that users cannot disable the mechanism (5.3.5)
Where this commonly fails
- Claiming the 5.2.3 exemption without the periodic risk analysis to support it
- Anti-malware installed but not reporting centrally, so coverage gaps go unnoticed
- Treating 5.4 as satisfied by the security awareness training that Requirement 12 already asks for
Terms
Glossary entries that name a control in this requirement:
- Anti-Malware: 5.2.1, 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5
- Malware: 5.2.1, 5.2.2, 5.2.3, 5.3.1, 5.3.2, 5.3.5
- Operating System: 5.3.2
- Phishing: 5.4.1
- Removable Electronic Media: 5.3.3
- Risk: 5.2.3, 5.2.3.1
- System Component: 5.2.1
Official source
The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard 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.