Protect systems and networks from malicious software

To meet the protect systems and networks from malicious software requirement in PCI DSS 4.0, you must implement malware controls that detect, prevent, and respond on all in-scope systems, then keep evidence that the controls are consistently operating. Operationalize it by defining scope, standardizing endpoint and server protections, centralizing alerting and response, and proving coverage with reports and tickets.

Key takeaways:

• Scope comes first: “in-scope systems” includes endpoints, servers, and workloads that touch the CDE or connected systems in scope.
• Auditors look for operational proof: coverage, updates, alerts handled, exceptions approved, and periodic effectiveness checks.
• Response is part of the requirement: prevention alone fails if you cannot detect and act on malware events.

PCI DSS 4.0 expects you to treat malware as an operational risk to cardholder data environments (CDE) and connected systems, not as an IT checkbox. The requirement is simple to say and easy to fail in practice: malware controls must be deployed across the right assets, kept current, monitored, and tied to an incident response workflow that actually closes the loop.

Compliance teams typically run into two failure modes. First, incomplete scope coverage: a handful of endpoints or a “temporary” server build falls outside endpoint protection because it lives in a separate domain, VDI pool, cloud subscription, or inherited image. Second, weak evidence: teams have tools, but cannot prove that definitions are current, scans are running, alerts are triaged, and exceptions are controlled.

This page translates the PCI DSS 4.0 requirement into a requirement-level operating model you can implement quickly: what it applies to, what to build, what evidence to retain, and how to pass the “show me” questions you will get from a QSA, internal audit, or customer security assessor. Source for the requirement excerpt: PCI DSS v4.0 (PCI DSS Document Library) ¹.

Regulatory text

PCI DSS 4.0 (PCI-10) excerpt: “Detect, prevent, and respond to malware in in-scope systems.” ¹

Operator meaning: You need (1) malware prevention controls on all in-scope systems, (2) detection and alerting that surfaces malware events, and (3) a documented, repeatable response process that results in containment, eradication, recovery, and lessons learned. “In-scope” is the trapdoor: if an asset is in scope for PCI, malware protections must be deployed and evidenced on that asset.

Plain-English interpretation (what the requirement demands)

Implement and operate anti-malware controls so that:

• Coverage is complete across PCI in-scope endpoints, servers, and workloads.
• Protection stays effective (signatures/engines current, real-time protection enabled where applicable, tamper protection enforced).
• Monitoring exists (alerts are generated and reviewed, not just logged).
• Response happens (malware detections create incidents that are tracked to closure).
• You can prove it (system-generated reports + process artifacts + approvals for exceptions).

Who it applies to

Entity scope: Merchants and service providers that must comply with PCI DSS 4.0 ¹.

Operational scope (“in-scope systems”):

• Systems in the CDE and systems that can impact the security of the CDE based on your PCI scoping.
• Typical asset types: employee endpoints with CDE access, jump hosts, admin workstations, Windows/Linux servers, VMs, container hosts, VDI images, POS devices where supported, and cloud workloads that process/store/transmit card data or connect to systems that do.

Common scoping edge cases to resolve explicitly:

• BYOD devices with any CDE access path.
• Contractor laptops used for administrative access.
• Golden images and auto-scaling groups where agents can silently fail to install.
• Segmented networks where update services are blocked and signature updates fail.

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

Step 1: Define and freeze the in-scope asset inventory (for malware coverage)

1. Pull your PCI in-scope inventory (CMDB, cloud inventory, MDM, EDR console exports).
2. Tag assets as: CDE, connected/in-scope, or out-of-scope based on your PCI scope statement.
3. Establish an owner for each in-scope asset class (Workstations, Windows servers, Linux servers, cloud workloads, VDI, POS).

Deliverable: “In-scope malware coverage list” (asset list with hostname/ID, owner, environment, and protection status).

Step 2: Standardize the malware control stack by asset type

Build a simple standard that an auditor can understand and ops can apply:

