Anti-Malware Scanning

PCI DSS 4.0.1 Requirement 5.3.2 requires your anti-malware solution to run periodic scans and either real-time (active) scanning or continuous behavioral analysis across systems and processes in scope for cardholder data. To operationalize it, standardize scan modes, schedules, and coverage; continuously monitor health; and retain evidence that scanning is enabled, running, and reviewed. (PCI DSS v4.0.1 Requirement 5.3.2)

Key takeaways:

• You must have both periodic scanning and real-time/continuous detection in place, not just one. (PCI DSS v4.0.1 Requirement 5.3.2)
• Auditors will look for proof of coverage, currency, and operational monitoring, not screenshots taken once. (PCI DSS v4.0.1 Requirement 5.3.2)
• Exceptions (systems that “can’t run AV”) must be replaced with continuous behavioral analysis and documented compensating practices. (PCI DSS v4.0.1 Requirement 5.3.2)

“Anti-malware scanning requirement” sounds simple until you map it to a modern PCI environment: endpoints, servers, VDI, containers, cloud workloads, build agents, and third-party managed systems. PCI DSS 4.0.1 Requirement 5.3.2 is short, but it is operationally demanding because it expects scanning and detection to be continuous enough to matter, and consistent enough to prove.

Your goal as a Compliance Officer, CCO, or GRC lead is to convert this requirement into a repeatable control that your security team can run without heroic effort before every assessment. That means: define scope (which systems and processes are in, and why), define the scanning modes that satisfy the requirement, set standard configurations, and build a lightweight evidence stream that shows the control is working over time.

This page gives you requirement-level implementation guidance: what the text means, who it applies to, what to do step-by-step, what evidence to retain, how auditors typically challenge it, and the failure modes that cause findings.

Regulatory text

Requirement text (excerpt): “The anti-malware solution(s) performs periodic scans and active or real-time scans, or performs continuous behavioral analysis of systems or processes.” (PCI DSS v4.0.1 Requirement 5.3.2)

What the operator must do

You must implement an anti-malware capability that:

1. Runs periodic scans on in-scope systems/processes, and
2. Also provides real-time (active) scanning or continuous behavioral analysis to detect malicious activity as it happens. (PCI DSS v4.0.1 Requirement 5.3.2)

Operationally, assessors will expect you to prove the anti-malware control is (a) deployed broadly across scope, (b) configured to actually scan, (c) functioning and monitored, and (d) not silently failing on a subset of assets.

Plain-English interpretation (what this requirement really demands)

• “Periodic scans” means scheduled scanning occurs on a recurring basis, and you can show it ran. (PCI DSS v4.0.1 Requirement 5.3.2)
• “Active or real-time scans” means files/processes are scanned upon access or execution, or other real-time methods detect malware as it is introduced. (PCI DSS v4.0.1 Requirement 5.3.2)
• “Continuous behavioral analysis” is an alternative to real-time file scanning that focuses on behavior-based detection across systems/processes (common in EDR tools). (PCI DSS v4.0.1 Requirement 5.3.2)

A common practical reading: if a device “has AV” but real-time protection is disabled, you are exposed. Another: if you rely on EDR-only behavioral analytics, you still need periodic scans.

Who it applies to

Entity types

• Merchants
• Service providers
• Payment processors
  (PCI DSS v4.0.1 Requirement 5.3.2)

Operational context (where this shows up in real life)

Applies to systems and processes in scope for PCI DSS, which often includes:

• Workstations and laptops used by staff who administer or access cardholder data environments.
• Servers/workloads that store, process, or transmit cardholder data, or provide security services to those systems.
• Bastion hosts, jump boxes, and admin consoles.
• Systems managed by a third party where you still must ensure the control is in place (contractually and operationally).

If you have mixed ownership (IT-managed endpoints, cloud workloads owned by engineering, and third-party managed systems), you need a single control narrative with shared accountability.

What you actually need to do (step-by-step)

1) Define “in scope” targets for anti-malware coverage

Build or refresh an asset list for PCI scope and tag each asset with:

• Owner team
• Platform (Windows/macOS/Linux, server/endpoint, cloud/on-prem)
• Whether an agent is supported
• Primary anti-malware control (AV, EDR behavioral, or both)

Output: “PCI Anti-Malware Coverage Register” (even a spreadsheet is fine if maintained).

2) Standardize the approved anti-malware solutions and modes

For each platform, document:

• Real-time protection setting (enabled/required) or behavioral analysis setting (enabled/required)
• Periodic scan configuration (scheduled scan enabled, what it covers)
• Update mechanisms (signatures/content updates where applicable)

Keep this as a configuration standard that your endpoint/server teams can implement consistently.

3) Turn the standard into enforceable configuration

Practical mechanisms:

• Endpoint management policies (for workstations)
• Server configuration management (for servers)
• Golden images/templates (for VDI, cloud instances)
• “Must-have” onboarding checklist for any new in-scope system

Your target state is: new assets inherit the configuration by default, rather than being fixed later.

4) Implement continuous monitoring for control health

Assessors usually probe whether agents are:

• Installed but stale
• Disabled by users/admins
• Not reporting
• Failing scans

Set up a control health dashboard and an operational process:

• Triage non-reporting agents
• Investigate disabled real-time scanning
• Follow up on scan failures and malware detections
• Track to closure via tickets

5) Define exception handling that still satisfies the requirement

Some systems cannot run traditional AV (performance constraints, appliance-like systems, certain workloads). Requirement 5.3.2 allows continuous behavioral analysis as an alternative to real-time scans, but you still need periodic scanning. (PCI DSS v4.0.1 Requirement 5.3.2)

For each exception:

• Record the reason the standard agent/mode can’t run
• Record the alternative control (behavioral analysis tool, monitored service, etc.)
• Approve via a named risk owner
• Set a review cadence and an end date if it’s meant to be temporary

6) Make it auditable: bind scanning to evidence

Don’t rely on “we can show it in the console live.” Evidence should be reproducible after the fact.

Create an evidence package per assessment period that includes:

• Policy/config exports for scan schedules and real-time/behavioral settings
• Logs/reports showing periodic scans executed
• Health/compliance reports showing coverage across in-scope assets
• A sample of tickets/incidents showing monitoring and response

Where Daydream fits: Daydream can act as the control “binder,” mapping PCI scope to assets, collecting recurring evidence (configs, scan reports, health attestations), and routing exceptions for approval so you do not rebuild the same package for every audit cycle.

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Design evidence

• Anti-malware standard (what must be enabled: periodic scans + real-time or behavioral analysis) (PCI DSS v4.0.1 Requirement 5.3.2)
• Scope definition for which systems/processes must comply

Implementation evidence

• Agent deployment reports by asset group
• Configuration baselines (screenshots are weaker than exports/config reports)

Operational evidence

• Periodic scan execution logs/reports
• Alerts/events showing real-time scanning or behavioral detections are active
• Control health reports (non-reporting agents, disabled protections, outdated components)
• Tickets showing investigation/closure for key exceptions or failures

Governance evidence

• Exception register with approvals and reviews
• Third-party responsibility matrix (who operates anti-malware on managed systems)

Common exam/audit questions and hangups

Expect these questions, and prepare short, evidenced answers:

1. “Show me periodic scan results for the last assessment period.” Provide scan execution logs and a sample set tied to asset inventory.
2. “How do you know real-time scanning is enabled everywhere?” Show a configuration policy and a compliance/health report proving enforcement.
3. “What about Linux servers/containers/build agents?” Show platform-specific coverage and how you handle ephemeral assets (gold images, CI checks, runtime agents).
4. “Who reviews failures and how do you track closure?” Show ticket workflow and escalation path.
5. “What about third-party managed systems?” Show contractual/control expectations and monitoring/attestation approach.

Audit hangup: teams show the assessor a console view but cannot produce historical evidence of scans running. Solve that by scheduling recurring exports or reports and retaining them with change context.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Periodic scans exist, but real-time protection is off “to improve performance”

