Marcus Webb had been Director of IT Security at Coral Bay Hospitality Group for eleven months when the call came in at 4:47 a.m. A property manager at the group's flagship resort in Naples, Florida, was staring at a point-of-sale terminal that had just printed forty identical receipts and then gone black. By the time Marcus got a laptop open, three more properties were reporting the same symptom. What started as a single infected back-office workstation — plugged in by a vendor technician who'd used the same USB drive at two other hotel chains that week — had moved laterally across a flat network segment into the payment switch that routed card transactions for all 40 Coral Bay properties.
The forensic firm Coral Bay's cyber insurer sent in took nine days to fully eradicate the infection and confirm the cardholder data environment was clean. The final tally: $410,000 in forensic and remediation fees, $290,000 in card brand assessments and reissuance costs passed through by the acquirer, $180,000 in PCI DSS-mandated incident response and re-assessment work, and an estimated $1.4 million in lost bookings during the eight days three properties had to run card-present transactions manually on paper slips. Total exposure: north of $2.3 million, against an anti-malware program that, on paper, looked compliant — Coral Bay had antivirus software installed on its Windows servers. What it didn't have was a documented process for evaluating which systems needed protection, a way to stop unscanned removable media from reaching the CDE, or any anti-phishing controls covering the vendor tech whose credentials had been harvested three weeks earlier through a spoofed IT-helpdesk email.
Requirement 5 of PCI DSS is the shortest of the twelve requirements to summarize and one of the easiest to under-scope. "Have antivirus" is not the control. The control is a documented, evidence-backed program that decides which systems are at risk, deploys and keeps current the right class of tooling on those systems, scans and monitors continuously, evaluates the systems you've decided don't need protection, defends your people against the phishing emails that deliver most of today's malware, and locks down the removable media pathway that took down Coral Bay. This article walks through every sub-requirement of Requirement 5 as it stands in PCI DSS v4.0.1, the evidence a QSA will pull to test each one, and where EDR and behavioral detection tools fit alongside — or instead of — traditional signature-based antivirus.
Who This Is For
This is written for the people who own Requirement 5 in practice: IT security managers, systems administrators, and compliance leads at merchants and service providers preparing for a PCI DSS assessment, plus the QSAs and ISAs who test the control. You should walk away knowing exactly which system components need anti-malware coverage and which can be documented as exempt, how "current, running, and generating logs" gets tested in an assessment, what qualifies as an anti-phishing mechanism under 5.4.1, and how to build the removable-media and behavioral-detection evidence trail before an assessor asks for it. We assume you already understand your cardholder data environment scope; if you don't, start with mapping your cardholder data environment (CDE) before tackling Requirement 5 controls in isolation.
Why Requirement 5 Still Matters in a Post-Signature World
A common objection I hear from technical teams: "Antivirus is dead, EDR caught this already, why does PCI DSS still make us talk about 1990s virus scanners?" It's a fair challenge, and PCI DSS v4.0 answered it directly — Requirement 5 was rewritten specifically to stop being an antivirus-only requirement and become a malicious-software requirement that explicitly recognizes behavioral analysis, machine-learning detection, and EDR/XDR platforms as valid mechanisms. The name in the official standard is "Protect All Systems and Networks from Malicious Software," not "Install Antivirus." That distinction matters for how you build evidence.
Malware remains one of the most common paths into a cardholder data environment because it's cheap for attackers to deploy and highly effective against unpatched, unsegmented, or unmonitored systems. Ransomware in particular has evolved from an availability problem into a data-theft problem — modern ransomware crews exfiltrate cardholder data before encrypting systems, turning a business-continuity incident into a card-brand-reportable breach. Point-of-sale RAM-scraping malware, credential-harvesting trojans delivered by phishing, and malicious macros in vendor-sent documents are still the most common malware families QSAs see cited in breach forensics involving merchants.
Table 1: Malware Categories Most Relevant to a Cardholder Data Environment
Malware Category | How It Reaches the CDE | Primary Impact on Cardholder Data | Requirement 5 Control That Addresses It |
|---|---|---|---|
POS/RAM-scraping malware | Compromised remote access, phishing, weak vendor credentials | Captures unencrypted PAN/track data from memory | 5.2 deployment on POS/payment systems, 5.3.2 real-time scanning |
Ransomware (double-extortion) | Phishing attachment, exposed RDP, exploited vulnerability | Encrypts + exfiltrates CHD before demanding payment | 5.2 + 5.3.2 behavioral detection, 5.4.1 anti-phishing |
Banking/credential trojans | Phishing links, malvertising, drive-by downloads | Harvests admin credentials used to pivot into CDE | 5.4.1 anti-phishing, 5.3.1 currency |
Macro-based document malware | Email attachments (invoices, HR forms) impersonating vendors | Drops secondary payload, establishes persistence | 5.4.1 anti-phishing, 5.3.2 scanning |
Removable-media worms | USB drives used by vendors, contractors, or staff | Lateral movement across flat/segmented networks | 5.3.3 removable media scanning |
Fileless/living-off-the-land malware | Exploited vulnerability, malicious script execution | Evades signature AV, uses legitimate OS tools | 5.2.2/5.3.2 behavioral analysis (EDR-class tooling) |
"The mistake I see most often isn't a missing antivirus icon in the system tray — it's a program built entirely around Windows servers while the payment switch, the jump box, and half the POS estate never got evaluated at all. Requirement 5.2.3 exists precisely because assessors got tired of hearing 'that system doesn't get viruses' with nothing behind it." — Dana Ruiz, QSA, Palisade Assurance Partners
Requirement 5 at a Glance: The Four Sub-Requirements
PCI DSS v4.0.1 organizes Requirement 5 into four numbered groups of controls, moving from governance (5.1) through deployment (5.2) and operational maintenance (5.3) to the newer people-focused control (5.4). Table 2 maps each to its control intent and the primary evidence a QSA collects.
Table 2: PCI DSS Requirement 5 Sub-Areas — Control Intent and Assessor Evidence
Sub-Requirement | Control Intent | Primary Evidence Reviewed |
|---|---|---|
5.1.1 | Documented policies/procedures for protecting systems from malware | Anti-malware policy document, review/approval history |
5.1.2 | Roles and responsibilities for anti-malware activities are documented and assigned | RACI or org chart mapping, job descriptions, ticketing ownership |
5.2.1 | Anti-malware solution(s) deployed on all system components at risk | Asset inventory cross-referenced to agent deployment reports |
5.2.2 | Solution detects, removes/blocks/contains known malware; scans or behavioral analysis | Vendor product documentation, detection engine configuration |
5.2.3 | Periodic evaluation of systems deemed not at risk, with a documented list | Documented exception list, evaluation methodology, sign-off records |
5.3.1 | Anti-malware kept current via automatic updates | Console screenshots, update logs, definition/engine version reports |
5.3.2 | Periodic/active scans and/or continuous behavioral analysis | Scan schedules, scan result logs, EDR detection telemetry |
5.3.3 | Removable media scanned automatically on connection, or behavioral analysis performed | Media control policy, agent configuration for USB/media triggers |
5.3.4 | Audit logs for anti-malware enabled and retained per Requirement 10 | Log retention configuration, SIEM ingestion confirmation |
5.3.5 | Anti-malware cannot be disabled/altered without documented, time-limited management authorization | Change tickets showing authorized exceptions, tamper-protection settings |
5.4.1 | Process to detect and protect personnel against phishing attacks | Anti-phishing tooling config, simulated phishing results, training records |
That's eleven discrete testable controls behind what most people shorthand as "have antivirus." Each one generates its own evidence trail, and a QSA testing Requirement 5 during a Report on Compliance will typically want to see all eleven independently, not infer 5.3 from a screenshot of 5.2.
5.2: Deploying Anti-Malware on Every System Component at Risk
Requirement 5.2.1 sets the default: anti-malware goes on all system components, full stop, unless you've formally documented and evaluated an exception under 5.2.3. That default-deploy posture is deliberate. PCI DSS doesn't want organizations quietly deciding a system is "probably fine" without a paper trail — the exception process itself is a control.
In practice, most in-scope environments break down into three buckets: systems that unambiguously need anti-malware (Windows and most Linux servers and workstations touching the CDE), systems that traditionally sat in a gray area (certain mainframes, embedded POS terminals, hardened appliances), and systems increasingly reclassified since v4.0 as still needing protection because attacker tooling has caught up with them.
Table 3: System Types — Commonly at Risk vs. Requiring Periodic Evaluation
System Type | Typical Risk Posture | Requirement 5 Treatment |
|---|---|---|
Windows servers/workstations in the CDE | Commonly targeted; broad malware ecosystem | 5.2.1 deployment mandatory, no exception path |
Linux servers processing/storing CHD | Increasingly targeted (ransomware, cryptominers, fileless attacks) | 5.2.1 deployment expected; document rationale if excluded |
POS/POI terminals | Historically targeted via RAM-scraping malware | 5.2.1 deployment or vendor-managed equivalent control |
Payment switches/middleware servers | High-value pivot point (see Coral Bay case) | 5.2.1 deployment mandatory; behavioral monitoring recommended |
Mainframes (e.g., IBM Z/OS) | Historically low malware prevalence | Eligible for 5.2.3 evaluation; document evidence supporting exclusion |
Hardened network appliances (firewalls, HSMs) | Vendor-controlled firmware, limited attack surface | Eligible for 5.2.3 evaluation; confirm vendor patch/monitoring controls |
Cloud-native containers/serverless functions | Ephemeral, image-based; traditional AV agents often impractical | Behavioral/runtime protection or image-scanning as a compensating control |
The container and serverless row is worth dwelling on. A growing share of PCI DSS scope now includes containerized payment services where installing a traditional resident AV agent inside every ephemeral container is impractical or architecturally impossible. Assessors increasingly accept image scanning at build time, runtime behavioral monitoring, and host-level EDR on the underlying nodes as satisfying the intent of 5.2, provided the approach is documented and — where it departs meaningfully from the defined approach — supported by a formal customized approach or documented rationale tied to your targeted risk assessment.
5.2.2: What the Anti-Malware Solution Must Actually Do
Deploying a product isn't enough; Requirement 5.2.2 specifies functional capability. The solution must be able to detect all known types of malware, must remove, block, or contain detected malware, and must provide either periodic scanning, continuous behavioral analysis, or both. This is where the requirement's rewrite in v4.0 opened the door for EDR and next-generation endpoint protection platforms to satisfy Requirement 5 outright, rather than being treated as a bolt-on to a separate signature-based product.
Anti-Malware vs. EDR: What Satisfies Requirement 5 in 2026
By 2026, the overwhelming majority of QSAs I work alongside expect to see endpoint detection and response (EDR) or a comparable next-generation platform as the primary Requirement 5 control on servers and workstations, with legacy signature-based antivirus increasingly relegated to a supporting layer or phased out entirely. PCI DSS doesn't mandate EDR by name, but it does mandate the outcomes EDR is built to deliver: behavioral detection of malware that has no known signature, automated containment, and detailed forensic telemetry.
Table 4: Traditional Anti-Malware vs. EDR/XDR Against Requirement 5 Controls
Requirement 5 Control | Traditional Signature-Based AV | EDR / Behavioral Platform | XDR (Extended) |
|---|---|---|---|
5.2.2 detect known malware | Strong (signature matching) | Strong (signature + behavioral) | Strong, correlated across layers |
5.2.2 remove/block/contain | Quarantine, delete | Isolate host, kill process, rollback | Coordinated containment across endpoint/network/identity |
5.2.3 evolving threat coverage | Weak — dependent on definition updates | Strong — behavioral/ML models generalize to novel variants | Strongest — correlates weak signals across telemetry sources |
5.3.1 currency | Definition file updates (hours–daily) | Continuous cloud-delivered model updates | Continuous, cross-product |
5.3.2 scanning/behavioral analysis | Scheduled/on-access scans | Continuous behavioral analysis (native) | Continuous, plus network/identity correlation |
5.3.4 audit logging | Basic detection logs | Rich forensic telemetry (process trees, network connections) | Centralized, correlated event logs |
Fileless/living-off-the-land detection | Generally poor | Good to strong | Strong |
Typical cost profile | Lower per-endpoint licensing | Moderate-to-higher licensing + tuning effort | Highest — platform + integration cost |
Extended detection and response (XDR) extends this further by correlating endpoint telemetry with network, identity, and cloud signals — useful for larger service providers with complex CDEs, but not a strict PCI DSS requirement for smaller merchants whose scope is a handful of POS terminals and a back-office server. The right-sizing conversation matters: a Level 4 merchant running three registers doesn't need an XDR platform to satisfy Requirement 5; a Level 1 service provider running thousands of endpoints across a multi-tenant CDE almost certainly benefits from one operationally, even if the minimum compliance bar is lower.
"We migrated from a legacy signature AV product to an EDR platform two years before it was fashionable, mostly because our SOC was drowning in alerts nobody could act on. What convinced our QSA it satisfied 5.2.2 wasn't the marketing deck — it was that we could show behavioral detection catching a credential-stealing variant that had zero signature coverage anywhere, three days before the vendor published one." — Priya Nandakumar, Director of Threat Intelligence, Vantage Payments
Keeping Anti-Malware Current, Running, and Logging (5.3.1, 5.3.4, 5.3.5)
Requirement 5.3 is where compliance programs quietly rot. A product gets deployed during the initial assessment cycle, passes its first ROC, and then drifts: agents stop checking in, definition updates lag, a well-meaning administrator disables real-time protection to troubleshoot a performance issue and forgets to re-enable it. Three controls specifically target that drift.
5.3.1 requires automatic updates — not "someone checks monthly," but a configured mechanism that pulls current definitions, behavioral models, or engine updates without manual intervention. 5.3.4 requires that anti-malware audit logs are enabled and retained consistent with Requirement 10's logging and retention rules (generally 12 months, with 3 months immediately available). 5.3.5 is the tamper-resistance control: end users cannot disable or alter anti-malware protections unless management has explicitly authorized a specific, time-limited, documented exception.
Table 5: Configuration Parameters QSAs Check for 5.3 Compliance
Parameter | Compliant Configuration | Common Failure Pattern |
|---|---|---|
Update mechanism | Automatic, cloud-delivered or centrally pushed | Manual updates, or scheduled but frequently skipped |
Update frequency | Continuous or at minimum daily | Weekly or "as available," creating exposure windows |
Real-time/on-access protection | Enabled by default across all deployed agents | Disabled fleet-wide for performance, never re-enabled |
Tamper protection | Enabled; local admin cannot disable via console | Local admin rights allow silent disablement |
Exception process (5.3.5) | Documented ticket, named approver, defined expiry, auto re-enable | Verbal approval, no expiry, agent stays off indefinitely |
Log forwarding | Anti-malware events forwarded to centralized logging/SIEM | Logs retained only locally on endpoint, no central visibility |
Log retention | Minimum 12 months, 3 months immediately accessible | Default 30–90 day local retention, no archive |
Alerting on failure | Automated alert when agent stops reporting/checking in | No monitoring for "silent" agent failure |
That last row — alerting on agent failure — is the single most common gap I flag in Requirement 5 gap assessments. Anti-malware software failing loudly (a crashed process, a visible error) is rare; it fails quietly, and a quiet failure on a payment server can persist for months unless something is actively watching for missing heartbeats. Build that monitoring into your SIEM or endpoint management console dashboard, not as an afterthought.
Scanning: Periodic, Active, and Behavioral (5.3.2)
Requirement 5.3.2 gives you three compliant paths, and understanding which one(s) your organization is actually running matters for evidence collection: periodic scans, active/real-time scanning, or continuous behavioral analysis. Most modern deployments run a blend — real-time protection catching execution-time threats, supplemented by scheduled full scans that catch dormant or previously-undetected malware sitting in files that haven't been executed since the last engine update.
Table 6: Scan Types, Frequency, and Evidence
Scan Type | What It Catches | Recommended Frequency | Evidence to Retain |
|---|---|---|---|
Real-time/on-access scanning | Malware at the point of execution or file access | Continuous (always-on) | Configuration export confirming enabled state fleet-wide |
Scheduled full scans | Dormant malware in files not recently accessed/executed | Weekly minimum on CDE systems | Scan completion logs with timestamp and result summary |
Continuous behavioral analysis (EDR) | Fileless attacks, novel variants, anomalous process behavior | Continuous | Detection/alert telemetry, tuning change history |
Removable media scan-on-connect | Malware introduced via USB/external media | Triggered automatically on connection | Agent event logs showing scan-on-mount events |
Vulnerability-triggered rescan | Malware exploiting a newly disclosed vulnerability | Ad hoc, tied to threat intel/patch cycles | Rescan tickets linked to CVE or advisory reference |
A note on scan performance complaints: I've sat through more than one internal argument between IT operations and security teams over full scans degrading batch-processing windows on payment servers. The fix is rarely "scan less" — it's scheduling full scans during documented low-traffic windows and leaning more heavily on real-time and behavioral protection for continuous coverage, which is exactly the flexibility 5.3.2's "and/or" language was designed to permit.
5.2.3: The Process for Evaluating Systems Not Commonly Targeted by Malware
This is the sub-requirement Coral Bay skipped, and it's the one most gap assessments find undocumented even at organizations with strong anti-malware tooling everywhere else. If you're going to leave any system component without a deployed anti-malware agent, PCI DSS requires you to prove you made that decision deliberately, on a recurring basis, using current threat intelligence — not that you never thought about it.
Table 7: Building a Compliant 5.2.3 Evaluation Process
Step | Activity | Output |
|---|---|---|
1. Inventory | Identify every system component excluded from anti-malware deployment | Documented exception list tied to the asset inventory |
2. Justify | Document the technical/architectural rationale for exclusion (e.g., closed OS, vendor-managed appliance, no general-purpose execution capability) | Written justification per system or system class |
3. Monitor threat intel | Track vendor advisories, CERT bulletins, and threat feeds for malware targeting the excluded platform | Subscription/log of reviewed sources and dates |
4. Periodic re-evaluation | Reassess each excluded system at a defined interval (commonly aligned to your annual risk assessment cycle) | Dated evaluation record with outcome (remains excluded / requires remediation) |
5. Escalation trigger | Define what evidence of emerging malware targeting the platform triggers immediate re-evaluation | Documented escalation criteria and named owner |
6. Sign-off | Management approval of the exclusion decision and evaluation outcome | Signed/dated approval record |
The evaluation doesn't need to be exotic. For a mainframe processing authorization files, a credible 5.2.3 record might note the platform's closed execution model, cite the absence of mainstream malware families targeting that specific OS/version combination, reference the vendor's security bulletin history for the review period, and get signed off annually by the systems owner and CISO. What breaks assessments isn't the substance of the judgment — it's that nobody wrote it down, dated it, or repeated it.
"I ask for the 5.2.3 list before I ask for anything else on Requirement 5, because it tells me more about the maturity of the program than the antivirus console does. A team that can hand me a dated, re-evaluated exclusion list with real rationale has usually done the rest of the requirement properly too." — Dana Ruiz, QSA, Palisade Assurance Partners
5.4.1: Anti-Phishing Mechanisms to Protect Personnel
Requirement 5.4.1 is the newest addition in v4.0 and reflects where the actual initial-access statistics have moved. Most malware doesn't break into a network through an unpatched server anymore — it walks in through a person clicking a link or opening an attachment. PCI DSS now explicitly requires a process to detect and protect personnel against phishing attacks, and it deliberately doesn't prescribe a single tool, because effective anti-phishing programs are layered.
Phishing sits at the intersection of technical control and human behavior, which is why 5.4.1 evidence spans both. A QSA testing this control wants to see the technical filtering layer (what stops the email before a human sees it), the detection layer (what happens when something gets through), and the human layer (social engineering awareness and reporting behavior).
Table 8: Anti-Phishing Defenses That Satisfy 5.4.1
Defense Layer | Mechanism | Evidence for Assessors |
|---|---|---|
Email gateway filtering | Reputation/sandboxing, attachment detonation, URL rewriting | Gateway configuration, quarantine/block statistics |
Domain authentication | SPF, DKIM, DMARC enforced on inbound/outbound mail | DNS records, DMARC reporting configuration |
Link protection | Time-of-click URL rewriting/analysis | Vendor console logs showing blocked malicious clicks |
Browser/endpoint isolation | Blocks or isolates known-bad domains at the browser | Policy configuration export |
Simulated phishing exercises | Periodic internal phishing simulations with tracked click/report rates | Campaign schedule, results, trend data |
Security awareness training | Role-based training on recognizing phishing/social engineering | Training completion records, curriculum content |
User reporting mechanism | One-click "report phishing" button with SOC triage workflow | Reporting tool config, triage ticket volume/history |
MFA on email/critical accounts | Reduces impact of credential harvesting even if phishing succeeds | MFA enforcement policy and coverage report |
The security awareness training row is where the Coral Bay incident's second root cause lived — a vendor technician whose credentials were harvested by a spoofed IT-helpdesk email had never gone through phishing simulation training, because "vendor personnel" fell outside the scope of Coral Bay's annual security awareness program. If a person has credentials that can touch anything in or adjacent to your CDE — employee, contractor, or vendor technician — they need to be inside your 5.4.1 program, not exempted from it because of their employment classification.
"Anti-phishing under 5.4.1 isn't a training slide deck you show once a year and call it done. We run monthly simulations, we publish click-rate trends by department to the leadership team, and repeat clickers get one-on-one coaching, not a memo. That visibility is what actually moves the number." — Sarah Lindqvist, Incident Response Lead, ClearArc Security
Removable Electronic Media Controls (5.3.3)
Requirement 5.3.3 requires anti-malware solutions to automatically scan removable electronic media — USB drives, external hard disks, memory cards — when connected, inserted, or logically mounted, unless continuous behavioral analysis is performing that function dynamically. This is the exact control gap that let a vendor's infected USB drive walk malware into Coral Bay's payment switch.
Removable media remains a persistent blind spot because it bypasses network-layer defenses entirely — firewalls, network segmentation, and email filtering do nothing against a physical device plugged directly into an endpoint. Organizations that treat Requirement 5.3.3 as "the antivirus scans it eventually" rather than "the connection triggers an immediate, logged scan" tend to fail this control during testing.
Table 9: Removable Media Control Options and Trade-offs
Control Approach | How It Works | Strength | Common Limitation |
|---|---|---|---|
Scan-on-connect (agent-based) | Endpoint agent automatically scans media on mount | Direct compliance with 5.3.3 | Requires agent on every endpoint with a USB port |
Device control / port lockdown | Blocks unauthorized USB device classes entirely | Eliminates the vector for non-approved devices | Can disrupt legitimate vendor/operational workflows if not planned |
Media whitelisting | Only pre-approved, organization-issued media permitted | Strong control over provenance | Requires asset tracking and issuance process |
Centralized transfer stations | Dedicated, isolated system for scanning media before use in CDE | Keeps scanning off production endpoints | Adds process friction; requires staff discipline |
Behavioral/dynamic analysis | EDR monitors process/file behavior post-connection regardless of scan | Satisfies 5.3.3's behavioral alternative | Doesn't prevent initial file execution if not paired with blocking |
Policy prohibition | Removable media banned outright in CDE-adjacent areas | Eliminates the vector entirely | Operationally impractical for many retail/hospitality environments |
For most merchant environments — retail, hospitality, restaurants — I recommend pairing device control (blocking unapproved USB device classes by default) with scan-on-connect for the narrow set of approved use cases, rather than relying on policy prohibition alone. Policies get violated by exactly the kind of well-intentioned vendor technician who took down Coral Bay; technical controls don't care about intentions.
Mobile device management (MDM) platforms are worth folding into this conversation too — for organizations issuing mobile devices or tablets that touch payment workflows (mobile POS, order-taking tablets), MDM policies can enforce the same device-control and media-restriction posture at the device level, extending Requirement 5.3.3's intent beyond traditional desktop/server endpoints.
Malware Defense Layers: A Visual Model
Requirement 5 doesn't operate in isolation — it's one layer in a defense-in-depth model that spans network controls (Requirement 1), secure configuration (Requirement 2), access control (Requirements 7–8), and monitoring (Requirement 10). The diagram below maps how a malware attempt gets challenged at each layer, and where Requirement 5's specific controls sit.
flowchart TD
A[Attack Vector: Phishing Email, Removable Media, Exploited Vulnerability] --> B{Perimeter / Email Gateway Filtering}
B -->|Blocked| Z[Threat Neutralized]
B -->|Delivered| C{Anti-Phishing Detection - 5.4.1}
C -->|User Reports / Link Blocked| Z
C -->|Clicked / Opened| D{Endpoint Anti-Malware - 5.2/5.3}
D -->|Signature Match| Z
D -->|Behavioral Detection - EDR| E{Automated Containment}
E --> Z
D -->|Undetected| F[Lateral Movement Attempt]
F --> G{Network Segmentation Blocks CDE Access}
G -->|Contained| H[SIEM Alert / Incident Response]
G -->|Reaches CDE| I[Cardholder Data Environment]
I --> J{Removable Media Scan-on-Connect - 5.3.3}
J --> H
H --> ZThat flow is the practical argument for why Requirement 5 can't be evaluated on its own merits during a maturity assessment. A strong anti-phishing program that funnels into weak endpoint detection still lets malware through; strong endpoint detection sitting on a flat, unsegmented network still lets one infected workstation become a payment-switch incident, exactly as it did at Coral Bay.
Case Study: Trellis Kitchen Co. — Removable Media Discipline After a Near-Miss
Trellis Kitchen Co., a 34-location fast-casual chain, discovered a USB drive plugged into a back-office manager's workstation at one location was carrying a variant of a known credential-stealing trojan — caught only because a scheduled full scan flagged it eleven days after the drive was first connected, since the store's endpoint agent had real-time protection disabled during a POS software rollout and nobody had re-enabled it.
Security engineer Ben Okafor used the incident to rebuild the company's Requirement 5.3.3 and 5.3.5 controls from scratch: device control software now blocks unauthorized USB device classes by default across all 34 locations, with a documented exception process requiring regional IT manager approval and a 72-hour auto-expiry for any temporary media access; the endpoint agent's tamper-protection setting was locked at the platform level so store-level staff and even most IT technicians can no longer disable real-time scanning without a change ticket; and a weekly automated report now flags any endpoint with real-time protection disabled for more than four hours, with an alert routed straight to the security team rather than sitting in a dashboard nobody checks.
"The scariest part wasn't the malware — it was that our agent had been silently blind for eleven days and the only reason we caught it was a scheduled scan finally ran. Now if protection goes dark anywhere in our fleet, we know within hours, not days." — Ben Okafor, Security Engineer, Trellis Kitchen Co.
Eighteen months later, Trellis passed its next PCI DSS assessment with zero Requirement 5 findings, and the QSA specifically cited the auto-expiring exception process as evidence of a mature 5.3.5 control rather than a policy that existed only on paper.
Case Study: Ferro Payments — EDR Deployment Cuts Dwell Time
Ferro Payments, a mid-sized payment processor supporting several thousand merchant endpoints indirectly through managed terminal deployments, ran legacy signature-based antivirus across its core processing infrastructure for years, passing every PCI DSS assessment on paper while its security operations team quietly worried about fileless attack techniques the tooling had no visibility into.
VP of Risk Wayne Kessler sponsored a phased EDR migration across the processing environment, prioritizing internet-facing systems and the payment switch tier first. During the transition period, the EDR platform's behavioral analysis flagged a credential-harvesting process on an administrative jump box that the legacy AV product — still running in parallel during the cutover — never alerted on, because no signature existed for the specific loader variant in use. Mean time to detect suspicious lateral movement attempts across the processing environment dropped from an estimated several days (based on prior incident timelines) to under four hours after full EDR rollout, driven largely by the automated containment capability isolating affected hosts the moment anomalous behavior crossed a defined threshold.
"Signature AV told us what already had a name. EDR told us what was actually happening on the box right now. For a processor, that difference is the whole ballgame — attackers targeting payment infrastructure aren't running off-the-shelf malware with a known hash." — Wayne Kessler, VP Risk, Ferro Payments
Ferro's next Report on Compliance documented the EDR platform as satisfying 5.2.2 and 5.3.2 through continuous behavioral analysis, with the legacy AV product formally decommissioned rather than run redundantly — simplifying both the environment and the audit evidence trail.
What Assessors Actually Test for Requirement 5
Understanding what a Qualified Security Assessor (QSA) does during testing helps you build the right evidence before the assessment window opens, rather than scrambling to produce it on request. Requirement 5 testing procedures generally combine document review, configuration inspection, and personnel interviews.
Table 10: Requirement 5 — Assessor Testing Methods by Control
Control | Testing Method | What "Pass" Looks Like |
|---|---|---|
5.1.1 / 5.1.2 | Document review + interview | Current, approved policy; named roles matched to actual staff in interviews |
5.2.1 | Configuration inspection + asset inventory cross-check | Agent deployment matches inventory; gaps are documented 5.2.3 exceptions |
5.2.2 | Vendor documentation + console review | Product capability matches detection/removal/scanning requirements |
5.2.3 | Document review + interview | Dated, re-evaluated exclusion list with rationale and named approver |
5.3.1 | Configuration inspection | Automatic update mechanism confirmed active, current version deployed |
5.3.2 | Configuration inspection + log review | Scan schedules and/or behavioral analysis confirmed running and logging |
5.3.3 | Configuration inspection + demonstration | Scan-on-connect or behavioral trigger observed/confirmed for removable media |
5.3.4 | Log review | Anti-malware logs present, forwarded, retained per Requirement 10 |
5.3.5 | Configuration inspection + change ticket sampling | Tamper protection enabled; any exceptions have documented, expired authorization |
5.4.1 | Configuration inspection + document review + interview | Technical filtering + simulation/training evidence + reporting workflow observed |
A pattern worth internalizing: nearly every control pairs a technical configuration check with a document or interview component. Teams that treat Requirement 5 as purely a technology procurement exercise — buy the product, install the agent, done — consistently underperform in assessments relative to teams that also build the policy documentation, the exception evaluation process, and the training/interview readiness alongside the tooling.
Common Requirement 5 Failures and How to Prevent Them
Across gap assessments and post-incident reviews, the same handful of failure patterns recur. Table 11 catalogs them alongside the fix that actually resolves the root cause, not just the symptom.
Table 11: Common Requirement 5 Failures
Failure Pattern | Why It Happens | Prevention |
|---|---|---|
No documented 5.2.3 exclusion list | "We just know which systems don't need it" — undocumented tribal knowledge | Formalize an annual exclusion review tied to the risk assessment cycle |
Real-time protection silently disabled | Disabled for troubleshooting/performance, never re-enabled, no alerting | Lock tamper protection; alert on any endpoint reporting protection disabled |
Anti-malware logs not forwarded centrally | Logging treated as a local endpoint feature, not integrated with Requirement 10 | Route anti-malware events into the central SIEM/log retention platform |
Removable media scanned "eventually" not on connect | Scan-on-connect not explicitly configured; relying on scheduled scans only | Explicitly enable and test scan-on-mount/connect triggers |
Vendor/contractor personnel excluded from anti-phishing program | Scope defined by employment status, not by system access | Include anyone with credentials touching the CDE or adjacent systems |
EDR deployed but treated as "extra," legacy AV still the compliance record of truth | Compliance documentation not updated when tooling changed | Formally document which tool satisfies which sub-control after migration |
No monitoring for agent check-in failure | Assumed "installed" equals "operating" indefinitely | Build automated alerting for missed heartbeats/check-ins |
Anti-malware coverage stops at server tier, ignores endpoints/POS | Scoping exercise focused on "servers" not full system component inventory | Cross-reference deployment against the complete CDE asset inventory |
Phishing simulations run but results never acted on | Metrics collected, no coaching/escalation workflow attached | Pair simulation data with mandatory coaching for repeat clickers |
Anti-malware policy exists but hasn't been reviewed since initial certification | Annual review cycle not enforced | Tie policy review to the annual PCI DSS assessment calendar |
"Every one of these failure patterns shows up in breach forensics reports more often than exotic zero-days do. Attackers don't need a novel exploit when a disabled real-time scanner or an unmonitored USB port will do the job for free." — Tomás Alvarez, CISO, Coral Bay Hospitality Group
Cost and Timeline: Building a Requirement 5 Program
Budgeting for Requirement 5 varies enormously by environment size and whether you're migrating from legacy AV to EDR or building from scratch. Table 12 gives illustrative ranges based on the deployment patterns I see most often; treat these as planning inputs, not vendor quotes.
Table 12: Illustrative Requirement 5 Program Costs and Timeline
Activity | Small Merchant (10–50 endpoints) | Mid-Size Merchant/Service Provider (500–2,000 endpoints) | Large Service Provider (5,000+ endpoints) |
|---|---|---|---|
Anti-malware/EDR licensing (annual) | $500–$3,000 | $40,000–$180,000 | $400,000+ |
Initial deployment/tuning effort | 1–2 weeks | 6–10 weeks | 4–6 months (phased) |
Anti-phishing tooling + training platform | $300–$1,500/year | $15,000–$60,000/year | $150,000+/year |
Policy/documentation build-out (5.1, 5.2.3) | 8–16 consulting/internal hours | 40–80 hours | 150–300 hours |
Removable media control implementation | 1–2 weeks | 4–8 weeks | 3–5 months |
Ongoing monitoring/tuning (annual) | Minimal, often bundled | 0.25–0.5 FTE | 2–4 FTE (SOC-integrated) |
Smaller merchants running eligible self-assessment questionnaire (SAQ) types often find that consumer-grade or SMB-tier endpoint protection platforms with centralized cloud management satisfy Requirement 5 at a fraction of enterprise EDR cost, provided the platform still meets the behavioral analysis and logging requirements — the control intent, not the price tag, is what an assessor evaluates.
Roles and Responsibilities
Requirement 5.1.2 explicitly requires documented roles and responsibilities, and in practice Requirement 5 touches more teams than any single owner can manage alone: IT operations deploys and maintains agents, the security team owns policy and exception evaluation, the security operations center (or MSSP) monitors alerts and behavioral detections, and HR/people teams often own the training-delivery mechanics of the anti-phishing program.
Table 13: RACI for Requirement 5 Control Ownership
Activity | IT Operations | Security/GRC Team | SOC / Monitoring | HR / L&D |
|---|---|---|---|---|
Anti-malware deployment (5.2.1) | Responsible | Accountable | Consulted | Informed |
5.2.3 exclusion evaluation | Consulted | Responsible/Accountable | Consulted | — |
Currency/update management (5.3.1) | Responsible | Accountable | Consulted | — |
Scanning configuration (5.3.2) | Responsible | Accountable | Informed | — |
Removable media controls (5.3.3) | Responsible | Accountable | Informed | — |
Log retention/forwarding (5.3.4) | Consulted | Accountable | Responsible | — |
Tamper-protection exceptions (5.3.5) | Consulted | Responsible/Accountable | Informed | — |
Anti-phishing tooling (5.4.1 technical) | Responsible | Accountable | Consulted | — |
Phishing simulations/training (5.4.1 human) | Informed | Accountable | Consulted | Responsible |
Ambiguous ownership is its own failure mode — I've seen organizations where the security team assumed IT operations owned exclusion evaluation, IT operations assumed security owned it, and the 5.2.3 documentation simply never got written by anyone until a QSA asked for it during fieldwork.
Integration with Other PCI DSS Requirements
Requirement 5 doesn't function as an island. It draws directly on the logging and retention rules of Requirement 10, depends on the network segmentation established under Requirement 1 to limit how far a missed detection can travel, and increasingly overlaps with Requirement 6's expectations around secure software development where malware delivery exploits application-layer weaknesses. If your organization is also working through PCI DSS Requirement 4: Encrypted Data Transmission Over Open Networks, note that encryption in transit does nothing to stop malware already resident on an endpoint — the two requirements are complementary, not substitutes.
Table 14: How Requirement 5 Connects to Adjacent PCI DSS Requirements
Adjacent Requirement | Connection Point |
|---|---|
Requirement 1 (network security controls) | Segmentation limits lateral movement if endpoint detection misses an initial infection |
Requirement 2 (secure configurations) | Hardened baselines reduce the attack surface malware can exploit locally |
Requirement 6 (secure software) | Vulnerable applications are a common malware delivery/execution vector |
Requirement 7/8 (access control, authentication) | Compromised credentials from malware/phishing require strong MFA and least-privilege to limit blast radius |
Requirement 10 (logging and monitoring) | Anti-malware audit logs feed the centralized logging program 5.3.4 requires |
Requirement 11 (security testing) | Penetration testing and vulnerability scanning validate that anti-malware and segmentation controls hold under real attack conditions |
Requirement 12 (security policy) | The overarching security awareness and incident response programs anti-phishing and malware response depend on |
Requirement 6, which governs secure software development and vulnerability remediation, hasn't yet been published as a standalone PentesterWorld article at the time of writing — treat the reference above as directional context for how the two requirements interlock rather than a live link.
Merchant and Service Provider Applicability
Requirement 5 applies broadly across nearly every merchant and service provider validation path, though the specific evidentiary burden scales with assessment type. Table 15 maps how Requirement 5 typically surfaces across common validation routes.
Table 15: Requirement 5 Across Validation Types
Validation Path | Requirement 5 Relevance | Typical Evidence Burden |
|---|---|---|
SAQ A (fully outsourced e-commerce) | Minimal direct scope; merchant systems largely outside CDE | Confirm no CHD-touching systems require in-scope anti-malware |
SAQ B / B-IP (standalone terminals) | Applies to any connected systems, terminal management workstations | Moderate — device/terminal-adjacent systems in scope |
SAQ C (payment application connected to internet) | Full applicability to POS/payment application environment | Moderate-high — full anti-malware program on in-scope systems |
SAQ D (merchant, complex environments) | Full applicability across CDE | High — all eleven Requirement 5 controls independently evidenced |
SAQ D (service provider) | Full applicability, typically at greater scale | High — enterprise-grade tooling and process maturity expected |
Report on Compliance (Level 1) | Full applicability, QSA-tested control by control | Highest — formal testing procedures against every sub-requirement |
Even merchants on lighter-touch SAQs shouldn't assume Requirement 5 is irrelevant — any system that connects to, manages, or supports payment terminals typically falls in scope, and QSA-led assessments have increasingly scrutinized terminal-management workstations that merchants historically treated as out of scope.
Vendor and Tooling Selection Considerations
Choosing an anti-malware or EDR platform for a PCI DSS-scoped environment involves criteria beyond general detection efficacy scores from independent testing labs. Table 16 lists the questions worth asking during procurement specifically through a Requirement 5 compliance lens.
Table 16: Requirement 5-Specific Vendor Evaluation Criteria
Evaluation Criterion | Why It Matters for Requirement 5 |
|---|---|
Supports both scanning and behavioral analysis | Satisfies 5.2.2/5.3.2's "and/or" flexibility without needing a second product |
Tamper-protection enforceable centrally | Directly supports 5.3.5's anti-disablement requirement |
Automatic, cloud-delivered updates | Supports 5.3.1 currency without manual intervention |
Removable media scan-on-connect capability | Directly satisfies 5.3.3 |
Centralized logging with SIEM/export integration | Supports 5.3.4 log retention and Requirement 10 alignment |
Coverage for server, workstation, and container/cloud workloads | Avoids gaps at the edges of a mixed-architecture CDE |
Documented detection/removal capability for known malware families | Supports evidence for 5.2.2 |
Vendor SOC/threat intel feed transparency | Strengthens 5.2.3 evolving-threat evaluation process |
Role-based admin access with audit trail | Prevents unauthorized configuration changes to protection settings |
Reporting/dashboard exportable for assessor evidence | Reduces manual evidence-gathering burden during assessment prep |
Requirement 5 as a Business Differentiator, Not Just a Checkbox
It's tempting to treat Requirement 5 as the "easy" requirement — install a product, check a box, move on to harder controls like Requirement 3's cryptography rules or Requirement 6's software security lifecycle. The Coral Bay incident, and every gap assessment finding cataloged in Table 11, argues the opposite. Malware is still the delivery mechanism behind a large share of the card-data breaches that trigger card brand fines, forensic investigations, and the kind of reputational damage that costs far more than any compliance program line item.
Organizations that build Requirement 5 properly — full deployment mapped to a real asset inventory, documented and periodically re-evaluated exclusions, currency and tamper-protection enforced centrally, removable media locked down technically rather than by policy alone, and a genuinely layered anti-phishing program covering everyone with CDE-adjacent access — end up with something more valuable than a clean audit finding. They end up with an endpoint and email security program that materially reduces breach probability, shortens dwell time when something does get through, and gives the board and the acquiring bank a real answer to "how would we know" rather than a hopeful assumption.
That's the pitch worth making internally when Requirement 5 budget gets questioned: this isn't compliance theater bought to satisfy a QSA once a year. It's the layer that decided whether Coral Bay's vendor-USB incident stayed a contained, forty-receipt anomaly at one property or became a $2.3 million, eight-day, forty-property event. The tooling and process cost a fraction of the second outcome every single time.
If you're building or maturing your Requirement 5 program, PentesterWorld's PCI DSS 12-Requirements Checklist walks through evidence expectations across every requirement, and our PCI DSS Gap Analysis Tool can help you baseline where your anti-malware and anti-phishing controls stand today against the full v4.0.1 control set before your next assessment window opens. For teams still mapping the CDE these controls need to cover, the PCI DSS Scoping & CDE Worksheet is a practical starting point, and our PCI DSS Glossary is worth bookmarking for the terminology that comes up throughout an assessment. If your program is still developing from the ground up, our PCI DSS Policy Pack includes anti-malware and anti-phishing policy templates aligned to Requirement 5.1's documentation expectations.
Requirement 5 sits alongside the other eleven within the same PCI DSS Complete Guide: Payment Card Industry Data Security Standard — worth reviewing if you're building out your full compliance roadmap rather than tackling one requirement in isolation. It also pairs directly with PCI DSS Requirement 4: Encrypted Data Transmission Over Open Networks, since encrypting cardholder data in transit does nothing to stop malware already resident on an endpoint — the two controls solve different halves of the same threat model. And if your organization also holds SOC 2 or ISO 27001 obligations alongside PCI DSS, the malware-protection controls largely reinforce each other: see how the same control intent maps under SOC 2's malware protection and endpoint security criteria and ISO 27001 Control 8.7 on protection against malware if you're harmonizing a multi-framework control set rather than building Requirement 5 as a standalone silo.
Marcus Webb's team at Coral Bay rebuilt its anti-malware program from the ground up in the four months following the incident — full 5.2.3 documentation, tamper-locked EDR across every property, device control on every USB port, and a phishing simulation program covering vendor technicians alongside employees. Their next PCI DSS assessment closed with zero Requirement 5 findings. The $2.3 million lesson was expensive. It didn't need to be.