03.14.02 Malicious code protection: evidence and tests

What 03.14.02 malicious code protection asks for and why it is harder than it looks

03.14.02 asks for malicious code protection mechanisms at system entry and exit points that detect and eradicate malicious code, stay updated as new releases become available, scan the system at a defined frequency, scan files from external sources in real time, and block, quarantine or otherwise mitigate what they find. The risk it addresses is simple to state: CUI can be harmed or exfiltrated when malicious code enters a nonfederal system through email, removable media, downloads or network sessions, or leaves through a compromised host. Rev. 3 folded Rev. 2's 3.14.4 (updating malicious code protection) into this requirement, and NIST treats the Rev. 2 3.14.5 periodic and real-time scanning requirement as addressed by it, so a team that already runs an endpoint agent cannot assume its Rev. 2 evidence carries over without review.

The hard part is the one organization-defined parameter: the frequency at which scans run. NIST does not assign that value. If the federal agency that holds your contract does not specify it, your organization must set it and document the reasoning, and an assessor will test whether the value is defined and whether the system actually follows it. Confirm with the contracting officer whether a value has been specified for your contract before you pick one. Whatever you choose, the scan schedule, the real-time settings and the update cadence must match what the system security plan says.

Installing an agent is the easy step. Proving coverage is harder. An assessor will ask for a current inventory of every endpoint and server in the boundary, reconciled against the agent console, with exceptions tracked and explained. Servers that are offline for long periods, appliances that cannot run agents, and cloud workloads created outside the normal build process are common gaps. Ask your team to produce a report that shows, for a sample of systems, the signature or engine version, the last successful scan, the last update and the action taken on any detection, because that is the evidence an interview and a test will rely on.

Which systems and entry and exit points are in scope for malicious code protection

Requirement 03.14.02 applies at system entry and exit points, so the scope is set by where CUI can arrive, leave and run. Each decision below changes how many scanners, agents and evidence sources you must configure, update and document.

Endpoints and servers that handle CUI

Every workstation, laptop and server that stores, processes or transmits CUI is a candidate for malicious code protection mechanisms. Scope should follow the system security plan's boundary, not the org chart, so administrator jump hosts and build servers count if they touch CUI. Check that each host has a mechanism, that updates reach it, and that scan schedules are recorded. The number of agents tracks the number of CUI-bearing hosts, so an accurate asset inventory is the first input.

Email and web gateways as entry points

Email and web gateways are the most common entry points for malicious code reaching CUI systems. Gateway scanning can cover traffic before it reaches endpoints, but it does not replace endpoint protection for files that arrive by other routes. Confirm which mail flows and proxies are in the boundary, and whether gateway scanning reports into the same evidence store as endpoint scanning. Each gateway adds a second scanner and a second set of logs to maintain.

Removable media and file transfer points

USB drives, optical media and file transfer servers are entry points that bypass network controls. Decide whether removable media is scanned on connection, scanned on a separate kiosk, or blocked by policy for CUI systems, and document the choice. Managed file transfer and secure upload portals also need scanning of files from external sources before they reach internal storage. Each transfer point adds a scanning step and a log source to the evidence set.

Outbound paths as exit points

03.14.02 covers exit points as well as entry points, so outbound channels such as upload services, egress proxies and cloud sync tools need inspection or control. The aim is to catch malicious code being staged or exfiltrated from CUI systems. Confirm which egress paths the boundary allows and whether scanning or blocking applies to them. Each outbound path that is scanned adds a rule set and a review step.

Cloud workloads and containers

Virtual machines, container images and serverless functions that process CUI fall within scope when they are part of the system boundary. Scanning a container image at build time is not the same as scanning a running workload, so identify which points the organization covers and how new images are checked before deployment. Cloud providers' native protections may cover parts of this, but the organization must confirm what they cover and retain evidence. Scope usually grows with the number of images and environments.

Third-party and managed systems

Managed service providers, outsourced helpdesks and external hosting that handle CUI must either run compliant malicious code protection or be covered by contractual requirements that do. Ask each provider which mechanisms, update cadence and scan frequency it applies, and request evidence rather than assurances. Where a provider's system is in scope, the organization still owns the requirement and must keep the records. Each external system adds an evidence source that someone must collect and review.

How an assessor tests malicious code protection under SP 800-171A

