03.14.02: Malicious Code Protection

To meet the 03.14.02: malicious code protection requirement, you must deploy and operate technical and procedural controls that prevent, detect, and remediate malicious code across every system component that stores, processes, or transmits CUI, and you must be able to prove those controls work with current evidence. Document the implementation in your SSP and track gaps to closure in your POA&M. ¹

Key takeaways:

• Cover endpoints, servers, email, and cloud workloads with malware prevention plus ongoing monitoring and response.
• Make the control auditable: defined standards, assigned owners, and recurring evidence mapped to the SSP/POA&M.
• Treat exceptions (offline assets, enclaves, lab systems) as first-class scope items with compensating controls and proof.

03.14.02 sits in the NIST SP 800-171 security requirements that federal contractors and other nonfederal organizations must implement when handling Controlled Unclassified Information (CUI). In practice, assessors do not accept “we have antivirus” as an answer. They look for a defined malicious code protection program with clear scope boundaries, standardized configurations, timely updates, monitoring, alert handling, and evidence that the program runs continuously in the environment that touches CUI.

This requirement also tends to surface gaps that are operational, not tool-related: unmanaged endpoints, exceptions that never got documented, alerts routed to an unmonitored mailbox, or a mismatch between what the SSP claims and what is deployed. Your objective as a Compliance Officer, CCO, or GRC lead is to turn 03.14.02 into a small set of testable statements, bind each statement to owned system components, and run an evidence cadence that makes audits boring.

The guidance below is written to help you operationalize quickly: scope, actions, artifacts, and the audit questions you will get. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.14.02 (Malicious Code Protection).” ¹

Operator meaning (what you must be able to demonstrate)

You must have controls that protect CUI systems from malicious code and you must be able to show:

1. what is covered, 2) how protection is implemented, 3) that it stays current, and 4) that detections are handled through a defined process with evidence. Document the control in your System Security Plan (SSP) and manage shortfalls in a Plan of Actions and Milestones (POA&M). ¹

Plain-English interpretation of the requirement

Malicious code protection means you prevent malware from executing, you detect it when prevention fails, and you respond consistently. For most environments, that translates to managed anti-malware/EDR on endpoints and servers, malware scanning at key ingress points (email, web downloads), alert monitoring, and a repeatable workflow for containment, eradication, and recovery.

Assessors will focus on two failure modes:

• Control exists but is not provably operating (no logs, no alert workflow, stale agents, unmanaged devices).
• Control is deployed but not aligned to CUI scope (CUI enclaves excluded, third-party-managed hosts not covered, cloud workloads missing agents).

Who it applies to

Entities

• Federal contractors and other organizations operating nonfederal systems that handle CUI. ¹

Operational context (where it must work)

Apply the requirement to all in-scope system components that store, process, or transmit CUI, including:

• User endpoints (corporate and approved remote devices)
• Servers (on-prem and cloud)
• Virtual machines and managed container hosts (where applicable)
• Email and collaboration surfaces that can carry CUI or attachments
• File shares, document repositories, and VDI/Citrix-style environments
• Admin jump boxes and privileged workstations used to manage CUI systems

Include third parties when their services provide system components in your CUI boundary (managed IT, SOC, MDR, hosted desktops). You still own proving the control works.

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

Step 1 — Define scope and ownership in the SSP

1. List in-scope assets: endpoints, servers, cloud workloads, email gateways, and any special networks (lab, OT-like segments) within the CUI boundary.
2. Assign a control owner (accountable) and implementation owners (responsible): Security Operations, IT Endpoint, Cloud Ops, Messaging.
3. Write SSP control statements that are testable, such as:
   • “All in-scope endpoints and servers run centrally managed anti-malware/EDR.”
   • “Signatures/detection content update automatically and failures generate alerts.”
   • “Malware alerts are triaged and tracked to closure.”
4. Map each statement to system components (tools and platforms) and to where evidence is produced. ¹

Practical tip: Keep SSP statements short enough that you can test them in an hour during an assessment.

Step 2 — Standardize your malicious code protection baseline

1. Select the control stack for each platform: endpoint EDR, server EDR, email security scanning, and (if applicable) web proxy/download scanning.
2. Define configuration standards:
   • Real-time protection on
   • Tamper protection on
   • Cloud-delivered protection (if supported) enabled
   • Scheduled scans (set a standard; document the cadence)
   • Exclusion management rules (who can approve, how you log it)
3. Define update expectations (agent versions and detection content). Document what “current” means in your environment and how you detect drift.

Step 3 — Deploy and prove coverage

1. Roll out agents to all in-scope endpoints/servers via your management plane (MDM, RMM, GPO, configuration management, golden images).
2. Validate coverage using a report that lists:
   • Total in-scope assets
   • Assets with agent installed
   • Assets actively reporting
   • Assets with stale check-ins
3. Handle non-standard assets (air-gapped machines, lab systems) with documented compensating controls (restricted media, controlled file transfer station, offline scanning workflow) and evidence.

Step 4 — Implement monitoring, alerting, and response workflow

1. Centralize telemetry (EDR console, SIEM, MDR portal) and define alert routing.
2. Create a triage runbook:
   • Severity classification
   • Containment steps (isolate host, disable account, block hash)
   • Evidence collection expectations (alerts, host details, actions taken)
   • Eradication and recovery steps
3. Track all confirmed malware events as tickets with timestamps and closure notes.
4. Define escalation for suspected CUI exposure and ensure the incident process references malicious code scenarios.

Step 5 — Manage exceptions and change control

