PCI DSS Requirement 5 Explained

When you look at recent breach reports, one pattern keeps repeating: attackers rarely “hack the card database” directly. More often, they get in through malware, phishing, or compromised endpoints and then move laterally until they reach payment data. European and global threat reports from ENISA and others continue to list malware, ransomware, and phishing among the top threats year after year.

That is exactly the risk PCI DSS Requirement 5 is trying to contain.

In this article, I will briefly explain what PCI DSS is, then walk you through Requirement 5 in PCI DSS v4.0, translating its clauses into practical actions you can take today.

What PCI DSS Is And Why Requirement 5 Matters

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard created and maintained by the PCI Security Standards Council (PCI SSC). It defines a baseline set of technical and operational controls for any organization that stores, processes, or transmits payment card data.

PCI DSS v4.0, released in 2022 and now the active version, organizes controls into 12 core requirements. These cover areas like network security, protection of cardholder data, access control, monitoring, and governance. Many of the new and enhanced controls in v4.0 focus on evolving threats like ransomware, phishing, and cloud-hosted workloads.

Requirement 5 sits under the “Maintain a Vulnerability Management Program” domain and is titled “Protect All Systems and Networks from Malicious Software.” It is where PCI DSS concentrates all expectations around anti-malware, endpoint protection, and anti-phishing technology.

In practical terms, Requirement 5 is where you prove that malware cannot quietly sit on your systems, pivot toward the cardholder data environment (CDE), and exfiltrate payment data or credentials.

How PCI DSS Requirement 5 Is Structured In Version 4.0

PCI DSS v4.0 significantly expanded Requirement 5 compared with version 3.2.1. Previously, it was summarized as “Protect all systems against malware and regularly update anti-virus software or programs.” In v4.0, it becomes “Protect all systems and networks from malicious software,” explicitly recognizing modern threats, EDR/XDR tools, cloud workloads, and behavior-based detection.

The requirement is broken into four main sections, each with detailed sub-requirements:

Each clause maps neatly onto things you already know from endpoint security, SIEM, and email security. The real challenge is proving consistency, coverage, and governance to your QSA.

PRO TIP

When you read Requirement 5, think in three layers: governance (5.1), technical coverage (5.2–5.3), and human-targeting controls (5.4). If you can show that all three work together in your environment, assessments become much smoother.

Requirement 5.1: Policies, Procedures, And Roles That Actually Work

Requirement 5.1 is about making malware defense a managed process rather than a “set and forget” technology. It has two key expectations.

First, all security policies and operational procedures related to Requirement 5 must be documented, kept up to date, in use, and known to all affected parties (5.1.1). This means you need written standards that describe how you deploy, update, monitor, and manage anti-malware and anti-phishing tools, and those documents cannot just sit on a shelf.

Second, roles and responsibilities must be documented, assigned, and understood (5.1.2). The standard explicitly suggests tools such as a RACI matrix to clarify who is responsible, accountable, consulted, and informed. That mapping is essential when something goes wrong, and you need to know who triages alerts, who tunes the EDR platform, who approves exceptions, and who reports to management.

From a practical viewpoint, a good 5.1 implementation usually includes a dedicated malware protection standard, procedures for onboarding and offboarding systems into EDR/AV, a playbook for malware incidents, and a clear description of how exceptions are requested and reviewed.

PRO TIP

Align your Requirement 5 documentation with your existing ISO 27001 and ITIL processes. For example, integrate anti-malware deployment into change management and asset onboarding, and ensure your incident management process explicitly references your malware response playbooks.

Requirement 5.2: Deploy The Right Anti-Malware In The Right Places

Requirement 5.2 is where PCI DSS sets the expectations for where and how anti-malware must run. The core idea is straightforward: malicious software must be prevented, or at least detected and addressed, across all system components that are at risk.

Anti-malware coverage and “not at risk” exceptions

Clause 5.2.1 requires that an anti-malware solution be deployed on all system components, except for those that you can justify as “not at risk from malware” through documented, periodic evaluations under 5.2.3.

The standard’s guidance stresses two points:

1. “System components” is broad. It includes servers, workstations, virtual machines, containers, network devices with operating systems, and often cloud workloads—essentially anything in scope for PCI DSS.
2. Claiming a system is not at risk is an exception, not a default. You must maintain a documented list of such systems, monitor evolving malware threats, and periodically confirm that your conclusion still holds (5.2.3 and 5.2.3.1).