This table maps each SP 800-171A assessment step for 03.14.02 to the evidence an assessor asks for and the gaps they most often find. Read it as a checklist for what to prepare before an assessment, since the scan frequency value must be defined by your organization. Most findings trace to policy that names no frequency, update status that no one verified, or detections that were logged but not blocked.

Assessment step	Evidence the assessor requests	Common findings
Examine: malicious code protection policy and procedures	Approved policy and procedures covering scope, updates, scans, detection response and named owners	Procedures describe scanning in general terms with no frequency, owner or escalation path
Examine: configuration management procedures	Baseline showing the protection agent, signature settings and scan configuration for each system class	Baseline not updated after the tool changed, or exceptions left undocumented
Interview: personnel responsible for malicious code protection	Walkthrough of how alerts are triaged, quarantined and confirmed as eradicated	Staff cannot say who reviews detections or how eradication is verified
Interview: staff who install, configure or maintain systems	Confirmation that new builds and rebuilt hosts receive the protection agent before production use	Images or rebuilt hosts deployed without the agent
Test: process for employing mechanisms at entry and exit points	Coverage report linking mechanisms to email, web, removable media, endpoints and outbound paths	Gaps on servers outside the main console or on outbound traffic paths
Test: process for updating mechanisms as new releases become available	Update logs, version history and console output showing engine and signature currency	Update status assumed rather than checked; agents report outdated versions
Test: process for configuring scans and real-time file scanning	Scan schedules, real-time settings for files from external sources and sample scan logs	Real-time scanning disabled for external files or scan schedule not matching policy
Test: blocking, quarantine and mitigation of detections	Test detections with records showing block, quarantine or other mitigation action	Detections logged but not blocked or quarantined, with no eradication record
Check: organization-defined scan frequency is defined	Approved frequency value in policy and matching value in the scanner configuration	Frequency left as a placeholder or set by default without a documented decision

Implementing malicious code protection in the order an assessor expects

This sequence takes 03.14.02 from scope to evidence, so that the ODP value, the protection configuration and the exception record all exist before an assessor asks for them. Each step produces an artifact the assessor can examine, interview against or test.

Confirm scope and entry and exit points
Start by listing every system in the CUI boundary and every point where data or code enters or leaves it: email gateways, web proxies, removable media ports, file transfer services, remote access paths and cloud storage synchronization. The organization owns this decision, and an implementation partner can document it with the security team. The output is a coverage inventory that maps each system and each entry or exit point to a named protection mechanism, or to a documented reason that none applies. The step is done when the inventory matches the system security plan boundary and a reviewer can trace every in-scope system to a row.
Define the scan frequency and update rules
Set the organization-defined parameter for 03.14.02, which is the frequency at which malicious code protection mechanisms perform scans, and write it into the system and information integrity policy with the procedures that enforce it. The rules should also state how signatures, engines and detection content are updated as new releases become available, and who approves them. Rev. 3 leaves the ODP value to the organization unless the federal agency specifies one, so confirm the value with the contracting agency before approval. The output is an approved ODP value and a procedure an assessor can compare against the configuration.
Set real-time scanning for external files
Configure on-access or real-time scanning for files arriving from external sources, such as downloads, email attachments, removable media and inbound transfers. Pair this with scheduled full-system scans at the approved frequency so that files already on the system are also checked. Where open-source tooling is used, such as osquery for process, module and file hash visibility, or Wazuh for log-driven detection, record what each component covers and what it does not. The output is a configuration baseline that states the real-time scope, the scheduled scan settings and the update source for each in-scope system.
Deploy and verify mechanisms on every in-scope system
Install the chosen mechanisms on each system in the coverage inventory, including servers, workstations, virtual machines and cloud workloads, and confirm that each one reports as active and current. Use a fleet query or management console to compare the deployed population with the inventory, because gaps usually appear on systems added after the original rollout. The output is a deployment report that shows, per system, the product version, the last update, the last scheduled scan and any systems that are unprotected. Those gaps must be closed or added to the exceptions record in a later step.
Set blocking and quarantine behavior
Decide and configure what happens when malicious code is detected: block the file or connection, quarantine it for review, or apply another mitigation the organization approves. Eradication should be tested with a benign test file that the mechanism is expected to flag, so that the blocking and quarantine behavior is observed rather than assumed. Record which actions run automatically and which need an analyst. The output is a tested response matrix and a record of the test results, which an assessor can use when testing the mechanism's ability to detect, eradicate and block.
Connect detections to alerting and review
Route detection events to the monitoring or security operations queue, so that each detection creates a record with the system, file, action taken and the person who reviewed it. Wazuh, for example, can write matching alerts to log files and forward them to an indexer for dashboard review, and OpenSearch Security Analytics can record matches as findings with severity. Confirm that alerts reach a named reviewer and that the reviewer's follow-up is captured. The output is a working alert path with a sample detection traced from endpoint to review record.
Document exceptions and assessment evidence
Record every system, mechanism or scan that deviates from the baseline, with the reason, the compensating control, the approver and the review date. Keep the policy, the ODP approval, the configuration baseline, the deployment report, the test records and the review logs in one evidence set, indexed by requirement. Ask the assessor which evidence format they prefer before you assemble it. The output is an exceptions register and an evidence index that let an assessor move from each determination statement to a document, interview or test result without searching.

