SI.L2-3.14.5 System and file scanning: evidence guide

What SI.L2-3.14.5 system and file scanning requires in plain terms

If you are preparing for a CMMC Level 2 assessment, SI.L2-3.14.5 is a 3-point requirement that must be scored MET, because it cannot be carried on a plan of action and milestones. Under the scoring methodology, a NOT MET result subtracts 3 points from the maximum of 110, and 32 CFR 170.21 does not allow a 3-point requirement on a POA&M. Your organization owns this control and must be able to show, with evidence in final form, that it runs two distinct kinds of scanning: periodic malicious code scans of its systems, and real-time scans of files from external sources as they are downloaded, opened or executed.

The two halves exist for different reasons. Periodic system scans find malicious code that already reached a host through a route that bypassed or predated your inline controls, such as removable media, a sync client, or a file that was clean when first stored and later flagged. Real-time file scanning stops malware at the moment a file from outside your boundary is about to run, which is where email attachments, web downloads and shared documents create most of the risk. The contractor sets the scan frequency, but under 32 CFR 170.14(d) that interval may be no longer than one year. Choose a shorter interval only if you can document why and then follow it, because an assessor will test that the scans actually ran at the frequency you defined.

Assessors test three things: that you defined the scan frequency, that scans ran at that frequency, and that external files are scanned in real time. They look for scan configurations, scheduled job records, scan results, and records of actions taken on detections, so gaps in logs are a common reason this requirement fails. Confirm with your assessor or C3PAO which artifacts they will accept for each half, and confirm that your scanner's logs and configuration history are retained long enough to cover the assessment period. Plan for both halves early, because a gap in either one leaves the requirement NOT MET.

Which systems, files and teams fall under SI.L2-3.14.5 scanning

SI.L2-3.14.5 applies to the organizational systems that handle CUI and to the paths files take into them. The cards below set out which assets, file sources and third-party services belong in scope, and which team owns each one, so the scan schedule and real-time controls cover the places where malicious code can enter.

CUI systems and their boundary

The scan requirement reaches the systems that store, process or transmit CUI, which is where your system security plan draws the boundary. Start from the asset inventory and mark every host, virtual machine and container that sits inside that boundary. Confirm with the assessor how they will test the periodic scan against each asset class. Engineering and IT operations usually own the scanner deployment, while the compliance lead owns the scope statement.

Servers and virtual infrastructure

Servers carry the highest impact when malware lands, because they run shared services and hold data for many users. Include domain controllers, application servers, database hosts and hypervisors that support the CUI environment. Scheduled scans on these hosts need maintenance windows that operations teams agree to in advance. Ask who owns the hypervisor layer, since a gap there leaves guest scans blind to host-level activity.

Endpoints and user workstations

Laptops and desktops are the most common entry point for files from outside the boundary, so they need both periodic scans and real-time checks on downloads, opened attachments and executed programs. Remote and traveling staff often fall outside network-based controls, so the endpoint agent must run wherever CUI is accessed. Helpdesk and endpoint management teams typically own enrollment, and the security team owns exception handling for devices that cannot run the agent.

File shares and collaboration stores

Network file shares and document repositories hold CUI copies that move between users, so they are a common path for malicious files to spread. Map every share that holds CUI, including sync folders and archived projects, and confirm which scanning method covers each one. Data owners and storage administrators should agree on who triggers a scan when a file is quarantined. Without that agreement, infected files can stay accessible while tickets wait for action.

Email, downloads and removable media

Email attachments, web downloads and media from outside the boundary are external file sources that SI.L2-3.14.5 specifically addresses. Real-time scanning must run as each file is downloaded, opened or executed, so the control has to sit on the endpoint or gateway that receives it. Removable media used with CUI also needs a scan before a user opens its contents. Confirm with the messaging and endpoint teams which path enforces each check, and record the owner of each path in your scope statement.

Third-party services that handle CUI

