MA.L2-3.7.1 requires organizations to perform maintenance on their systems in a controlled, documented way; auditors will expect a clear trail showing what maintenance was planned, who authorized and performed it, how it was executed, and how the system was validated and returned to service—especially for systems that process, store, or transmit CUI under the Compliance Framework.
What auditors are verifying under MA.L2-3.7.1
Auditors interpret MA.L2-3.7.1 as evidence that maintenance is performed deliberately and consistently, not ad-hoc. They want proof that maintenance activities (patching, firmware upgrades, hardware replacement, preventive maintenance) are scheduled, authorized, logged, and verified. For CMMC/NIST, the scope centers on organizational systems that handle Controlled Unclassified Information (CUI), so evidence must show controls applied to those assets specifically.
Core evidence items auditors expect
Policies, procedures, and role assignments
Provide an up-to-date maintenance policy or SOP that defines maintenance types (routine, emergency, vendor), roles (maintenance technician, approver, system owner), and authorization requirements. Auditors will look for a documented maintenance procedure that maps responsibilities and references the systems in your asset inventory/CMDB. Small-business practical step: create a one-page maintenance SOP for each system class (servers, network devices, endpoints) and store it in your secure document repository.
Maintenance schedules and approvals
Auditors expect a schedule or calendar showing planned maintenance windows and evidence of pre-approval for each activity. Evidence can be calendar invites, change management tickets with approval fields populated, or signed emails. Implementation detail: use your ticketing/change system (e.g., Jira Service Management, ServiceNow, Freshservice) with required fields like "system impacted," "CUI involved," "rollback plan," and "approver signature" to standardize evidence capture.
Work orders, execution logs, and artifacts
Provide work orders or change tickets showing start/end times, technician identity, commands run, and outcome. Technical artifacts are critical: console logs, patch-management job output (SCCM/WSUS/Intune job reports), syslog/journalctl entries, and package manager logs (/var/log/dpkg.log, /var/log/yum.log). For Windows, auditors commonly accept Event Log entries (e.g., service installs such as Event ID 7045, scheduled task creation Event ID 4698) and SCCM deployment reports. Include screenshots or exported CSVs from tools when possible to show timestamps and hashes.
Post-maintenance verification and rollback documentation
Auditors want validation that maintenance didn't break systems and that fallback options exist. Provide test results, monitoring alerts cleared, user acceptance signoffs, and rollback procedures executed when needed. Technical validation can include service health checks, automated smoke test results, successful index of backup restores, or BMC/monitoring graphs showing normal CPU/memory post-maintenance. Keep rollback logs or scripts and show they were tested in staging.
Third-party and remote maintenance controls
When vendors perform maintenance, auditors expect contracts, SOWs, proof of authorization for each session, and session logs. For remote maintenance, provide remote access logs, bastion/jump-host session recordings, MFA evidence, and just-in-time privileged access records. Practical technical setup: require SSH via an isolated bastion host with recorded session, or RDP through gateway with Azure AD conditional access and audit logging enabled. Evidence should show the vendor account used, the time window, and the actions taken.
Small business examples and implementation tips
Example A: A 20-person defense subcontractor uses an MSP for patching. Evidence bundle: the MSP's monthly maintenance report (PDF), the subcontractor's change ticket approving the monthly window, SCCM deployment report for the patch batch, system uptime graphs after the patch, and an email from the MSP confirming completion. Example B: A small software shop performing firmware updates on network gear—evidence includes pre-maintenance backup configs, a signed change ticket that names the devices (matching the CMDB asset IDs), the executed CLI command log (copied from the terminal or captured via automation tool like Ansible), and a post-update config diff proving the change.
Risks of not implementing MA.L2-3.7.1 and best practices
Failure to maintain systems properly exposes you to unpatched vulnerabilities, unexpected outages, data loss, and unauthorized changes—risks that can lead to CUI exposure, contract loss, and failed audits. Best practices: automate patch orchestration and evidence collection where possible (SCCM, Intune, Ansible), centralize logs (SIEM or log aggregator) with immutable storage, enforce change approvals, and establish retention policies (align with contract requirements; many organizations retain maintenance logs 1–3 years). Also perform periodic audits of your maintenance process, and run tabletop exercises for emergency maintenance scenarios.
In summary, convincing auditors you meet MA.L2-3.7.1 requires a consistent, documented pipeline from policy and approvals through execution and verification, with concrete artifacts—tickets, logs, test results, and contracts—mapped back to the systems that handle CUI; small businesses can meet this bar by standardizing SOPs, using ticketing and automation tools to capture evidence, and keeping a central, tamper-resistant repository of maintenance records.