1. Exception criteria: only allow exclusions (paths, processes, extensions) through a ticketed request.
2. Approval: require Security sign-off and a business justification.
3. Review cadence: periodically review exclusions and decommission those no longer needed.
4. Risk acceptance: if you cannot cover a system, document the risk decision and compensating controls in the POA&M until fixed. ¹

Step 6 — Run an evidence cadence (so audits are repeatable)

Set a recurring operating rhythm tied to what assessors ask for:

• Coverage report review (agent health, reporting status)
• Alert queue review (triage activity)
• Update/compliance checks (signature/content currency, agent version drift)
• Exception review (exclusions and allowlists)
• POA&M review for open items and closure validation ¹

Daydream fit (earned mention): If you manage multiple environments or business units, Daydream helps keep the SSP statement, component mapping, and recurring evidence in one place so the control stays auditable across changes.

Required evidence and artifacts to retain

Keep artifacts that prove design and operation. Minimum set:

• SSP excerpts for 03.14.02: control statements, scope, owners, and mapped components ¹
• Asset inventory for in-scope endpoints/servers/workloads (and how scope is determined)
• EDR/anti-malware coverage reports showing active reporting status
• Configuration baselines (screenshots/exported policies) and change history
• Update/compliance reports: signature/detection content currency; agent version compliance
• Alert/ticket evidence: a sample of malware alerts with triage notes and closure
• Incident response runbook entries for malware and containment steps
• Exception records: approved exclusions, rationale, approvals, review outcomes
• POA&M entries for gaps, target completion criteria, and closure validation ¹

Retention note: keep evidence long enough to cover your assessment period and to show continuous operation through personnel and tooling changes.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the list of CUI-scoped assets and prove they all report into your malware protection console.”
• “How do you know signatures/detection content is current? Show failures and how you remediate them.”
• “Show three recent malware alerts and walk me through triage to closure.”
• “Do you allow exclusions? Who approves them? Show me the last review.”
• “Your SSP says ‘all servers’; does that include cloud instances and ephemeral workloads?”

Hangup to plan for: assessors often pick a random hostname from your inventory and ask you to prove it is protected and reporting.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits	How to avoid
“AV installed” without proof of reporting	Installation does not prove operation	Keep agent health and last check-in reports; alert on stale agents
Unmanaged remote endpoints in scope	Creates blind spots for CUI exfiltration and ransomware	Enforce enrollment; block access to CUI apps from unmanaged devices
Exclusions sprawl	Exclusions become an attacker path	Require ticket + Security approval + periodic review
Cloud workloads not covered	SSP claims coverage but implementation stops at laptops	Include server and cloud images in deployment automation
Alerts not triaged consistently	Tools generate noise; auditors look for process	Define runbooks, severity, and ticketing requirements

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Your risk exposure is still concrete: malware events are a common precursor to credential theft and CUI compromise, and weak evidence hygiene (SSP/POA&M misalignment) increases the likelihood of failing customer or government-driven assessments. ¹

Practical execution plan (30/60/90)

A staged plan helps you move quickly without inventing unrealistic timelines.

First 30 days (Immediate stabilization)

• Confirm the CUI boundary and produce an initial in-scope asset list.
• Draft SSP control statements for 03.14.02 and assign owners. ¹
• Generate a first coverage report; identify missing/stale agents.
• Stand up a basic alert-to-ticket workflow for malware detections.

By 60 days (Operational consistency)

• Implement standardized policies (real-time protection, tamper protection, scanning standards).
• Document and enforce exclusion approvals; inventory current exclusions.
• Create malware triage runbooks and validate the team can execute them.
• Open POA&M items for any platforms you cannot cover and define compensating controls. ¹

By 90 days (Audit-ready evidence cadence)

• Run recurring reviews: coverage, updates, alerts, and exclusions.
• Collect an evidence packet that matches each SSP statement to artifacts.
• Perform an internal control test: sample assets and prove protection and reporting.
• Close POA&M items where possible; validate closure with evidence before marking complete. ¹

Frequently Asked Questions

Does 03.14.02 require EDR specifically, or is antivirus enough?

The text provided does not mandate a specific product category; it requires malicious code protection. In assessments, you still need demonstrable prevention, detection, and response coverage across the CUI boundary with evidence. ¹

How do we handle air-gapped or offline systems in the CUI enclave?

Treat them as in scope and document compensating controls, such as controlled media handling and offline scanning workflows. Record the procedure, who performs it, and retain execution evidence plus any exceptions in the POA&M. ¹

Are email and file downloads part of malicious code protection?

If email and downloads are a realistic ingress path for your environment, auditors commonly expect you to address them within your CUI boundary. Document where scanning occurs (gateway, endpoint, or both) and keep logs or reports that show it operates. ¹

What evidence is strongest during an assessment?

Coverage and health reports (showing active reporting), policy configuration exports, and a small sample of recent alert tickets with containment/closure notes tend to be persuasive. Evidence must map cleanly back to the SSP statement for 03.14.02. ¹

How do we document and control malware exclusions without breaking business apps?

Use a ticketed workflow with Security approval, a recorded business justification, and a review cadence to remove obsolete exclusions. Keep an exclusion register and show change history from your endpoint security console. ¹

What do we put in the POA&M if coverage is incomplete?

Record the specific gap (affected assets/platforms), interim compensating controls, an accountable owner, and objective closure criteria (what evidence will prove it’s fixed). Do not mark items complete until you have validated closure evidence. ¹

Footnotes

1. NIST SP 800-171 Rev. 3