Asset type	Required control state	Minimum operational notes
Corporate endpoints with CDE access	EDR/anti-malware agent installed, real-time protection enabled, tamper protection on	Enforce via MDM; block local admin from disabling agent where feasible
Servers in-scope	Server-compatible anti-malware/EDR installed; scheduled scanning policy set	Validate performance exceptions through formal approval, not ad hoc disables
Cloud workloads	Agent baked into images or installed at provisioning; centralized management	Require agent health checks as part of CI/CD or provisioning pipelines
VDI/Golden images	Agent included in base image; updates validated post-deploy	Confirm clones check in and do not share duplicate identifiers in console

Key control decision: pick one authoritative console for reporting. Mixed tools are fine operationally, but they complicate evidence and exception tracking.

Step 3: Implement prevention and hardening configurations

Configure policies to prevent common malware execution paths:

• Enable real-time protection where supported.
• Block or restrict user ability to disable protections.
• Ensure automatic updates for engines/signatures, or document and run a compensating update process for isolated networks.

Evidence goal: You must be able to show “effective configuration” via policy screenshots/exports and sample endpoint/server configuration states.

Step 4: Implement detection, alerting, and triage routing

1. Define what constitutes a malware event (detection, quarantine, blocked execution, suspicious behavior).
2. Route events to your ticketing/IR workflow (SIEM/SOAR integration, email-to-ticket, or manual queue with documented daily review).
3. Establish triage SLAs as internal targets (avoid publishing numeric commitments you cannot meet); document severity mapping and escalation.

Evidence goal: alert records and the linked incident/tickets demonstrating review and closure.

Step 5: Build “respond to malware” into incident response operations

Your IR process must show repeatability:

• Containment: isolate host, disable accounts, block hashes/domains where appropriate.
• Eradication: remove malware, patch exploited weakness, rotate credentials if indicated.
• Recovery: restore from known-good state; validate with follow-up scans.
• Post-incident: document root cause and control improvements (policy change, user training, hardening).

Make response auditable: ensure each malware incident has a record of actions taken and final disposition.

Step 6: Run periodic effectiveness checks (prove the control works)

PCI DSS 4.0 will reward teams that can demonstrate ongoing validation, not just deployment ¹. Implement:

• Coverage reviews (agent installed and reporting).
• Update/definition currency checks.
• Test detections (benign test files or simulation tools approved by security) in a controlled environment.
• Exception reviews (what’s excluded from scanning and why).

Operational tip: Put these checks on an evidence calendar aligned to your assessment window so you can produce artifacts on demand.

Required evidence and artifacts to retain

Keep evidence in a single “PCI-10 Malware” folder (GRC repository, ticketing attachment set, or Daydream control record). Minimum set:

• Scope artifacts: PCI scope statement excerpt or in-scope system list that ties to malware coverage.
• Tooling inventory: list of anti-malware/EDR products and management consoles in use.
• Policy/configuration evidence: exported policy settings, screenshots, or configuration baselines showing real-time protection, update settings, tamper protection, and scan schedules.
• Coverage reports: console reports showing in-scope assets checked in, protected, and healthy; include exception lists for non-reporting endpoints.
• Update/health reports: evidence that signatures/engines update successfully (or documented offline update process).
• Incident/ticket samples: malware detections with investigation notes, containment/eradication steps, and closure.
• Exception register: approved exclusions (file paths, processes, hosts), business justification, compensating controls, approval, and review cadence.
• Effectiveness checks: results of periodic reviews/tests and corrective actions taken.

Daydream can help by turning this into a single control workspace: scoped asset lists, evidence requests, and recurring evidence tasks mapped to PCI DSS 4.0 so you do not rebuild the same audit packet each cycle.

Common exam/audit questions and hangups

Expect these “show me” prompts:

• “Show your population of in-scope systems and prove anti-malware is installed and reporting on all of them.”
• “How do you know protections cannot be disabled by end users or local admins?”
• “Show that signature/engine updates are current for in-scope servers that cannot reach the internet.”
• “Provide examples of malware alerts and the incident response records for each.”
• “Which systems are excluded from scanning, and who approved those exclusions?”
• “How do you verify the control stays effective over time?”