Evidence that passes 03.14.02 and how to keep it current between audits

An assessor testing 03.14.02 looks for a written procedure, a current inventory of protected systems, and records that show the mechanisms ran and responded to detections. The cards below cover the artifacts that prove each part, how often each one must be refreshed, and who on the team should own that refresh so the evidence still holds when the assessment arrives.

Malicious code protection procedure

The written procedure defines the mechanisms used at system entry and exit points, the scan frequency that the organization assigned to the 03.14.02 organization-defined parameter, and the steps for detection, eradication, blocking and quarantine. Assessors examine it, so the scan frequency in the document must match what the configuration actually does. Review it at least annually and after any change to tooling or scanning cadence. The information security lead owns the text, and the operations team confirms that it describes current practice.

Coverage inventory by mechanism

A coverage inventory lists every in-scope system, its role, the malicious code protection mechanism applied to it, and any system that is exempt with a documented reason. Gaps often appear in servers, build hosts, and systems that were added after the last review, so reconcile this list against the asset inventory and the system security plan. Refresh it whenever a system is added, retired or re-platformed, and confirm it at least quarterly. The system owner for each platform should attest to its entries.

Update and version history records

Records of engine and signature updates show that protection mechanisms receive new releases as they become available. Export version history from the management console or configuration management system, and keep a log of cases where an update was delayed, with the reason and the compensating control. Assessors often compare the version in the inventory with the version on a sample of hosts, so mismatches are a common finding. Pull a sample of hosts each month. The endpoint administrator maintains the log.

Scan schedule and real-time configuration exports

Configuration exports show the scheduled scan cadence and whether real-time scanning of files from external sources is enabled on each platform. Export them from the policy or configuration source of truth rather than from screenshots, and store them with a timestamp. Compare exports to the defined frequency and investigate any drift before the assessment. Export on every change and at least quarterly. The configuration management owner should run the export and the security lead should review the differences.

Detection and quarantine logs with response

Detection logs record each malicious code event, the host, the action taken (block, quarantine or other mitigation), and the follow-up such as eradication confirmation or a related incident ticket. Assessors look for evidence that detections were acted on, not only that they were logged. Keep a sample of detections with their closure notes, and retain logs under the organization's retention policy. The security operations team reviews detections weekly and tags each one with its closure status.

Interview-ready ownership records

Assessors interview the people responsible for malicious code protection and for installing, configuring and maintaining it, so the organization needs a current record of who holds each responsibility, their backup, and the escalation path. Name the roles in the procedure and keep the list aligned with the staffing roster. Verify it after every reorganization or departure, and at least once a year. Human resources and the security lead should confirm that each named person can explain the mechanism and the scan frequency in their own words.

What malicious code protection costs to meet and what drives it

