CMMC 2.0 Level 2 does not prescribe a fixed retention period for MA.L2-3.7.4 scan records, but a practical, defensible answer to how long to keep malware scan logs for cmmc audit is at least 12 months of searchable evidence, with longer archive retention if your company policy, contracts, or incident-response requirements require it. The important point is not a magic number: an assessor must be able to verify that media containing diagnostic or test programs were scanned for malicious code before use on systems that process, store, or transmit CUI. Retain the scan result, the date and time, the file or media identifier, the scanning tool and signature status, the approval or disposition decision, and enough context to connect the record to the actual troubleshooting or maintenance event.
For a compliance officer preparing a mid-market organization for assessment, treat MA.L2-3.7.4 as an evidence-chain practice rather than an antivirus configuration exercise. The practice extends the malicious-code protections in SI.L2-3.14.2 and SI.L2-3.14.4 to vendor-provided diagnostics, test utilities, bootable media, firmware tools, and similar executable content used during maintenance. Your evidence should show that the organization did not merely have endpoint protection installed; it followed a repeatable pre-use process when diagnostic media entered the environment.
What does an assessor actually check for MA.L2-3.7.4?
An assessor evaluating NIST SP 800-171 Rev. 2 practice MA.L2-3.7.4 generally follows the evidence from policy to procedure to operating records. They are looking for proof that the requirement works in practice, including situations involving vendors, urgent troubleshooting, and removable media.
- A documented procedure: A maintenance, removable-media, or malware-protection procedure that requires personnel to scan diagnostic and test programs before they are installed, executed, or connected to in-scope systems. It should identify who performs the scan, what tool is used, and what happens if the scan fails or produces an alert.
- Representative scan records: Logs, tickets, intake forms, or endpoint security reports showing actual scans of vendor diagnostic executables, ISO files, USB media, firmware packages, or test tools. Each record should be traceable to a specific item and date.
- Tool health evidence: Configuration or console evidence that the malware-protection mechanism was active and current when scans occurred. Examples include Microsoft Defender signature-update status, CrowdStrike Falcon prevention policy, or SentinelOne agent health records.
- Maintenance or support tickets: ServiceNow, Jira Service Management, or similar tickets connecting a diagnostic file or media item to a troubleshooting event, system owner, and technician. This is often what proves the scan happened before use rather than after installation.
- Personnel interviews: Interviews with IT support staff, system administrators, and the compliance owner to confirm that the written process matches normal operations, including how urgent vendor support cases are handled.
A clean policy without operating evidence is weak. Conversely, a collection of antivirus logs without a documented requirement to scan diagnostic media can leave the assessor unable to determine whether the activity was intentional, repeatable, and applicable to the CUI environment.
How long to keep malware scan logs for CMMC audit evidence?
Use a 12-month searchable retention target for MA.L2-3.7.4 evidence unless a stricter internal retention schedule applies. This gives the assessment team enough records to evaluate whether the process has operated consistently across normal maintenance cycles, while keeping the evidence manageable for a mid-market IT team. Archive records beyond 12 months according to your security-log retention policy, contract obligations, legal hold requirements, and incident-response needs.
Do not retain only raw endpoint logs if they roll over after 30 or 60 days. Raw logs can support the evidence package, but they may not identify the business context of the scan. Preserve an associated ticket, intake form, or approved exception record that identifies the diagnostic tool, vendor source, system involved, scan outcome, and authorization to proceed. That combination is much easier for an assessor to test.
What should your pre-audit evidence map include?
Build a concise evidence map before the assessor requests documents. The map should identify the source of truth, the storage location, and the accountable owner for every artifact. Avoid assigning all ownership to “IT”; assessors may need to interview the person who administers the tool and the person who approves maintenance activity.
| Evidence tool or artifact | Location and retention setting | Owner |
|---|---|---|
| Microsoft Defender for Endpoint scan history and device timeline | Microsoft Defender portal; advanced hunting export retained in the CMMC evidence SharePoint library for 12 months | Security Operations Manager |
| ServiceNow maintenance and vendor-support tickets | ServiceNow; ticket records retained for 24 months, with “Diagnostic Media Scan Completed” as a required work-note field | IT Service Delivery Manager |
| Diagnostic media intake and scan attestation form | SharePoint CMMC Evidence Library; MA.L2-3.7.4 folder with quarterly access review and 12-month active retention | Compliance Officer |
| CrowdStrike Falcon sensor policy and signature/version evidence | Falcon console policy export; monthly PDF evidence stored in the Security Operations evidence repository | Endpoint Security Administrator |
| Approved maintenance procedure | Controlled policy repository; procedure version, approval record, and annual review history retained permanently | Director of IT |
| Vendor diagnostic tool hash and source verification record | ServiceNow attachment plus ticket work notes; SHA-256 hash recorded before execution where available | Systems Engineering Lead |
For each sample you present, verify the timeline. The ticket should show when the tool was received, the scan evidence should show when it was scanned, and the maintenance action should occur afterward. If timestamps are in separate systems, document the relevant time zone and ensure clocks are synchronized through your normal system-management controls.
What are the top three MA.L2-3.7.4 gotchas that fail audits?
1. Treating routine endpoint protection as proof that diagnostic media was scanned
Assessors may accept endpoint protection as part of the solution, but it does not automatically prove that a vendor USB drive, downloaded diagnostic executable, or bootable utility was scanned before use. A technician saying, “Defender scans everything automatically,” is not the same as showing a procedure and a traceable record for the diagnostic item.
2. Having logs but no connection to the maintenance event
A generic endpoint scan log may contain a device name and timestamp but no file name, vendor reference, ticket number, or use decision. When evidence cannot tie the scan to a diagnostic or test program, it becomes difficult to demonstrate that MA.L2-3.7.4 was met. Require staff to enter the ticket number in the scan attestation or upload the scan export to the ticket.
3. Allowing emergency support work to bypass the process
Urgent production incidents are where informal workarounds occur. If a vendor instructs a technician to run a utility immediately, staff may download and execute it without recording the scan. Your procedure should allow an expedited path, but it should still require a malware scan before execution and a documented after-action review if the record could not be completed in real time.
What should the 7-day pre-audit countdown look like?
- Day 7: Confirm scope. Identify the systems that process, store, or transmit CUI and the teams that can introduce vendor diagnostics, test utilities, firmware tools, or removable media.
- Day 6: Pull the current MA.L2-3.7.4 procedure, approval history, and related SI.L2-3.14.2 and SI.L2-3.14.4 malware-protection documentation.
- Day 5: Export 12 months of representative maintenance tickets involving vendor troubleshooting, endpoint diagnostics, bootable tools, or hardware test activity.
- Day 4: Match each selected ticket to a scan record, scan attestation, file hash where available, and evidence of the tool’s source.
- Day 3: Validate endpoint security console evidence. Confirm malware definitions, prevention policies, and agent health were current for the sampled systems.
- Day 2: Conduct a gap review. Flag any sample where the scan occurred after use, the ticket lacks identifying detail, or the evidence cannot establish the sequence of events.
- Day 1: Prepare a controlled evidence package and rehearse the walkthrough with the technical owners. Do not create backdated records; document gaps honestly and provide remediation status.
What should you do during the assessor interview?
Lead with the process, then show one or two complete examples. Explain that diagnostic and test programs are treated as potentially malicious code, whether they arrive from a vendor portal, email attachment, removable drive, or support technician. Show the procedure, the endpoint security control, the maintenance ticket, and the scan record in chronological order.
Keep answers specific and avoid overstating automation. If scans are initiated manually for removable media or vendor utilities, say so and explain the required workflow. If an exception occurred, explain the documented compensating action and remediation rather than implying that every event was perfect. Assessors are evaluating whether the organization understands its process, can produce objective evidence, and addresses weaknesses in a disciplined manner.
Before your assessment window opens, assign evidence owners, test your ticket-to-scan-log traceability, and close any gap that prevents you from proving malicious-code checks occurred before diagnostic media was used.
