CMMC Level 2 Practice 3.7.1: Perform maintenance on organizational systems.26

CMMC Level 2 Practice 3.7.1 requires you to perform maintenance on organizational systems in a controlled, documented way so assessors can verify the work was authorized, performed by appropriate personnel, and did not create security gaps. To operationalize it fast, define what “maintenance” includes, require tickets and approvals, control tools and access, and retain maintenance records as recurring evidence. ¹

Key takeaways:

• Treat maintenance as a controlled change: ticket, authorization, execution, validation, and closeout. ²
• Maintenance is an assessment-evidence control; missing records is a common failure mode for 3.7.1. ³
• Include third-party maintenance in scope with access controls, logging, and contracts that support evidence retention. ²

“Maintenance” is one of those words that feels obvious until an assessor asks you to prove it is governed, repeatable, and secure. Under CMMC Level 2, Practice 3.7.1 (mapped to NIST SP 800-171 Rev. 2 3.7.1) expects you to perform maintenance on organizational systems, but your pass/fail outcome often hinges on whether you can show consistent operational control and records, not whether you did a one-off patch or hardware repair. ⁴

For a CCO or GRC lead, the fastest path is to (1) define maintenance events, (2) route every event through a work management mechanism (ticketing/CMDB/change workflow), (3) constrain who can do maintenance and how they connect, and (4) capture evidence that ties the maintenance action to authorization and outcome. This requirement touches IT operations, security operations, and any third party that performs break-fix, managed services, OEM support, or remote administration. ²

This page gives requirement-level implementation guidance for the target keyword: cmmc level 2 practice 3.7.1: perform maintenance on organizational systems.26 requirement. ²

Requirement: CMMC Level 2 Practice 3.7.1 (Maintenance)

## Regulatory text

Regulatory excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.7.1 (Perform maintenance on organizational systems.26).” ¹

Operator translation (what you must do):

• You must conduct system maintenance (routine, corrective, preventative) under defined controls so maintenance does not bypass security requirements or introduce unmanaged changes. ²
• You must be able to demonstrate, with records, that maintenance happens through an approved process and is attributable to authorized personnel and approved methods/tools. ³

Plain-English interpretation

You need a maintenance program that answers five assessor questions without scrambling:

1. What counts as maintenance?
2. Who is allowed to perform it?
3. How is it authorized and tracked?
4. What tools and access paths are permitted (especially remote)?
5. What evidence proves it happened and was completed safely? ²

If you already run change management, treat maintenance as a subset of change where “emergency” and “break-fix” are still controlled and recorded.

---

Who it applies to

In-scope entities

• Defense contractors and federal contractors that handle CUI and need CMMC Level 2 alignment. ⁵

In-scope systems and environments

• Endpoints, servers, network devices, security appliances, OT/IoT where present, cloud workloads, and management planes used to administer systems that store/process/transmit CUI. ²

In-scope personnel and third parties

• Internal IT administrators, SecOps engineers, and helpdesk staff performing break-fix.
• Third parties performing managed services, OEM support, warranty repair, remote troubleshooting, or on-site maintenance. Your process must still govern their access and your evidence must still exist. ²

---

What you actually need to do (step-by-step)

1) Define “maintenance” and scope it to assets

Create a short maintenance standard that includes:

• Maintenance event types: preventive (scheduled servicing), corrective (break-fix), adaptive (configuration to support new requirements), emergency (outage/security incident response fix).
• Assets covered: link to your asset inventory/CMDB categories and explicitly include network gear and security tooling.
• Security baseline expectation: maintenance must not disable logging, weaken configurations, or introduce unapproved software. ²

Practical tip: If teams argue whether patching is “maintenance,” define it as maintenance and route it through the same tracking mechanism to avoid evidence gaps. ²

2) Require a ticket (or work order) for every maintenance event

Minimum ticket fields to standardize:

• Asset identifier (hostname/serial/cloud resource ID)
• Requestor and approver
• Reason/category (routine/corrective/emergency)
• Planned actions (what will change)
• Maintenance window (if planned)
• Tools and access method (VPN/jump host/console)
• Validation steps and results
• Rollback plan (as applicable)
• Attachments: logs, screenshots, vendor work summary (if third party) ⁶

Emergency maintenance rule: allow expedited approval, but require after-the-fact documentation and manager/security review.

3) Implement authorization gates (who can approve and who can perform)

Operationalize with a simple RACI:

• Approver: system owner or IT manager; include security approval for high-risk systems or privileged-path changes.
• Performer: authorized admins only (named roles, not “IT”).
• Reviewer (spot checks): security or GRC verifies tickets are complete and evidence exists. ⁴

Tie authorization to access:

• Privileged access should be role-based and time-bounded where feasible.
• Maintenance access paths should be standardized (jump host, bastion, management VLAN, VPN). ²

4) Control tools, media, and remote maintenance pathways

Even if 3.7.1 is short, assessors will probe how you prevent “maintenance” from becoming an unmonitored backdoor. Put guardrails around:

• Approved toolset: remote management tools, patch tools, scripting frameworks, firmware tools.
• Remote access constraints: require corporate-managed endpoints, MFA where possible, and logging for remote sessions.
• Portable media (if used): only approved, scanned, and tracked media for firmware updates or offline maintenance packages. ²

For third parties:

• Document how third-party personnel are authenticated, how sessions are monitored/logged, and how access is removed after work completes. ²

5) Validate and close out maintenance

Define “done”:

• Post-maintenance verification (service health, baseline configs, security agent running, logging intact).
• Update asset records and configurations if something changed.
• Close ticket with evidence attached and a brief outcome statement. ³