In practice, examples sometimes include hardened appliances where the vendor confirms no malware exposure path, or extremely constrained network devices. Even then, the decision should be backed by vendor documentation and threat intelligence.

PRO TIP

Build an “anti-malware coverage report” from your EDR/AV console and reconcile it with your PCI in-scope asset inventory. Any asset in scope that does not show coverage should either be fixed or appear on your formally approved “not at risk” list with a risk analysis and vendor evidence.

Detecting and stopping all known types of malware

Clause 5.2.2 states that your anti-malware solution must detect and remove, block, or contain all known types of malware. The guidance explicitly mentions viruses, Trojans, worms, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links.

For most organizations, this means:

• Using modern endpoint protection (EDR/XDR or equivalent) rather than legacy, signature-only antivirus.
• Ensuring feature sets like behavioral analysis, sandboxing, and exploit prevention are enabled, not just licensed.

This is also where you consider network-level controls—for example, secure web gateways or next-generation firewalls—to complement endpoint defenses.

Periodic evaluation of systems without anti-malware

Clause 5.2.3 requires you to periodically re-evaluate any system components that you consider “not at risk for malware.” You must keep a documented list, review new malware trends, and confirm whether each system still does not require protection.

Clause 5.2.3.1 goes further by stating that the frequency of these evaluations must be defined in a targeted risk analysis, referencing Requirement 12.3.1. At the time of writing, these targeted risk analyses are no longer just “nice to have” – they are required elements of PCI DSS v4.0.

PRO TIP

Put systems without anti-malware under a quarterly or semi-annual review schedule by default, and document this in your targeted risk analysis. If threat intelligence or vendor advisories show that a platform starts to be targeted by malware, build a predefined path for moving that platform from “exception” to “protected.”

Requirement 5.3: Keep Anti-Malware Effective, Monitored, And Hard To Bypass

Even the best EDR platform does not help if signatures are outdated, scanning is disabled, or logs are not retained. Requirement 5.3 addresses exactly these operational realities.

Automatic updates for anti-malware

Clause 5.3.1 requires anti-malware solutions to be kept current via automatic updates. The guidance encourages updating from a trusted source and allows a central staging point where updates are tested before broad deployment.

For you, this means:

• Enabling automatic updates for signatures and engines.
• Monitoring for agents that have fallen behind.
• Documenting how quickly critical updates must be deployed, including change control where needed.

Real-time scanning or continuous behavioral analysis

Clause 5.3.2 says your anti-malware solution must either perform periodic and real-time scans or provide continuous behavioral analysis of systems or processes. This is PCI DSS explicitly acknowledging newer EDR-style approaches where behavior monitoring replaces traditional scanning on some platforms.

Clause 5.3.2.1 ties the frequency of periodic scans to a targeted risk analysis, again referencing Requirement 12.3.1. This prevents “weekly scans because we always did it that way” and instead asks you to justify frequency based on risk and environment.

The guidance suggests combining scheduled scans, real-time protection, and user-initiated on-demand scans, and stresses that the scope should include all disks, memory, start-up files, email servers, browsers, and often-overlooked components.

PRO TIP

If you rely on EDR behavioral analysis in place of traditional scanning on some workloads, document that architecture clearly for your QSA. Map EDR capabilities (process monitoring, script blocking, exploit prevention) directly to 5.3.2 so it is obvious you meet the intent even if “full AV scans” are not used everywhere.

Scanning removable media

Clause 5.3.3 focuses on removable electronic media such as USB drives. Your anti-malware solution must either automatically scan media when it is inserted, connected, or mounted, or must perform behavioral analysis when this happens.

This is often overlooked in real environments, especially where developers or support staff frequently use USB devices. Attackers still abuse this vector, especially in targeted campaigns and ransomware scenarios.

Logging, monitoring, and preventing users from disabling protection

Finally, Requirement 5.3 closes with two operational controls that matter a lot in incidents: logging and prevention of tampering.

• Clause 5.3.4 requires audit logs for anti-malware solutions to be enabled and retained according to Requirement 10.5.1. That generally means at least one year of retention, with the last 90 days immediately available for analysis.
• Clause 5.3.5 states that anti-malware mechanisms cannot be disabled or altered by users, except where specifically documented, approved by management on a case-by-case basis, and limited in time. The guidance suggests additional safeguards (for example, isolating the system and running a full scan when protection is restored).