Hangups that cause findings:

• Asset inventory mismatches between CMDB, cloud inventory, and EDR console.
• Multiple consoles with inconsistent reporting, causing “unknown coverage.”
• No clear linkage between an alert and a closed incident record.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “AV installed” as compliance.
   Avoid: Require evidence of detection + response: alert handling records and closure.

2. Mistake: Exceptions live in email or tribal knowledge.
   Avoid: Maintain a formal exception register with expiration/review and compensating controls.

3. Mistake: Golden images and auto-scaling create blind spots.
   Avoid: Add agent-health checks to provisioning and build pipelines; block promotion if the agent is missing or unhealthy.

4. Mistake: Offline or segmented networks miss updates.
   Avoid: Document an update distribution method (internal update server, staged packages) and retain update logs as evidence.

5. Mistake: No operational owner for malware events.
   Avoid: Assign queue ownership (SOC, IT Ops, SecOps) and document triage and escalation.

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement, so this page does not cite specific enforcement actions.

From a risk perspective, weak malware controls increase the likelihood that credential theft, remote access tooling, and lateral movement reach in-scope systems. For PCI programs, the practical impact is predictable: assessment delays, compensating control debates, and higher effort evidence collection because you cannot prove coverage and response.

Practical 30/60/90-day execution plan

Days 0–30: Get to “known scope + basic coverage”

• Confirm the PCI in-scope asset population and owners.
• Export current EDR/anti-malware coverage reports; identify gaps and non-reporting devices.
• Deploy agents to missing in-scope assets; fix basic policy drift (real-time on, updates on).
• Stand up an exception register and stop ad hoc exclusions.

Exit criteria: You can produce a list of in-scope assets and a matching protection status report.

Days 31–60: Make it auditable (alerts + response + evidence cadence)

• Route malware alerts to a tracked workflow (tickets/incidents).
• Update IR procedures to include malware-specific steps and required documentation fields.
• Implement periodic effectiveness checks (coverage review, update review, exception review).
• Create an evidence pack template (reports + screenshots + ticket samples) in your GRC system or Daydream.

Exit criteria: You can show closed malware events with documented response actions.

Days 61–90: Reduce findings risk (hard cases and automation)

• Address the hard assets: isolated servers, VDI pools, build pipelines, cloud auto-scaling.
• Add control gates: new in-scope assets must enroll in EDR to pass provisioning.
• Run a tabletop or controlled test of malware detection/response and capture results as evidence.
• Internal audit dry run: answer the common “show me” questions with your evidence pack.

Exit criteria: Evidence is repeatable, not handcrafted, and exceptions are rare and well-justified.

Frequently Asked Questions

Do we need anti-malware on every system in the company?

The requirement applies to in-scope systems for PCI DSS, not necessarily every corporate system ¹. Your first task is to define scope and prove coverage for that scoped population.

Are EDR tools acceptable, or does it have to be “traditional antivirus”?

PCI DSS 4.0 focuses on outcomes: detect, prevent, and respond to malware ¹. EDR can satisfy this if it is deployed, monitored, and tied to response with auditable evidence.

How do we handle servers that cannot reach the internet for signature updates?

Document the update mechanism you use (internal repository, staged packages, or update relays) and retain logs or reports proving updates occurred. Auditors will ask how you confirm currency and what you do when updates fail.

What counts as “respond to malware” for audit purposes?

You need incident records that show containment and remediation actions, not just an alert in a console ¹. A closed ticket should show what was detected, what actions were taken, and the final status of the host.

Can we exclude directories or processes from scanning for performance reasons?

Yes, but exclusions are a common audit hangup. Maintain a controlled exception process with business justification, approval, compensating controls, and periodic review evidence.

What evidence is usually fastest to produce during a PCI assessment?

A current in-scope asset list, an EDR/anti-malware coverage and health report for that list, and a small set of malware incident tickets mapped to alerts. Store them together so you can respond to requests without rebuilding the packet.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. PCI SSC, PCI DSS v4.0