Evaluation of Systems Not at Risk

PCI DSS 4.0.1 Requirement 5.2.3 requires you to periodically reassess any system component you claim is “not at risk for malware” and therefore does not need anti-malware. To operationalize it, maintain a defensible inventory of these components, track evolving malware threats relevant to them, and formally confirm (or revoke) the exception on a recurring cadence. (PCI DSS v4.0.1 Requirement 5.2.3)

Key takeaways:

• Keep a documented, owned list of all systems excluded from anti-malware, tied to scope and function. (PCI DSS v4.0.1 Requirement 5.2.3)
• Run periodic threat-focused evaluations for those systems, not a one-time “exception forever.” (PCI DSS v4.0.1 Requirement 5.2.3)
• Record a clear decision each cycle: still not at risk, or now requires anti-malware/compensating controls. (PCI DSS v4.0.1 Requirement 5.2.3)

“Systems not at risk for malware” is an exception path inside your malware controls program, and assessors will treat it like any other exception: it must be specific, justified, reviewed, and reversible. Requirement 5.2.3 does not ask you to prove a system is impossible to infect; it asks you to show you have a disciplined process for identifying which system components are not at risk, monitoring how the malware threat landscape changes for those components, and confirming whether the exception remains valid. (PCI DSS v4.0.1 Requirement 5.2.3)

This requirement shows up in real programs when you have appliances, embedded systems, purpose-built devices, container hosts with immutable images, segmented jump hosts with strict allowlisting, or other components where traditional anti-malware is unavailable, incompatible, or operationally unsafe. The risk is not theoretical: if you exempt broadly (“all Linux servers”), stop tracking changes, or cannot produce review records, the exception becomes a control gap.

The goal of this page is speed-to-implementation. You’ll get a working method: define “not at risk” criteria, build the authoritative exception list, run a repeatable evaluation, and retain evidence that an auditor can follow without reading minds.

Regulatory text

PCI DSS 4.0.1 Requirement 5.2.3 states: “Any system components that are not at risk for malware are evaluated periodically to include a documented list of all system components not at risk for malware, identification and evaluation of evolving malware threats for those system components, and confirmation whether such system components continue to not require anti-malware protection.” (PCI DSS v4.0.1 Requirement 5.2.3)

Operator meaning:

• You may have system components without anti-malware, but only if you can support the claim they are “not at risk.”
• You must keep an explicit list of those components (not an implied category).
• You must periodically evaluate malware threats relevant to those components.
• You must record a decision each review cycle confirming the exception remains valid, or switching the component into anti-malware coverage or alternative protection. (PCI DSS v4.0.1 Requirement 5.2.3)

Plain-English interpretation (what the requirement is really testing)

Assessors are testing whether your anti-malware control coverage is complete and whether exceptions are governed. A mature implementation has three characteristics:

1. Traceability: each excluded component is uniquely identified, owned, and linked to a reason anti-malware is not required or not feasible.
2. Threat-awareness: you show you considered how malware could realistically reach or execute on that component (supply chain, management plane, removable media, admin tooling, update channels).
3. Reversibility: you can revoke the exception and take action when conditions change (new software installed, new connectivity, new remote admin method, new exploit class). (PCI DSS v4.0.1 Requirement 5.2.3)

Who it applies to (entity + operational context)

Entities: Merchants, service providers, and payment processors validating against PCI DSS 4.0.1. (PCI DSS v4.0.1 Requirement 5.2.3)

Operational context (where this comes up):

• Payment environment system components (or connected components) where endpoint anti-malware agents cannot be installed, are unsupported, or create safety/availability issues.
• Infrastructure patterns where you rely on other malware risk-reduction controls (immutable builds, strict application allowlisting, controlled admin paths), but you must still justify why the component is “not at risk for malware.” (PCI DSS v4.0.1 Requirement 5.2.3)

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

1) Define “not at risk for malware” criteria you will enforce

Write criteria that are testable. Keep it narrow and component-specific. Examples of criteria you can defend operationally:

• The system does not execute arbitrary/untrusted code, and software installation is technically prevented or tightly controlled.
• Administrative access paths are restricted and monitored; management interfaces are not exposed broadly.
• The component has a controlled update mechanism and you validate updates through your normal change process.
• Network exposure is constrained to required flows only, and inbound/outbound connectivity is minimized.

Document these criteria as part of your malware/endpoint standard so teams cannot self-approve exceptions informally. (PCI DSS v4.0.1 Requirement 5.2.3)

2) Build the documented list of system components excluded from anti-malware

Create an inventory that is purpose-built for this requirement (even if it references your CMDB). For each component, capture:

• Unique identifier (hostname/asset ID/cloud resource ID)
• Environment and scope relationship (in-scope for PCI, connected-to, or supporting)
• OS/firmware type and role (appliance, hypervisor, embedded device, etc.)
• Reason anti-malware is not installed (not supported, breaks functionality, immutable image pattern, etc.)
• Compensating protections in place (segmentation, allowlisting, restricted admin paths)
• Owner and approver
• Last evaluation date and decision outcome (continue exception vs. revoke) (PCI DSS v4.0.1 Requirement 5.2.3)

Practical tip: make the list auditor-friendly. If the assessor can’t map the list back to real assets quickly, you will spend the audit arguing about completeness rather than security.

3) Perform the periodic evaluation: threats + conditions changed

Your evaluation should have two tracks:

A. Evolving malware threats relevant to the component Record what you checked and why it matters. Examples:

• New malware techniques relevant to the platform (firmware attacks, management plane compromise, signed update abuse).
• New remote administration tools introduced in your environment that could deliver malware payloads.
• Changes in attacker interest in the device class (for example, appliance-targeting campaigns).

You do not need to predict the future. You need to show a defensible check against evolving threats for that component class. (PCI DSS v4.0.1 Requirement 5.2.3)

B. Local change review Confirm whether anything changed that invalidates the “not at risk” posture:

• Connectivity changes (new routes, new VPN access, new peering)
• Privilege/access model changes (more admins, new IAM roles, shared accounts)
• Software/function changes (new packages, new scripting, new plugins)
• Operational changes (new third party remote support method, new patch tool)

Tie this to change management: if changes occur, trigger an out-of-cycle review for the impacted component. (PCI DSS v4.0.1 Requirement 5.2.3)

4) Make and record the decision: continue exception or require protection

Each evaluation cycle must end with a clear, recorded decision:

• Continue “not at risk” with justification and any follow-up tasks, or
• Revoke the exception and implement anti-malware, or
• If anti-malware still cannot be installed, document what alternative protections you are implementing and how they reduce malware risk for that component.

Avoid vague outcomes like “reviewed, OK.” Write what was reviewed, what threats were considered, and why the decision is reasonable. (PCI DSS v4.0.1 Requirement 5.2.3)

5) Operationalize ownership and cadence

Assign ownership to a role that can enforce change: endpoint/security engineering for general compute, network/security engineering for appliances, and IT operations for inventory integrity. Schedule recurring reviews and align them with vulnerability management and change windows so the work actually happens. (PCI DSS v4.0.1 Requirement 5.2.3)

If you need workflow support, Daydream can track exception inventory, route time-bound reviews to asset owners, and retain approval evidence in a single control record so audits don’t become a spreadsheet scavenger hunt.

Required evidence and artifacts to retain

Retain artifacts that let an assessor re-perform your reasoning:

• Documented list of all system components not at risk for malware (exportable, dated). (PCI DSS v4.0.1 Requirement 5.2.3)
• Evaluation records for each review cycle, including:
  • What threat sources/inputs were checked (describe inputs even if you don’t attach them)
  • What changed in the environment (or confirmation nothing changed)
  • Decision + approver + date (PCI DSS v4.0.1 Requirement 5.2.3)
• Supporting technical evidence (as applicable):
  • Screenshots/config exports showing restricted services, locked-down management interfaces, allowlisting, immutable build pipelines, or segmentation rules
  • Change tickets proving update controls and configuration governance
• Exception governance artifacts: criteria/standard, approval workflow, and triggers for out-of-cycle review. (PCI DSS v4.0.1 Requirement 5.2.3)

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the complete list of systems without anti-malware and prove it’s complete.” (PCI DSS v4.0.1 Requirement 5.2.3)
• “Why are these systems ‘not at risk’? Walk me through one example end-to-end.” (PCI DSS v4.0.1 Requirement 5.2.3)
• “What does ‘periodically’ mean in your program, and where is the evidence that it happened?” (PCI DSS v4.0.1 Requirement 5.2.3)
• “What evolving threats did you evaluate for this device class?” (PCI DSS v4.0.1 Requirement 5.2.3)
• “What happens when a system’s exposure changes?” (PCI DSS v4.0.1 Requirement 5.2.3)

Hangup to plan for: teams often provide a policy statement but cannot produce component-level evaluation records. Requirement 5.2.3 is explicitly component-oriented. (PCI DSS v4.0.1 Requirement 5.2.3)

Frequent implementation mistakes (and how to avoid them)

1. Over-broad exceptions (category-based)

• Mistake: “All Linux servers are not at risk.”
• Fix: exceptions must be asset-specific, with technical reasoning for that asset’s exposure and controls. (PCI DSS v4.0.1 Requirement 5.2.3)