Cloud platforms, managed service providers and SaaS tools that store or process CUI become part of the scope, or must be addressed through a documented external service relationship. Ask each provider whether they run malicious code scanning on the systems that hold your data, and what evidence they can supply. Contract terms should name who performs the scans and who receives the results. Procurement and the contract owner should track these terms with the system security plan so the assessor can trace each external dependency.

How an assessor tests malicious code scanning and file checks

This table maps the three NIST SP 800-171A assessment objectives for SI.L2-3.14.5 to how an assessor tests them, the evidence they request and the findings that most often stop a requirement from being MET. Read each row as one objective that must be satisfied with final-form evidence before the requirement counts toward a passing score.

Assessment objective	How the assessor tests it	Evidence requested and common findings
Frequency of malicious code scans is defined	Assessor reads the scan configuration and the documented interval, then checks it is set by the organization and no longer than one year where the requirement uses the word periodically.	Evidence: scan policy or system security plan stating the interval. Common finding: a scan schedule exists in a tool but the interval is never written down or approved.
Scans run at the defined frequency	Assessor compares the scan schedule with the scan logs over a sample period and looks for gaps, failed jobs and skipped systems.	Evidence: scheduler configuration, scan job history and results for in-scope systems. Common finding: scans configured but silently failing on some hosts, or new systems missing from the scan scope.
Real-time scanning of files from external sources	Assessor selects files pulled from external sources, such as email attachments, downloads and removable media, and checks that scanning occurs as each file is downloaded, opened or executed.	Evidence: on-access scanning settings, endpoint or gateway policy and detection logs for sampled files. Common finding: on-access protection disabled for some users or no scanning for files opened from network shares.
Scan results are reviewed and detections acted on	Assessor traces a sampled detection from alert to documented action, such as quarantine, removal or investigation.	Evidence: scan results, ticket or case records and disposition notes. Common finding: detections logged but never reviewed, or actions not recorded.
Malicious code protection mechanisms are in place and current	Assessor checks that scanning mechanisms are installed on in-scope systems and that their update records match the scan period.	Evidence: inventory of scanning agents, update logs and version reports. Common finding: scanners installed on some systems only, or definitions months out of date.
Scope covers all in-scope systems	Assessor compares the system inventory and the system security plan boundary with the list of hosts reporting scan results.	Evidence: asset inventory reconciled with scan coverage reports. Common finding: servers, virtual machines or cloud workloads inside the CUI boundary that no scan reports cover.

Implementing periodic scans and real-time file checks, step by step

This sequence turns SI.L2-3.14.5 into a working scanning program with a defined schedule, real-time checks on external files, retained results and proof that a detection leads to a recorded action. Each step ends with an artifact an assessor can examine.