This table breaks the cost of meeting 03.14.02 into its components, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and what to request in writing. No price levels are given here, so use it to build a like-for-like quote request with vendors and consultants.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Endpoint protection licenses or subscriptions	Recurring, usually annual or multi-year	Number of endpoints and servers in scope, number of system entry and exit points, and whether the licensing model is per device, per user or per capacity. Self-hosted open-source tooling such as Wazuh or osquery shifts this line toward infrastructure and labor.	Written per-unit terms, what counts as a billable device, renewal uplift terms, and whether signature updates and cloud-delivered detections are included.
Engineering time to deploy and configure	One-time, with some recurring tuning	Fleet size, heterogeneity of operating systems, number of network entry points such as email gateways, web proxies and removable media controls, and whether agents must be packaged for air-gapped or segmented networks.	A fixed-scope statement of which hosts and entry points are covered, the configuration baseline delivered, and acceptance tests the implementer will run.
Policy and procedure writing	One-time, with periodic review	Whether existing system and information integrity and configuration management procedures already describe malware protection, and how many business units must approve the text.	Deliverable list (policy, procedure, scan schedule definition), review cycle, and who approves the scan frequency that the 03.14.02 organization-defined parameter requires.
Ongoing update and coverage checks	Recurring	How often signatures and engine releases are published, how many systems fall outside management, and whether checks are automated through dashboards or performed by hand. Automation generally lowers staff hours per cycle.	Documented update cadence, the coverage report format, the escalation path for hosts that miss updates, and the staff hours assumed per cycle.
Evidence upkeep	Recurring	Retention period for scan logs and detection records, number of systems sampled by an assessor, and whether evidence is exported from the platform or assembled manually.	Evidence list mapped to the examine, interview and test objects in SP 800-171A, export format, and storage location.
External testing or review	Recurring or per engagement	Scope of the test (sample of endpoints, email gateway, removable media path), whether the review tests detection quality or only configuration, and how many retests are included.	Written test scope, method (configuration review or detection testing), deliverables, and the number of retests included in the fixed price.
Assessor time	Per assessment cycle	Whether the organization is preparing for a Basic Assessment, a DCMA DIBCAC assessment or a CMMC assessment, and how clean the evidence package is on arrival. Only an independent assessor or certification body issues the result.	Assessor's own written fee schedule, the assessment scope they will examine, and whether they charge for re-review after findings are corrected.

Self-hosted open source tools that support malicious code protection evidence

Malicious code protection is judged on evidence that scanning and updates happen at entry and exit points, on schedule, and that detections are acted on. The tools below can produce parts of that record, but each covers a different slice of it. Confirm each one against the evidence your assessor expects before relying on it.

osquery for fleet state queries

osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. Its osqueryd daemon can schedule the same queries across an entire fleet of hosts, which gives a recurring record of what is running where. For 03.14.02, this helps show that suspicious processes or unexpected kernel modules are checked at a defined frequency. Confirm the query schedule matches the scan frequency you assigned to the organization-defined parameter. License: Apache-2.0 OR GPL-2.0-only.

Velociraptor for artifact hunts

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that collect one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing combined results. This supports the investigation and eradication side of 03.14.02, where you must show that detected code was located across the fleet and removed. Confirm that your hunts and retained results meet your evidence retention needs. License: AGPL-3.0-only.

OpenSearch Security Analytics detectors

OpenSearch Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with rule, log type and severity, and alerts can go to channels such as Slack or email. Its correlation engine links findings across log types, which helps show how a malware detection on one host relates to other activity. Confirm that your endpoint and security logs are ingested and that detections for malicious code are enabled. License: Apache-2.0.

Wazuh rule-matched alerts

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. For 03.14.02, the alert trail can show that malicious code events were detected and routed for response. Confirm that the rules cover the malware events your scanner produces and that alert retention matches your records requirements. License: GPL-2.0-only.

What these tools do not replace

None of these tools is a malicious code scanning engine. If your organization chooses a commercial anti-malware product to scan at entry and exit points, that product still performs the detection, eradication, updates and blocking or quarantine that 03.14.02 requires. The open-source tools supply query, hunt, alert and review evidence around it. Ask your assessor which records they will examine, and confirm that the scanner's own logs flow into the monitoring stack.

Who does what: your team, an implementation partner and the auditor

Your organization owns requirement 03.14.02. Accountability stays with you even when an outside party deploys the tools, because the federal agency with the contract holds the organization responsible for implementation and compliance. Your team sets the malicious code policy, chooses the scan frequency that fills the organization-defined parameter, and decides how detections are blocked, quarantined or escalated. Assessors will look for named owners who can explain those choices.