2. No evolving threat consideration

• Mistake: only documenting “agent not supported.”
• Fix: add a threat check section: how malware could reach this component, what changed in attacker techniques relevant to it, and why your protections still hold. (PCI DSS v4.0.1 Requirement 5.2.3)

3. Stale lists

• Mistake: list exists, but assets are decommissioned/renamed or new appliances appear without being added.
• Fix: reconcile the exception list against CMDB/cloud inventory and procurement/implementation processes, and make “add to exception list or install anti-malware” a go-live gate. (PCI DSS v4.0.1 Requirement 5.2.3)

4. No revocation path

• Mistake: exception approvals have no expiry, no trigger, no owner.
• Fix: assign ownership, define review triggers, and document the decision each cycle. (PCI DSS v4.0.1 Requirement 5.2.3)

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this specific PCI DSS requirement. Practically, the risk is assessment failure (a finding for incomplete malware controls governance) and increased likelihood that unprotected components become a foothold through management interfaces, update channels, or admin workflows. (PCI DSS v4.0.1 Requirement 5.2.3)

Practical execution plan (30/60/90)

First 30 days: establish control ownership and baseline inventory

• Assign a control owner and approver role for “not at risk” determinations. (PCI DSS v4.0.1 Requirement 5.2.3)
• Define the criteria and minimum documentation required for an exception. (PCI DSS v4.0.1 Requirement 5.2.3)
• Produce the first documented list of excluded system components and validate it against real asset inventories. (PCI DSS v4.0.1 Requirement 5.2.3)

By 60 days: complete first evaluation cycle and close obvious gaps

• Run the first periodic evaluation for each listed component, including evolving threat considerations and local change review. (PCI DSS v4.0.1 Requirement 5.2.3)
• Revoke or remediate exceptions that are poorly justified; install anti-malware where feasible or strengthen alternative protections where not. (PCI DSS v4.0.1 Requirement 5.2.3)
• Implement a workflow for approvals, evidence retention, and re-evaluation scheduling (GRC ticketing or Daydream). (PCI DSS v4.0.1 Requirement 5.2.3)

By 90 days: operationalize continuous governance

• Integrate triggers into change management so connectivity/admin/tooling changes require an out-of-cycle re-evaluation. (PCI DSS v4.0.1 Requirement 5.2.3)
• Add a go-live control: no new in-scope component enters production without anti-malware coverage or a documented “not at risk” evaluation. (PCI DSS v4.0.1 Requirement 5.2.3)
• Run an internal audit-style spot check: pick a few exceptions and verify evidence is sufficient for an assessor to reproduce the decision. (PCI DSS v4.0.1 Requirement 5.2.3)

Frequently Asked Questions

What counts as a “system component not at risk for malware” under PCI DSS 5.2.3?

PCI DSS 5.2.3 does not define a fixed list; it requires you to identify the components you believe are not at risk and document why. Your justification must include threat evaluation and a recurring confirmation that the exception remains valid. (PCI DSS v4.0.1 Requirement 5.2.3)

How often is “periodically”?

The requirement says “periodically” but does not set an explicit interval in the provided text. Pick a cadence you can defend, document it in your standard, and prove you executed it with dated evaluation records. (PCI DSS v4.0.1 Requirement 5.2.3)

If anti-malware is unsupported on an appliance, is that enough to claim “not at risk”?

Unsupported tooling explains why you can’t install an agent, but it does not complete 5.2.3 by itself. You still need the component listed, a threat evaluation for that appliance class, and a recorded confirmation decision each cycle. (PCI DSS v4.0.1 Requirement 5.2.3)

Do we need an individual evaluation per asset, or can we evaluate by system type?

The text requires a documented list of all system components and evaluation of threats “for those system components.” Many teams evaluate by standardized build or model, then record that the evaluation applies to the specific listed assets that match that standard. (PCI DSS v4.0.1 Requirement 5.2.3)

What evidence will an assessor expect to see during a PCI audit?

Expect to show the exception inventory, the periodic evaluation write-ups (threats considered + what changed), and the approval/confirmation record that the component still does not require anti-malware. Add supporting configs or change tickets where they strengthen the narrative. (PCI DSS v4.0.1 Requirement 5.2.3)

How do we keep the exception list from becoming a spreadsheet nobody trusts?

Tie it to your asset inventory and change processes, assign owners, and require updates as part of provisioning and decommissioning. A workflow tool such as Daydream can centralize the list, enforce review tasks, and keep evidence attached to the control record. (PCI DSS v4.0.1 Requirement 5.2.3)