Scope systems and external file entry points
The organization lists the systems within the CUI assessment boundary, including endpoints, servers and any cloud workloads, and identifies every path by which external files enter them, such as email attachments, web downloads, removable media, file transfers and shared repositories. The system security plan owner confirms the list matches the boundary. The output is a scoped inventory of scanned systems and a separate list of file entry points, both reviewed and approved before tooling is selected.
Define and document the scan frequency
The organization sets the interval for periodic scans of its systems and records it in the system security plan or the scanning procedure. Under 32 CFR 170.14(d), the interval may be no longer than one year, but a shorter interval the organization can actually run is usually easier to defend. The output is a written schedule naming each system group, its scan interval and the person accountable for it, approved by the system owner.
Deploy periodic system scanning
Engineers deploy the chosen malicious code scanning tool to the in-scope systems and configure the scheduled scans to match the documented interval. Where the scanner is an endpoint agent, the team confirms each host reports in, and where it is a network or host-based scanner, the team confirms the scan target list matches the inventory from step one. The output is a configuration export and a fleet status report showing each in-scope system enrolled and scheduled.
Enable real-time checks on external files
Engineers turn on real-time scanning for files arriving from outside the boundary, so each file is checked as it is downloaded, opened or executed rather than only during a later scheduled run. This covers the entry points listed in step one, including mail and web gateways where they are in use. The output is a documented configuration for each entry point and a test record showing a known-test file is blocked or flagged on download or on open.
Configure alerting and scan result retention
The team routes scan detections and failed or missed scans to the people who must act on them, and sets a retention period for scan results and logs that the organization can justify to an assessor. Alerts should identify the host, file or process, the time and the detection. The output is a notification rule set, a named recipient list and a written retention setting for scan records, with a sample alert retained as evidence.
Test that a detection leads to a recorded action
The team runs a controlled test, using a harmless test file that the scanner is designed to flag, and follows the detection through alert, triage, containment or removal, and closure in the ticketing or incident system. The assessor-facing question is whether the action is recorded, not only whether the scanner fired. The output is a dated test record with the detection, the person who acted, the action taken and the closing entry, kept with the scan results.
Retain evidence for the assessment
The organization collects the schedule, configuration exports, real-time check records, scan reports, alert samples and the detection test record into one evidence folder, and confirms each item is in final form rather than a draft. The assessor checks these against the three assessment objectives in NIST SP 800-171A for 3.14.5. Confirm with your assessor or C3PAO which evidence formats they accept before the assessment begins.

How osquery, Velociraptor, Wazuh and Bareos support scan evidence

Four self-hosted open-source tools can generate the records an assessor will ask for when testing scheduled malicious code scans and file change detection. Each produces different evidence, and none of them satisfies SI.L2-3.14.5 on its own, because the organization must define the scan frequency, run the scans and keep the results and follow-up actions.

osquery for scheduled fleet queries

The osqueryd daemon runs SQL queries on a schedule across a fleet of hosts, covering running processes, loaded kernel modules, open network connections, browser plugins and file hashes. Scheduled query results give an assessor dated records of what each system was running at each check, which supports the periodic scan objective. Confirm that the scan interval you set is documented in your system security plan and that query results are retained and reviewed. Its license is 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 gather one or more artifacts across a group of systems. Hunts that check for known malicious indicators can show when a scan ran, which systems were covered and what was found. Offline machines are scheduled to collect when they reconnect, so confirm how you will document systems that were offline during a hunt. Its license is AGPL-3.0-only.

Wazuh for file integrity monitoring

Wazuh file integrity monitoring records a baseline of checksums and attributes for chosen files and directories, then alerts when a user or process creates, modifies or deletes a monitored file. It runs on a schedule or in real time, and its alerts record how and when a change happened and who made it. This addresses the real-time objective only for the paths you monitor, so confirm real-time file scanning coverage for downloads, mounted media and email attachments in your environment. Its license is GPL-2.0-only.

Bareos Verify jobs for cataloged attributes

Bareos Verify jobs compare files on a system against the attributes stored in its backup catalog, which gives a Tripwire-like check for changes after a suspected break-in. Verify job reports can serve as dated evidence that the comparison ran and what it found, provided you keep the reports with the backup records. A Verify job checks against the last backup, so it does not detect malicious code that was present when that backup was taken. Its license is AGPL-3.0-only.

What evidence passes a SI.L2-3.14.5 assessment

An assessor testing SI.L2-3.14.5 looks for proof in three places: the malicious code protection configuration, the record of how often scans run, and the record of what those scans found and what the organization did about it. The assessment objectives in NIST SP 800-171A, which the CMMC Level 2 assessment uses, ask whether the organization defined a scan frequency, actually scanned at that frequency, and checked files from external sources in real time as they are downloaded, opened or executed. Start by exporting the scanner policy or agent configuration showing scan schedules, real-time file checks enabled on endpoints and gateways, and the scope of systems covered. Then pull the scan job history for the full assessment period, since a single screenshot of a passing scan will not satisfy an assessor testing ongoing performance. Under 32 CFR 170.14(d), the organization sets its own interval for periodic scans, but that interval may be no longer than one year, so record the defined frequency in the system security plan and confirm the logs match it.

