{
  "title": "How to Perform Maintenance on Organizational Systems to Meet NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - MA.L2-3.7.1: A Step-by-Step Implementation Guide",
  "date": "2026-04-18",
  "author": "Lakeridge Technologies",
  "featured_image": "/assets/images/blog/2026/4/how-to-perform-maintenance-on-organizational-systems-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-mal2-371-a-step-by-step-implementation-guide.jpg",
  "content": {
    "full_html": "<p>Performing maintenance on organizational systems in a way that satisfies NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 MA.L2-3.7.1 requires more than installing patches — it requires a documented, auditable, and risk-managed maintenance process that protects Controlled Unclassified Information (CUI) and demonstrates control over who, how, and when systems are serviced.</p>\n\n<h2>Overview of MA.L2-3.7.1 and what compliance expects</h2>\n<p>MA.L2-3.7.1 obligates organizations to perform maintenance on organizational systems while controlling maintenance activity and preserving system security and integrity. For a compliance assessment you must show policies and procedures, authorized maintenance personnel (including third parties), approved tools and access methods, protected remote sessions, and records that prove maintenance events were planned, tested, executed, and verified.</p>\n\n<h2>Step-by-step implementation guide</h2>\n\n<h3>Step 1 — Inventory, classification, and scope the maintenance program</h3>\n<p>Begin by inventorying all systems that store, process, or transmit CUI/FCI and classify them by criticality and maintenance risk. Maintain a Configuration Management Database (CMDB) or asset register that includes device hostname, owner, purpose, OS/firmware version, location, and maintenance contact. Tag assets in the CMDB with attributes like \"production/staging\", \"contains CUI\", and maintenance window groups (e.g., ring-0: high criticality, ring-1: low criticality). This scope controls what maintenance procedures and approval levels apply.</p>\n\n<h3>Step 2 — Documented maintenance policy, procedures, and change control</h3>\n<p>Create a maintenance policy that defines who may approve work, required approvals for different asset classes, required pre-maintenance backups, test/staging requirements, rollback plans, and notification procedures. Integrate maintenance with your change control process (ticketing system such as Jira, ServiceNow, or Freshservice) so every maintenance action has a request, approval, implementation, and closure record. Require pre-change risk assessment and post-change verification steps in every ticket.</p>\n\n<h3>Step 3 — Secure remote maintenance and access controls</h3>\n<p>When maintenance is remote, require secure access methods: VPN to a hardened bastion/jump host, MFA for remote access, and use of Privileged Access Management (PAM) tools or just-in-time (JIT) elevation (e.g., Azure PIM, BeyondTrust, CyberArk). Disable or avoid unmanaged remote tools like consumer TeamViewer unless configured through your PAM and recorded. Use SSH keys with short lifetimes or ephemeral credentials, and enforce least privilege for maintenance accounts. For network device firmware updates, use an out-of-band management network or serial console via a secure console server rather than exposing device management to the internet.</p>\n\n<h3>Step 4 — Tools, testing, logging, and verification</h3>\n<p>Maintain an approved-tools list (e.g., WSUS/SCCM/Intune for Windows, Jamf for macOS, Ansible for Linux/configuration, RMM tools configured to audit) and require checksum verification (SHA256) for firmware and critical software. Test patches in a staging ring before production: use ring deployments (e.g., SCCM/Intune rings) for phased rollouts. Log all maintenance activity centrally: forward syslog/TLS to a SIEM (Splunk, Elastic, or cloud alternatives) and record remote sessions (screen capture and command logs). After maintenance, run automated verification: configuration drift checks (e.g., OpenSCAP, osquery), vulnerability scans, and application smoke tests, and attach evidence to the change ticket.</p>\n\n<h2>Real-world small-business examples and scenarios</h2>\n<p>Example 1 — A 50-person engineering firm with CUI: They use Microsoft Intune and a lightweight CMDB in a shared Confluence page. Implementation: create a maintenance calendar for production servers, use Intune ring deployments to stage Windows updates (pilot 10% → 50% → all), require backup snapshots in Azure before major changes, and log changes in Freshservice. Remote vendor support is only allowed through a VPN-provisioned jump host and PAM session that records activity. Example 2 — A small MSP-managed shop: The MSP signs a support addendum obligating them to follow the client's maintenance policy; remote maintenance requires a time-bound service account, prior approval ticket, and delivery of post-maintenance logs to the client for retention.</p>\n\n<h2>Compliance tips and best practices</h2>\n<p>Map artifacts to the control: maintenance policies, CMDB exports, change tickets with approvals, backups, pre/post screenshots or test logs, session recordings, and SIEM entries are your audit evidence. Use automation to reduce human error: Ansible/Chef playbooks for standardized maintenance, scripts that perform pre-check, patch, post-check, and upload results to the ticket. Maintain retention of maintenance records per your records-retention policy (recommendation: keep detailed maintenance logs and session recordings for at least 12 months; adjust for contractual obligations). Train staff and vendors on maintenance procedures and require background checks and authorized-user lists for those permitted to perform maintenance on CUI-handling systems.</p>\n\n<h2>Risk of not implementing MA.L2-3.7.1 correctly</h2>\n<p>Failing to control and document maintenance increases the risk of unauthorized access, untested patches causing outages, unnoticed configuration drift, and firmware/patch tampering. For organizations handling CUI, this can lead to data exposure, failed government audits, termination of contracts, or financial and reputational harm. A lack of audit evidence is a common reason small businesses fail CMMC readiness assessments even when they \"do the work\" informally.</p>\n\n<p>Summary: Implement MA.L2-3.7.1 by scoping assets, documenting policy and change-control workflows, enforcing strong remote-access controls and PAM, using approved and tested tools, and keeping centralized, auditable logs and artifacts. For small businesses, start small (inventory + one maintenance calendar + enforced ticket approvals + recorded remote sessions) and expand automation and tooling as maturity grows — these concrete steps provide both immediate risk reduction and the artifacts needed to demonstrate compliance.</p>",
    "plain_text": "Performing maintenance on organizational systems in a way that satisfies NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 MA.L2-3.7.1 requires more than installing patches — it requires a documented, auditable, and risk-managed maintenance process that protects Controlled Unclassified Information (CUI) and demonstrates control over who, how, and when systems are serviced.\n\nOverview of MA.L2-3.7.1 and what compliance expects\nMA.L2-3.7.1 obligates organizations to perform maintenance on organizational systems while controlling maintenance activity and preserving system security and integrity. For a compliance assessment you must show policies and procedures, authorized maintenance personnel (including third parties), approved tools and access methods, protected remote sessions, and records that prove maintenance events were planned, tested, executed, and verified.\n\nStep-by-step implementation guide\n\nStep 1 — Inventory, classification, and scope the maintenance program\nBegin by inventorying all systems that store, process, or transmit CUI/FCI and classify them by criticality and maintenance risk. Maintain a Configuration Management Database (CMDB) or asset register that includes device hostname, owner, purpose, OS/firmware version, location, and maintenance contact. Tag assets in the CMDB with attributes like \"production/staging\", \"contains CUI\", and maintenance window groups (e.g., ring-0: high criticality, ring-1: low criticality). This scope controls what maintenance procedures and approval levels apply.\n\nStep 2 — Documented maintenance policy, procedures, and change control\nCreate a maintenance policy that defines who may approve work, required approvals for different asset classes, required pre-maintenance backups, test/staging requirements, rollback plans, and notification procedures. Integrate maintenance with your change control process (ticketing system such as Jira, ServiceNow, or Freshservice) so every maintenance action has a request, approval, implementation, and closure record. Require pre-change risk assessment and post-change verification steps in every ticket.\n\nStep 3 — Secure remote maintenance and access controls\nWhen maintenance is remote, require secure access methods: VPN to a hardened bastion/jump host, MFA for remote access, and use of Privileged Access Management (PAM) tools or just-in-time (JIT) elevation (e.g., Azure PIM, BeyondTrust, CyberArk). Disable or avoid unmanaged remote tools like consumer TeamViewer unless configured through your PAM and recorded. Use SSH keys with short lifetimes or ephemeral credentials, and enforce least privilege for maintenance accounts. For network device firmware updates, use an out-of-band management network or serial console via a secure console server rather than exposing device management to the internet.\n\nStep 4 — Tools, testing, logging, and verification\nMaintain an approved-tools list (e.g., WSUS/SCCM/Intune for Windows, Jamf for macOS, Ansible for Linux/configuration, RMM tools configured to audit) and require checksum verification (SHA256) for firmware and critical software. Test patches in a staging ring before production: use ring deployments (e.g., SCCM/Intune rings) for phased rollouts. Log all maintenance activity centrally: forward syslog/TLS to a SIEM (Splunk, Elastic, or cloud alternatives) and record remote sessions (screen capture and command logs). After maintenance, run automated verification: configuration drift checks (e.g., OpenSCAP, osquery), vulnerability scans, and application smoke tests, and attach evidence to the change ticket.\n\nReal-world small-business examples and scenarios\nExample 1 — A 50-person engineering firm with CUI: They use Microsoft Intune and a lightweight CMDB in a shared Confluence page. Implementation: create a maintenance calendar for production servers, use Intune ring deployments to stage Windows updates (pilot 10% → 50% → all), require backup snapshots in Azure before major changes, and log changes in Freshservice. Remote vendor support is only allowed through a VPN-provisioned jump host and PAM session that records activity. Example 2 — A small MSP-managed shop: The MSP signs a support addendum obligating them to follow the client's maintenance policy; remote maintenance requires a time-bound service account, prior approval ticket, and delivery of post-maintenance logs to the client for retention.\n\nCompliance tips and best practices\nMap artifacts to the control: maintenance policies, CMDB exports, change tickets with approvals, backups, pre/post screenshots or test logs, session recordings, and SIEM entries are your audit evidence. Use automation to reduce human error: Ansible/Chef playbooks for standardized maintenance, scripts that perform pre-check, patch, post-check, and upload results to the ticket. Maintain retention of maintenance records per your records-retention policy (recommendation: keep detailed maintenance logs and session recordings for at least 12 months; adjust for contractual obligations). Train staff and vendors on maintenance procedures and require background checks and authorized-user lists for those permitted to perform maintenance on CUI-handling systems.\n\nRisk of not implementing MA.L2-3.7.1 correctly\nFailing to control and document maintenance increases the risk of unauthorized access, untested patches causing outages, unnoticed configuration drift, and firmware/patch tampering. For organizations handling CUI, this can lead to data exposure, failed government audits, termination of contracts, or financial and reputational harm. A lack of audit evidence is a common reason small businesses fail CMMC readiness assessments even when they \"do the work\" informally.\n\nSummary: Implement MA.L2-3.7.1 by scoping assets, documenting policy and change-control workflows, enforcing strong remote-access controls and PAM, using approved and tested tools, and keeping centralized, auditable logs and artifacts. For small businesses, start small (inventory + one maintenance calendar + enforced ticket approvals + recorded remote sessions) and expand automation and tooling as maturity grows — these concrete steps provide both immediate risk reduction and the artifacts needed to demonstrate compliance."
  },
  "metadata": {
    "description": "Practical, step-by-step guidance for small organizations to implement MA.L2-3.7.1 (Perform maintenance on organizational systems) to meet NIST SP 800-171 Rev.2 and CMMC 2.0 Level 2 requirements.",
    "permalink": "/how-to-perform-maintenance-on-organizational-systems-to-meet-nist-sp-800-171-rev2-cmmc-20-level-2-control-mal2-371-a-step-by-step-implementation-guide.json",
    "categories": [],
    "tags": []
  }
}