Fix: Make real-time scanning (or continuous behavioral analysis) a non-negotiable baseline; handle performance via exclusions governance and testing, not by disabling detection. (PCI DSS v4.0.1 Requirement 5.3.2)

Mistake 2: Coverage gaps due to ownership splits

Endpoints are covered; servers in a special network segment are not. Fix: Tie your PCI asset inventory to an automated compliance check that flags missing agents or missing reporting.

Mistake 3: “Set and forget” deployments

Agents drift, policies change, exclusions grow, and hosts stop reporting. Fix: Define a control health process with named owners and a ticketed remediation flow.

Mistake 4: Uncontrolled exclusions

Teams add broad path/process exclusions without review. Fix: Require documented justification, approval, and periodic review for exclusions. Keep an exclusions register.

Mistake 5: Third-party blind spots

A third party manages systems; you assume they run anti-malware. Fix: Put it in the contract/SOW and require evidence or attestation aligned to your requirement and assessment needs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program on anecdotal “fines.” Treat the risk plainly: ineffective anti-malware scanning increases the chance that malware persists in the environment long enough to access credentials, modify payment flows, or disrupt operations. For PCI, that translates into assessment findings, increased remediation burden, and potential downstream obligations to payment brands and acquiring banks depending on incident specifics.

Practical execution plan (30/60/90-day)

Use phases rather than date math. Your timing depends on asset count, tooling, and third-party dependencies.

First 30 days: establish control minimums and visibility

• Confirm the anti-malware tools in use and whether they support real-time scanning or behavioral analysis across your platforms. (PCI DSS v4.0.1 Requirement 5.3.2)
• Produce the PCI Anti-Malware Coverage Register (in-scope assets and current state).
• Define the baseline configurations: periodic scan enabled + real-time scanning or behavioral analysis enabled. (PCI DSS v4.0.1 Requirement 5.3.2)
• Turn on reporting exports you can retain (scan execution, health/compliance).

By 60 days: enforce and close gaps

• Deploy agents to uncovered in-scope assets or implement approved alternatives.
• Standardize policies through endpoint/server management so settings cannot be changed ad hoc.
• Implement exception workflow (request, approval, compensating control, review).
• Start ticket-driven remediation for non-reporting agents and scan failures.

By 90 days: make it repeatable for audits

• Build an “audit-ready” evidence pack template (what reports, from where, retained how long).
• Run an internal mini-assessment: sample systems, show periodic scan proof, show real-time/behavioral settings, show remediation tickets.
• If using Daydream, automate evidence collection and exception approvals so the package builds itself over time.

Frequently Asked Questions

Do we have to run both periodic scans and real-time protection?

Yes. The requirement calls for periodic scans and either active/real-time scans or continuous behavioral analysis. Plan for both elements to be provable in evidence. (PCI DSS v4.0.1 Requirement 5.3.2)

Can EDR replace traditional anti-virus for PCI DSS 5.3.2?

EDR can satisfy the “continuous behavioral analysis” part if it is truly continuous and enabled, but you still need periodic scans as required. Document how your EDR meets the requirement and retain operational proof. (PCI DSS v4.0.1 Requirement 5.3.2)

What systems should be included in anti-malware scanning for PCI scope?

Include systems and processes in scope for cardholder data, plus administration points that can affect those systems. Start from your PCI scoping and asset inventory, then validate coverage with agent reporting.

What evidence is strongest for auditors: screenshots or exports?

Exports and reports showing configuration and historical scan execution are stronger because they are repeatable and time-bound. Use screenshots only as supporting context, not as your primary proof.

How do we handle systems where anti-malware agents are not supported?

Document the constraint, implement continuous behavioral analysis where possible, keep periodic scanning coverage where applicable, and formalize the exception with approval and review. Keep the exception register ready for the assessor. (PCI DSS v4.0.1 Requirement 5.3.2)

What’s the most common reason teams fail this requirement during an assessment?

They cannot prove the control operated over time. Fix that by retaining periodic scan logs/reports, health status trends, and tickets showing response to failures and detections.