Scan results alone are not enough. Assessors expect records of actions taken on detections: quarantine or deletion events, tickets opened, containment steps, and follow-up scans confirming removal. Consistency matters more than volume. If the logs show gaps during which endpoints were offline, unmonitored or excluded from scanning, document why and show how coverage was restored. Confirm with your assessor and your C3PAO or consultant how they want real-time file check records presented, since products differ in what they log. Open-source options can produce parts of this evidence. osquery can schedule file hash and process queries across a fleet, and Wazuh file integrity monitoring can alert on changes to monitored files. Treat these as supporting records, and confirm that your chosen tools produce logs you can retain and export unchanged. Every artifact must be in final form. Drafts, unsigned reports and undated screenshots are not accepted as proof that a requirement is MET, so lock final exports with dates before the assessment.

What meeting SI.L2-3.14.5 costs in money and effort

This table breaks the cost of meeting SI.L2-3.14.5 into tooling, engineering, evidence upkeep, external review and assessor sampling. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. No dollar figures appear because none are supplied for this requirement.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Scanning tooling and licenses	Software vendor, if commercial endpoint protection or scanning is bought	Recurring (annual or per-seat licensing)	Endpoint count and vendor pricing model. Self-hosted open source such as osquery, Velociraptor or Wazuh can remove license spend, but hosting and staffing remain.
Engineering to configure scans and real-time checks	Internal IT or security staff, or an implementation partner under a written scope	One-time build, then periodic tuning	Number of operating systems, file sources in scope, and how many scan policies must be written and tested.
Defining the scan frequency	Internal policy owner	One-time decision, reviewed periodically	Under 32 CFR 170.14(d), the organization sets the interval but it may be no longer than one year. A shorter interval raises scan load and alert review time.
Evidence upkeep	Internal compliance or security staff	Recurring	Volume of scan logs, detection records and action tickets. Consistent naming, retention and final-form records reduce rework.
Handling detections and records of actions	Internal security operations staff	Recurring	Detection rate, false positive tuning and how well response steps are documented before an assessment.
External review or readiness check	Independent consultant or implementation partner, if engaged	Often one-time per cycle	Scope size, number of systems and whether the review is a gap check or a mock assessment. Ask for a fixed-scope quote with deliverables listed.
Assessor sampling and assessment time	Certified assessor or C3PAO, paid by the organization	Recurring per assessment cycle	Number of scan configurations, systems and records the assessor samples. Clean, consistent evidence shortens sampling. Confirm current assessment fees with the assessor.

Who does what for scanning: your team, a partner and the assessor

Your organization owns the requirement. The practice is assessed against your system security plan and your own decisions, so the scan policy, the scan frequency and the response to detections must be set and approved by people inside the company. Assessors test whether these decisions exist, whether they are followed and whether records show what happened. A partner can draft these documents, but the accountable owner signs them and runs them.

Scan policy: Define which systems, endpoints and file sources are in scope, which malicious code protection mechanisms apply and who may change them.
Frequency decision: Set the interval for periodic scans and record the reasoning. Under 32 CFR 170.14(d), the interval is yours to set, but it may be no longer than one year.
Real-time file checks: Decide which external sources (email attachments, removable media, downloads, shared transfers) are checked as files are downloaded, opened or executed.
Detection response: Assign who triages a detection, who isolates a host and how each action is recorded.
Operating records: Keep scan results, exception approvals and corrective action records in final form.

Before an assessment, confirm that a named owner can produce the policy, the frequency decision and a sample of detection records without help from the partner.

Where organizations fall short on system and file scanning

Most SI.L2-3.14.5 failures are not missing scanners. They are gaps in how scanning is defined, scoped and documented. Assessors test three objectives, so each gap below maps to a part of the requirement that must be shown with evidence in final form.

No documented scan frequency