From an implementation perspective, you typically enforce this with centrally managed policies, role-based administration of the EDR/AV platform, alerts when protection is disabled, and a formal exception process.

Requirement 5.4: Build Technical Defenses Against Phishing

Requirement 5.4 is new in PCI DSS v4.0 and reflects the reality that phishing is one of the most common delivery mechanisms for malware and credential theft.

Clause 5.4.1 requires “processes and automated mechanisms” to detect and protect personnel against phishing attacks. The guidance encourages using combinations of:

• Email authentication controls, such as SPF, DKIM, and DMARC, are used to prevent domain spoofing.
• Email security gateways that filter phishing messages, rewrite or analyze links, and scan attachments.
• Server-side anti-malware to stop malicious payloads before they reach users.
• Processes for reporting suspicious emails so you can remove similar messages from other inboxes quickly.

Importantly, Requirement 5.4 only concerns the automated mechanisms; it explicitly states that it does not replace security awareness training, which is covered by Requirement 12.6.3.1. Both are needed: technical controls to reduce exposure and training so people recognize what gets through.

For PCI scope, the focus is on personnel with access to in-scope systems, but from a security standpoint, it is usually easier and safer to apply consistent anti-phishing controls across the entire organization.

Putting Requirement 5 Into Practice: A Simple Roadmap

If you are responsible for PCI DSS compliance, you do not need an army of people to make Requirement 5 work. You do need structure. A pragmatic approach often looks like this:

1. Start from the asset inventory.
   Confirm that you have a complete list of PCI in-scope systems and networks, including cloud workloads. Without this, you cannot prove coverage.
2. Document your anti-malware architecture.
   Describe which technologies you use (EDR, AV, secure email gateway, web proxy), where they are deployed, and how they map to 5.2 and 5.3.
3. Define your policies and procedures.
   Create or update your malware protection standard, operational procedures, and exception handling so they explicitly reference Requirement 5.1, 5.2, 5.3, and 5.4.
4. Implement targeted risk analyses.
   Where scan frequencies or evaluation intervals are risk-based (5.2.3.1, 5.3.2.1), perform and document targeted risk analyses using your broader risk management methodology.
5. Wire everything into logging and incident management.
   Make sure anti-malware and anti-phishing logs reach your log management or SIEM platform and are retained in line with Requirement 10. Then map key alerts to incident response playbooks.
6. Prepare for the QSA conversation.
   Assemble evidence such as screenshots of configurations, sample logs, coverage reports, and copies of your risk analyses and procedures. The easier you make it for a QSA to see coverage and governance, the less painful the assessment will be.

PRO TIP

Build a single “Requirement 5 evidence pack” that you can update over time. Include your policy excerpts, diagrams of your malware defenses, and examples of alerts and incident tickets. That pack becomes reusable for audits, board briefings, and internal assurance.

From Check-Box Compliance To Continuous Defense

PCI DSS Requirement 5 is not just about installing antivirus software on a few servers. In PCI DSS v4.0, it has evolved into a comprehensive expectation that you:

• Govern malware defense with clear policies and accountable roles.
• Deploy modern anti-malware across all relevant systems, backed by risk-based exceptions.
• Keep those defenses updated, monitored, and resistant to tampering.
• Address phishing with automated, organization-wide controls that work hand-in-hand with awareness training.

If you design Requirement 5 as a living, continuously monitored control set rather than a static checklist, you end up with something more valuable than a compliant report: you gain a practical shield against the very threats that most often lead to payment data breaches.

Choose Copla for PCI DSS — and stop running PCI on spreadsheets

PCI DSS is the price of accepting cards. Copla makes hitting v4.0.1 — including the March 2025 changes — faster, cheaper, and radically less painful.

Why teams choose Copla:

• Shrink your CDE, shrink your PCI bill: Scope-minimization playbooks (tokenization, hosted payments, segmentation) cut effort and assessor questions.
• v4.0.1 done-for-you: Pre-mapped controls, policies, and workflows for all 12 requirements — including TRAs, MFA, and logging/retention.
• Evidence on autopilot: Automate access reviews, training, vendor AoCs, scan/pen-test tracking, and export-ready SAQ/RoC packages.

Typical outcome: 40–70% faster readiness and 40–70% lower internal PCI cost. PCI is non-negotiable. Doing it the hard way is.