Requirement 5: Protect All Systems and Networks from Malicious Software

Requirement 5 moved with the threat. v4.0.1 accepts that signature-based antivirus on every host is no longer the only defensible answer, but it demands you justify whatever you do instead.

PCI DSS v4.0.1 breaks this requirement into 4 sections containing 13 individual controls.

What this requirement is actually asking

Where a system is "not commonly affected by malware", you can omit anti-malware software, but only on the back of a documented, periodic risk analysis (5.2.3). 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 DMARC enforcement 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

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) 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.