Malware Protection for PCI DSS: What Requirement 5 Asks For

Requirement 5 of PCI DSS v4.0.1 is "Protect all systems and networks from malicious software". It has 13 controls. This article goes through them: where anti-malware has to run, the exception for systems not at risk, what the solution itself must do, and the phishing requirement that became mandatory on 31 March 2025. The Requirement 5 overview lists every control with its testing procedures.

Where it has to run

5.2.1 requires an anti-malware solution on all system components, with one exception: components that a periodic evaluation under 5.2.3 concludes are not at risk from malware.

That exception is narrower than it sounds. v4.0.1 does not exempt a system because it runs a particular operating system; it asks the entity to justify each case and keep justifying it. 5.2.3 requires:

• a documented list of every system component not at risk;
• identification and evaluation of evolving malware threats for those components;
• confirmation of whether each still does not need anti-malware protection.

The guidance says a conclusion that a system is not susceptible should be backed by industry evidence, vendor resources and best practice, and that trends in malware belong in the vulnerability identification process under 6.3.1. How often the evaluation happens is set by the entity's targeted risk analysis (5.2.3.1).

What the solution must do

• Detect and deal with all known types of malware: detect them, and remove, block or contain them (5.2.2). "Anti-virus" in the narrow sense is not enough if it misses whole classes such as ransomware or rootkits.
• Stay current by automatic updates (5.3.1). The standard sets no interval; the requirement is that updating is automatic.
• Scan or watch continuously. 5.3.2 accepts either periodic scans together with active or real-time scans, or continuous behavioural analysis of systems or processes. A tool that works by behavioural analysis, as many endpoint detection and response products do, can meet it on that second route. If periodic scans are used, their frequency comes from a targeted risk analysis (5.3.2.1).
• Check removable media automatically when it is inserted, connected or mounted, by a scan or by behavioural analysis (5.3.3).
• Keep its own audit logs, enabled and retained under 10.5.1: 12 months, with the most recent three immediately available (5.3.4).
• Resist being switched off. Users cannot disable or alter it unless management has authorised that case by case, in writing, for a limited time (5.3.5).

A failure of the anti-malware solution is itself a critical security control failure that must be detected, alerted on and dealt with promptly (10.7.2). A silent agent that stopped updating last month is a finding in its own right.

Phishing

5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing attacks. It was future-dated in v4.0 and has been assessed since 31 March 2025. The requirement names no technology. Its guidance suggests combining anti-spoofing controls such as DMARC, SPF and DKIM, which stop phishers impersonating the entity's own domain, with technologies that block phishing emails and malware before they reach people, such as link scrubbers and server-side anti-malware. Security awareness training has to cover phishing and social engineering too, under 12.6.3.1. PCI DSS v4.0.1 anti-phishing requirements goes further.

Policies and people

Requirement 5 opens, like every requirement, with documented and current policies and procedures that are in use and known to the people affected (5.1.1), and roles and responsibilities that are documented, assigned and understood (5.1.2).

When malware is found

The detection is where Requirement 5 hands over to the rest of the standard:

1. Contain the affected system, using the solution's own quarantine and network isolation.
2. Activate the incident response plan (12.10.1) and keep the evidence.
3. Work out whether account data could have been reached, and who has to be told; the plan must cover notifying payment brands and acquirers and analysing legal reporting duties.
4. Find how it got in, fix that, and restore from known-good sources.
5. Feed what was learned into the vulnerability process (6.3.1) and, if a system on the not-at-risk list was involved, into the next 5.2.3 evaluation.