The requirement calls for periodic scans, and the organization must define that interval. Where a scan schedule exists only in a tool's default settings, assessors have nothing to test against. Write the frequency into the system security plan or scanning procedure, set it in the scanner or osquery schedule, and keep the approved document with a revision history. The interval may be no longer than one year under 32 CFR 170.14(d), so confirm that your chosen interval is within that limit.

Real-time checks missing for downloads

Periodic scans do not cover files from external sources when they are downloaded, opened or executed. Browser downloads, email attachments, USB drives and files pulled from shared repositories often bypass the on-access check. Confirm that real-time protection is enabled on every endpoint and file server, and test it by placing a benign test file from an external source and recording the detection or the block. Keep the test result as evidence.

Removable media left unscanned

Files arriving on USB drives, external disks and mounted network shares are external sources that many endpoint configurations treat as trusted. Removable media policies often exist on paper while the scanner is not configured to check mounts. Check that the policy, the endpoint configuration and the scanning agent all cover removable devices. Record which device classes are covered so an assessor can match the configuration to the stated scope.

Scan results not retained

A scan that runs but leaves no record cannot show that the requirement is operating. Scanner logs, scan summaries and job completion records need a retention period set by the organization and stored where the assessor can review them. Forward scan results to a central log store or SIEM, confirm that retention settings are applied to that store, and export a sample month of results for the evidence folder.

Detections without recorded actions

A detection means little unless the record shows what was done about it. The assessment objectives look at the actions that follow a detection, not only the detection itself. For each alert, record the file or host affected, the disposition (quarantine, removal, false positive), the person who acted and the time. Tie these records to the incident response process so a detection that becomes an incident is tracked from start to close.

External services outside the boundary

Cloud file sharing, SaaS collaboration tools and managed services that handle CUI can receive files that never pass through an in-boundary scanner. Identify each external service that stores or transfers CUI, document whether it scans uploads and downloads, and where it does not, record a compensating control or a scope decision. Ask providers for written descriptions of their malicious code protection and the evidence they can supply for an assessment.

Questions buyers ask about SI.L2-3.14.5 scanning

How much effort does SI.L2-3.14.5 scanning take to meet?

Effort depends mainly on how many systems and endpoints are in scope, how many external file paths carry CUI-related traffic, and how much of the scanning stack already exists. The requirement has two parts: periodic scans of organizational systems and real-time scanning of files from external sources as they are downloaded, opened or executed. Most of the work is in deploying and configuring the scanning mechanisms, tuning them, and keeping records of scan results and the actions taken on detections. Scanning costs recur through tool licensing or infrastructure, staff time to review results, and updates to signatures and rules. Ask any provider for a written breakdown of which systems are covered, which tools are deployed, and who reviews the output.

Can a contractor meet SI.L2-3.14.5 in-house?

Yes, a contractor can meet SI.L2-3.14.5 with its own staff, provided it can show the scanning mechanisms, scan records and follow-up actions that the assessment objectives in NIST SP 800-171A call for. The organization owns its controls and its evidence. An implementation partner can help deploy and document scanning tooling, such as the open-source options described on this page, but it does not issue reports or certificates. Independent assessors test the result. In-house teams usually need clear ownership of scan schedules, alert triage and records of detections, because assessors look for proof that the scans ran and that findings were acted on.

How long does it take to have SI.L2-3.14.5 evidence ready?

The timeline depends on whether the scanning tooling is already running and whether its output is retained in a form an assessor can review. If scanning is new, the time goes into deployment, baseline scans, tuning and a period of real operation that produces records. Evidence must be in final form, not drafts, before a requirement is treated as MET under the assessment rules in 32 CFR 170.16 and 170.17. Ask a provider to confirm the time needed for deployment, the length of the run period before assessment, and the schedule for any retest. Any specific duration should come from a written scope, not from a general estimate.

What does the work need from the internal team?