Policy and procedures: Maintain the system and information integrity and malicious code protection procedures that assessors examine, and keep them current with the actual deployment.
ODP value: Assign and document the scan frequency. NIST does not set it for you, and an undefined value leaves the requirement incomplete.
Blocking and exceptions: Decide which detections are blocked or quarantined automatically, who approves any exception, and how long it lasts.
Evidence ownership: Retain scan logs, update records, alert tickets and coverage reports, and be able to produce them on request.
Sign-off: Approve the final configuration and accept residual risk in writing.

Before engaging anyone, confirm which named person will answer assessor interview questions about this control.

Where organizations fall short on malicious code protection and how to close each gap

Assessors testing 03.14.02 rarely fail an organization for owning an endpoint protection product. They fail it when the product's coverage, update status, scan schedule and response steps cannot be shown from evidence. The cards below cover the gaps that most often appear in examine, interview and test activities, and the fix for each.

Scan frequency left undefined

03.14.02 has one organization-defined parameter: the frequency at which malicious code protection mechanisms perform scans. If the organization has not assigned a value, the requirement is incomplete even when scanning runs. Assessors check that the value exists in the system security plan or policy and that scan logs match it. Fix this by setting a specific frequency, documenting it, and configuring the product to enforce it. Confirm the value with the agency or contract owner if they specified one.

Coverage that skips servers and removable media

Endpoint agents are often installed on workstations while servers, cloud workloads and build hosts stay outside the console. Removable media and file shares feeding the system are also common blind spots. An assessor will compare the asset inventory against the agent deployment report and look for hosts with no agent. Fix this by reconciling inventory with the console each cycle, requiring agents on every system in the boundary, and scanning removable media on connection. Osquery can help confirm which hosts report running processes and file hashes.

Signature and engine updates never verified

Requirement 03.14.02 expects protection mechanisms to be updated as new releases become available. Many teams set automatic updates and never check whether they succeeded. Assessors ask for update timestamps, the current engine and signature versions, and what happens when an update fails. Fix this with a report of update status per host, an alert when a host falls behind, and a documented exception path for systems that cannot update, such as air-gapped enclaves.

Real-time scanning of external files not evidenced

The requirement calls for scanning files from external sources in real time. Organizations often enable on-access scanning on workstations but leave downloads, email attachments and file transfers into servers uncovered. Assessors test this by introducing a benign test file through the intended path and reviewing the detection record. Fix this by mapping each entry path, enabling real-time scanning on it, and keeping a test result that shows the control acted.

Detections without a documented response

The requirement asks that detected malicious code be blocked, quarantined or otherwise mitigated. Assessors often find that alerts reach a mailbox or dashboard but no procedure says who acts, how quickly, or how eradication is confirmed. Fix this by writing a short response runbook that covers block, quarantine, eradication, and escalation to incident response, then sampling past detections to show the runbook was followed. Wazuh alerts can be routed to the same case records used for incident handling.

Procedures that describe a retired product

Policies and procedures written for a previous antivirus product remain in the document set after the tool changes. Interviews then reveal that staff describe a different console, schedule or update path than the one in use. Assessors treat this as a documentation accuracy failure under the examine method. Fix this by reviewing the malicious code procedure after each tooling change, naming the current product and version in the system security plan, and retiring the old text with a dated revision record.

Questions buyers ask about meeting 03.14.02 malicious code protection

How much does it cost to meet 03.14.02 malicious code protection?

No researched figure for this work is available, so the cost depends on your scope and environment. The main drivers are how many systems and entry and exit points carry CUI, whether you already run endpoint protection that meets the requirement, how much policy and procedure documentation must be written, and how many scanning and reporting tools you need to configure and integrate. Costs split into one-time work (design, configuration, documentation, testing and evidence collection) and recurring work (updates, scan schedule upkeep, and review of detections). Ask any implementation partner for a fixed-scope written quote that lists each system, each deliverable and each recurring task separately. Assessment fees are a different cost, paid to an independent assessor, and should be quoted separately.

How long does 03.14.02 work take, and what does it depend on?

The timeline depends on the size of the environment and how much of the malicious code protection already exists. No researched duration is available for this requirement, so ask for a timeline in the written scope. Work usually runs in order: inventory the systems and entry and exit points that handle CUI, confirm the protection mechanisms and their update method, define the scan frequency (the organization-defined parameter for this requirement), configure real-time scanning of external files, and then collect evidence. Delays most often come from unclear ownership of the scan frequency value, incomplete asset inventories and change approvals for endpoint configuration.

