We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

Talk to an expert
PCI DSS v4.0.1 · Requirement 5 of 12

Requirement 5: Protect All Systems and Networks from Malicious Software

v4 modernised the old "antivirus" requirement: coverage decisions must be justified, scan frequency can be risk-based — and anti-phishing controls are now mandatory. The classic failure is the fleet of Linux servers exempted years ago with no documented evaluation.

Reviewed by Abhay Singh, PCI SSC-qualified QSA professional · CyberSigma is a PCI SSC-listed QSA company · Part of the Requirement 1–12 series

The controls that decide your assessment

5.2.1
Anti-malware on all commonly-affected systems

Every system component commonly affected by malware runs an anti-malware solution.

5.2.3
Exempted systems periodically re-evaluated

Components deemed "not commonly affected" are listed and re-evaluated at a frequency set by targeted risk analysis — the exemption must be earned repeatedly, not inherited.

5.3.2
Real-time or periodic scans, risk-based frequency

The solution performs real-time protection, continuous behavioural analysis, or periodic scans at a TRA-defined frequency (5.3.2.1).

5.3.3
Removable media scanned

Removable media gets scanned or continuously protected when connected — USB remains a live infection path in POS and warehouse environments.

5.3.5
Users cannot disable protection

Anti-malware cannot be disabled or altered by users except case-by-case with management authorisation for a limited period.

5.4.1
Anti-phishing controls (new in v4)

Processes and automated mechanisms detect and protect personnel against phishing attacks — DMARC/SPF/DKIM, link/attachment filtering, plus the awareness side in 12.6.3.1. Fully effective 31 March 2025.

Control numbers reference PCI DSS v4.0.1 (June 2024). Verify wording against the standard itself — PCI SSC document library.

Where programmes actually fail

Linux/Unix exempted with no evaluation on file

5.2.3 demands a documented, periodically refreshed justification. "Linux doesn’t get viruses" from 2019 is a finding, not an evaluation.

No technical anti-phishing layer

Awareness training alone does not satisfy 5.4.1 — the control asks for mechanisms: email authentication, filtering, link protection.

Local admins can kill the agent

If endpoint users can stop the service, 5.3.5 fails regardless of how good the console dashboard looks.

Evidence a QSA accepts

A policy document proves intent; configuration proves control. Bring these to the assessment:

  • Anti-malware console coverage report reconciled against the asset inventory
  • Documented evaluation of exempted system types with review dates (5.2.3)
  • Targeted risk analysis supporting scan frequency (5.3.2.1)
  • Email security configuration: DMARC/SPF/DKIM, filtering, link protection (5.4.1)
  • Policy/config showing users cannot disable protection (5.3.5)

Requirement 5 FAQ

Is antivirus required on Linux servers in the CDE?

Either deploy anti-malware or maintain a documented, periodically re-evaluated determination that the component type is not commonly affected (5.2.3). Silence is non-compliance.

What satisfies the new anti-phishing requirement 5.4.1?

Technical mechanisms — email authentication (DMARC/SPF/DKIM), anti-phishing filtering, link and attachment protection — combined with the phishing-awareness training required by 12.6.3.1.

Can we scan weekly instead of daily?

Periodic-scan frequency can be defined by your targeted risk analysis (5.3.2.1) — documented, justified and approved, rather than defaulting to a vendor preset.

← Requirement 4: Encryption in TransitRequirement 6: Secure Development & Patching →

Requirement 5 in your environment

A PCI SSC-listed QSA firm can tell you in one session whether your controls will survive assessment — before the assessment.