6) Add recurring evidence capture and review (assessment readiness)

Build a lightweight monthly/quarterly control operation:

• Pull a sample of closed maintenance tickets across asset classes.
• Check for approval, performer identity, evidence, and validation.
• Track findings and remediation actions. ³

Daydream fit (earned mention):

• If your problem is consistency and evidence packaging, Daydream can map 3.7.1 to a repeatable control narrative and automate recurring evidence requests from IT and third parties so you are not rebuilding a binder right before assessment. ³

---

Required evidence and artifacts to retain

Aim for “ticket-to-proof” traceability.

Core artifacts

• Maintenance policy/standard (definitions, scope, roles, approval model). ²
• Maintenance procedures/runbooks (patching, firmware upgrades, break-fix, emergency changes). ²
• Completed maintenance tickets/work orders with approvals and closure notes. ³
• Access logs for administrative sessions used during maintenance (jump host logs, VPN logs, remote tool logs). ²
• Evidence of post-maintenance validation (monitoring alerts resolved, service checks, configuration snapshots). ²

Third-party specific artifacts

• Contract language or SOW terms requiring controlled access, logging cooperation, and delivery of maintenance summaries.
• Third-party maintenance reports tied to your internal ticket ID. ²

---

Common exam/audit questions and hangups

Assessors typically ask:

• “Show me your maintenance process and a few recent examples for servers, endpoints, and network devices.” ³
• “How do you ensure only authorized personnel perform maintenance?” ²
• “How do you control and log remote maintenance?” ²
• “What happens during emergency maintenance? Show documentation.” ²

Hangups that create findings:

• Work performed via chat/phone with no ticket.
• Tickets exist but lack approval, lack validation, or do not name the performer.
• Third-party work has an invoice but no record of access method, timing, or actions taken. ³

---

Frequent implementation mistakes (and how to avoid them)

1. Treating maintenance as “ops” outside compliance.
   Fix: mandate a ticket for every maintenance event and make it the single system of record. ³

2. No clear definition of maintenance vs. change vs. incident.
   Fix: define categories and map each to the required minimum fields and approvals. ²

3. Third-party maintenance is unmanaged.
   Fix: require third-party work to be initiated and tracked through your ticketing, with controlled access and session logging. ²

4. Evidence is scattered.
   Fix: standardize ticket templates and require attachments; use Daydream to maintain a consistent evidence register for 3.7.1 across cycles. ³

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat risk through the CMMC assessment lens: failure on 3.7.1 commonly shows up as inability to produce maintenance records and authorization evidence. That can delay certification timelines and create contractual friction where CMMC Level 2 is a prerequisite for award. ⁷

Operational risk is straightforward: uncontrolled maintenance is a common pathway for misconfiguration, weakened security controls, and untracked privileged access. Your process reduces the chance that “helpful break-fix” becomes a security incident. ²

---

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish a one-page maintenance standard: definitions, scope, required ticketing, emergency rules, third-party expectations. ²
• Identify maintenance-capable roles and create an authorized maintainer list (job roles + named groups in IAM). ²
• Configure a maintenance ticket template with required fields and approvals. ³

Next 60 days (implement controls and evidence flow)

• Route all maintenance through the ticketing workflow; train helpdesk/admins on “no ticket, no maintenance.” ³
• Standardize remote maintenance paths (jump host/VPN) and confirm logging exists and is retained. ²
• Update third-party SOWs and access procedures so external maintenance produces an auditable record tied to your ticket. ²

By 90 days (prove operation and readiness)

• Run an internal sample review of maintenance tickets and document results and remediation actions. ³
• Build your 3.7.1 assessment packet: policy, procedure, sample tickets, logs, third-party examples. ³
• In Daydream, map 3.7.1 to your control narrative and schedule recurring evidence pulls so you stay audit-ready after the first pass. ³

Frequently Asked Questions

Does patching count as “maintenance” for 3.7.1?

Treat patching as maintenance and track it the same way, because it changes system state and often uses privileged access. The safest approach is “ticketed, approved, validated, and closed” for routine patch cycles and emergencies. ²

What evidence is strongest for a CMMC assessor?

A maintenance ticket with approval, named performer, documented actions, and validation results, plus logs showing the administrative session or tool activity. Policies help, but assessors usually want operational records. ⁶

How do we handle emergency break-fix when the business refuses delays?

Allow emergency work with expedited approval, but require documented justification, who performed the work, what changed, and a prompt after-action review in the ticket. The key is that “emergency” does not mean “unrecorded.” ²

Do third-party OEM technicians need to follow our maintenance process?

Yes, in practice you need their work to be governed by your process because the system is yours and the assessment asks how maintenance is performed. Tie third-party activity to your internal ticket, constrain access paths, and retain their work summary. ²

We outsource IT to an MSP. Can we pass 3.7.1 with only the MSP’s records?

You can rely on third-party records, but you still need to show you govern the process and can produce evidence on demand. Make sure contract terms and operations give you access to tickets, approvals, and logs relevant to your CUI environment. ⁴

What’s the fastest way to close the “missing evidence” gap for 3.7.1?

Standardize a maintenance ticket template, enforce required fields, and run a recurring evidence capture routine so records don’t drift. Daydream helps by mapping 3.7.1 to the exact artifacts you need and prompting owners for fresh samples each cycle. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

5. 32 CFR Part 170; DoD CMMC Program Guidance

6. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

7. DoD CMMC Program Guidance; 32 CFR Part 170