The internal team needs named owners for four things: the scanning platform, the scan schedule, the triage of detections, and the records kept for assessment. An engineer usually administers the agents or daemons, a security analyst reviews results and documents actions, and an IT owner approves changes to scan scope. The team also needs access to the systems in scope, a place to store evidence, and time to respond to findings. A partner can build the runbooks and dashboards, but the organization must still perform the reviews and keep the records itself.

Can SI.L2-3.14.5 be placed on a POA&M?

No. SI.L2-3.14.5 is a 3-point requirement under the CMMC scoring methodology in 32 CFR 170.24. Under 32 CFR 170.21(a)(2), a requirement worth more than 1 point cannot go on a plan of action and milestones, so it must be MET to reach Conditional or Final Level 2 status. Contractors should therefore plan the scanning capability before the assessment rather than relying on a POA&M. Confirm the current status of CMMC phases and assessment requirements with the Department of War and your contracting officer, since the program schedule has been changing.

How often must the contractor scan, and who sets the interval?

The contractor sets the scan frequency. Under 32 CFR 170.14(d), where a CMMC requirement uses the word periodically, the contractor defines the interval, but it may be no longer than one year. The frequency must be written down, justified against the organization's risk, and followed in practice, because the first assessment objective for 3.14.5 requires defining the frequency and the second requires scanning at that frequency. Real-time scanning of external files is separate and runs continuously as files are downloaded, opened or executed. Record the chosen interval in the system security plan and keep logs that show each scan ran on time.

Which open-source tools help produce SI.L2-3.14.5 evidence?

Several open-source projects can produce evidence for this requirement, and each covers a different part of it. osquery exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables, and its osqueryd daemon can schedule queries across a fleet of hosts. Velociraptor collects forensic artifacts from endpoints through hunts that can reach offline machines when they reconnect. Wazuh file integrity monitoring records a baseline of checksums and attributes and alerts on changes in real time or on a schedule. Bareos Verify jobs compare files with previously cataloged attributes. Tool choice does not replace the malicious code protection mechanisms themselves, so confirm with the assessor which mechanisms they expect to see for the file scanning objective.

What should be asked in a quote for SI.L2-3.14.5 work?

Ask for a written scope that lists the systems and endpoints covered, the scanning and monitoring tools to be deployed, and the file sources that will be scanned in real time. Request a deliverables list that includes configuration documentation, scan schedules, the defined scan frequency, sample scan and alert records, and a runbook for handling detections. Ask which parts are one-time (deployment, configuration, documentation) and which recur (tool maintenance, signature or rule updates, staff review time, retesting). Confirm who performs each task, what the client must provide, and how changes to scope are priced. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen scopes and prepares SI.L2-3.14.5 scanning evidence

DeployOpen plans, implements and documents self-hosted open-source scanning and monitoring inside your own infrastructure so that SI.L2-3.14.5 has evidence an assessor can test. Your organization owns the requirement and its decisions, and an independent assessor makes the final determination.

How we scope

We agree in writing which systems, endpoints and file sources fall inside the CUI boundary for SI.L2-3.14.5.
The written scope sets the periodic scan interval you define, which may be no longer than one year.
Engagements are fixed-scope, and ongoing support is available as a retainer after handover.

How we build

We deploy osquery to run scheduled malicious code and process queries across the in-scope host fleet.
We configure real-time scanning of files from external sources as they are downloaded, opened or executed.
We test the scanning pipeline with controlled samples so that detections and alert records are shown to work.

How we hand over

We document the scan schedule, tool configuration, scope and the owner for each scan job in a system record.
We deliver sample scan results, detection records and records of actions taken, mapped to the SP 800-171A objectives.
We confirm with your assessor which evidence they expect in final form, since drafts do not count toward a MET result.

How we support

We can keep signature and scanner updates, scan jobs and evidence exports running under a retainer.
We can review scan results and detection records each cycle to confirm the schedule is being followed.
We can retest scanning after system changes so that the evidence still matches the documented configuration.