What does the internal team need to provide?

The internal team owns the controls, so it must make decisions and supply access. Someone must set the organization-defined scan frequency and document it, approve how detections are blocked, quarantined or escalated, and confirm which systems are in the CUI boundary. IT operations must grant access to endpoints, email and web gateways, and removable media controls, and allow configuration changes. Security staff need to review detections and own the procedures for them. Expect a named contact for each area, and agree on that list before work starts.

Can a small team meet 03.14.02 without outside help?

A small team can meet the requirement in-house if it has someone who can configure endpoint protection, manage updates and read scan logs, and if the organization has documented policy and procedures. The work is less about buying a tool and more about proving the protection runs at the defined frequency, updates on new releases, scans external files in real time and blocks or quarantines what it finds. Small teams often struggle to produce consistent evidence over time and to keep the procedure current. An outside partner can help with setup and evidence design, but the organization must still own the controls and the day-to-day operation.

How does 03.14.02 differ from 03.14.06 system monitoring and 03.14.01 flaw remediation?

03.14.02 covers malware protection at entry and exit points: detecting and eradicating malicious code, keeping protection updated, scanning on a defined schedule and in real time, and blocking or quarantining detections. 03.14.06 covers monitoring the system for attacks, unauthorized connections and unauthorized use, including inbound and outbound traffic. 03.14.01 covers identifying, reporting and correcting system flaws and installing security-relevant updates within defined times. Malware detections from 03.14.02 often feed the monitoring work in 03.14.06, while patching under 03.14.01 reduces the flaws malware exploits. Each needs its own evidence, so keep separate records for scan configuration, monitoring alerts and patch timelines.

Does my contract require Rev. 2 or Rev. 3 wording for 03.14.02?

The contract decides which revision applies, so check the clause and any class deviation or agency direction that names it. NIST's Rev. 3 folded Rev. 2 requirement 3.14.4 into 03.14.02 and treats 3.14.5 as addressed by it, so the same protection work covers both. However, CMMC Level 2 assesses the Rev. 2 requirement as SI.L2-3.14.2 with its own scoring, and the DFARS revision and the FAR proposal named in the pillar facts differ on which revision applies. Confirm the applicable revision in writing with your contracting officer before scoping, and re-check when DoD or FAR rules change.

What can a partner provide to an assessor, and what can it not provide?

An implementation partner can prepare systems, configuration, procedures and evidence, such as scan configuration records, update logs, detection records and documented scan frequency, so the organization can show how it meets the requirement. A partner cannot issue an assessment report, attestation or certification. Only an independent assessor or certification body can do that. Your assessor will examine documents, interview staff and test the mechanisms, so the organization must be able to answer questions and demonstrate the live system. Confirm the assessor's requirements and the evidence format with the assessor before the work starts.

How DeployOpen scopes, implements and prepares malicious code protection evidence

DeployOpen works on 03.14.02 Malicious code protection by agreeing a written scope first, then deploying and configuring open-source tooling inside your own infrastructure and documenting the evidence an assessor will examine, interview and test. DeployOpen prepares the systems and evidence only. Independent assessors make any determination, and your organization owns its controls.

How we scope

Written scope lists the in-boundary systems, endpoints and entry and exit points where malicious code protection must operate.
Scope records the ODP value for scan frequency, which your organization must define if the federal agency does not specify it.
Scope confirms which policies, procedures and configuration baselines assessors will examine for this requirement.

How we build

Deploy and configure the malware protection mechanisms you select, with update and signature sources defined for each platform.
Configure scheduled and real-time scanning of files from external sources, plus blocking or quarantine of detected code.
Test detection and eradication on representative hosts, and document the results against the determination statements in SP 800-171A Rev. 3.

How we hand over

Deliver configuration documentation, update procedures and scan schedules that match the procedures your assessor will review.
Provide evidence packs showing update history, scan logs and detection records mapped to each determination statement.
Walk your staff through the interview topics for personnel responsible for malicious code protection and system maintenance.

How we support

Ongoing support and upgrades are available as a retainer, including review of update status and scan coverage after changes.
Re-test configurations when systems, scan frequencies or platform versions change, and refresh the evidence to match.
Confirm with your assessor and contracting officer which Revision of SP 800-171 applies before finalizing evidence scope.