MA.L2-3.7.1 Perform maintenance: evidence and requirements

What MA.L2-3.7.1 perform maintenance requires of defense contractors

MA.L2-3.7.1 asks for one thing: maintenance is actually performed on organizational systems. The assessment objective in NIST SP 800-171A is equally narrow, so an assessor will not accept a policy that describes maintenance as an intention. They will look for dated work orders, patch records and repair tickets showing that the work happened. The requirement covers four kinds of maintenance: corrective (fixing faults), preventive (reducing the chance of faults), adaptive (changing systems to fit a new environment) and perfective (improving functions or performance). Regular patching of discovered vulnerabilities is the form most assessors expect to see first, because the CMMC Assessment Guide Level 2 names it as a common type of security maintenance.

The stakes are higher than the wording suggests. Under the CMMC Scoring Methodology in 32 CFR 170.24, MA.L2-3.7.1 is worth 3 points, so a NOT MET result lowers the score from the maximum of 110. Because it carries more than 1 point, 32 CFR 170.21(a)(2) does not allow it on a plan of action and milestones. A gap here cannot be carried forward as a planned fix. It has to be closed with evidence before the assessment, which makes it one of the requirements to test early in a readiness review.

Most gaps come from work that happens but is not recorded or owned. Patches are applied by whoever notices a vendor alert, a server is rebuilt during an outage without a ticket, and a network appliance is serviced by a contractor whose visit is only in an email thread. Before you prepare evidence, confirm who is accountable for maintenance on each system class, which scheduling and approval process applies, and where records are kept. A helpdesk or change system such as GLPI, whose Assistance module tracks tickets, problems and changes following ITIL practices, can hold that trail if the team uses it for every maintenance action, including emergency work.

Which systems, teams and vendors fall under maintenance scope

Maintenance scope for MA.L2-3.7.1 follows the CUI boundary, not the org chart. The decisions below determine which assets, people and outside providers must produce maintenance records that an assessor can examine.

CUI systems and their support infrastructure

Start with the systems that store, process or transmit CUI, then include the infrastructure they depend on: directory services, DNS, logging, backup servers and the firewalls at the boundary. Each in-scope component needs a maintenance schedule, a record of work performed and a named owner. Teams often find that a supporting service, such as a patch server or a jump host, was never listed in the system security plan and therefore has no maintenance history to show. Confirm the inventory matches the boundary before you size the maintenance effort.

Endpoints and servers in the boundary

Every workstation, laptop and server that touches CUI is maintained, and each one generates patch and repair records. Scope decisions here drive most of the recurring effort, because volume multiplies the number of records an assessor may sample. Decide early whether remote endpoints count as in scope, and whether personal devices are excluded only when they are fully barred from CUI. Ask your team to show how a single laptop's patch history can be traced from the asset inventory to the ticket.

OT and test equipment with CUI

Operational technology, lab instruments and test rigs can store CUI in configuration files, logs or calibration data. Many are maintained by the equipment vendor and are not patched through the standard IT cycle. Decide whether each device is in the assessment boundary, then document who maintains it, how maintenance is scheduled and what records exist. Specialized assets often need separate handling in the system security plan, so confirm their status with your assessor before work begins.

Internal IT and engineering teams

Staff who patch systems, repair hardware or change configurations are part of the maintenance process, even when they are not labeled as maintainers. List every internal team that performs maintenance on in-scope assets, then confirm each one follows the same scheduling, documentation and review steps. Gaps usually appear where an engineer fixes a problem directly on a server and does not open a ticket. Require that all work, including emergency fixes, leaves a record that someone else reviews.

Managed and cloud service providers

A managed service provider or cloud operator that maintains CUI assets extends your maintenance scope to its own processes. Your contract should state who patches, who approves changes and where records are kept, and you should be able to obtain those records during an assessment. Confirm whether the provider's environment is covered by its own assessment or requires your evidence. Ask each provider to show the maintenance records for the systems it supports, and keep them with your own.

Vendor technicians and remote support

Outside technicians who arrive on site or connect remotely to repair equipment are a separate maintenance risk. Their work falls under MA.L2-3.7.1 as well as the related maintenance requirements for tools, sessions and supervision. Decide in advance which vendors may touch CUI assets, who approves each visit and where the visit is logged. Keep a list of vendor access events so that every repair appears in your maintenance history alongside internal work.

How an assessor tests 3.7.1 under NIST SP 800-171A

This table compares what an assessor does for MA.L2-3.7.1 with the evidence each step expects and the gaps that most often cause a NOT MET result. The single assessment objective is that system maintenance is performed, so the assessor tests both the process and the records that show it ran. Every item must exist as final, approved evidence, because draft records do not count toward a MET finding.

Assessment step	What the assessor does	Evidence requested	Common findings
Scheduling	Reviews how maintenance is planned, including routine work, patch windows and emergency fixes.	Approved maintenance calendar or change schedule, and the procedure that defines it.	Schedule exists only as an informal calendar with no owner or approval.
Performing	Samples completed maintenance events and checks that the work matches what was planned.	Work orders or tickets with dates, technician names, systems affected and outcomes.	Tickets are opened after the work is done, or the records do not name the system changed.
Documenting	Checks that each maintenance action leaves a complete, final record.	Maintenance logs, repair notes and vendor maintenance specifications used for the work.	Records are incomplete, missing the affected asset or the reason for the action.
Reviewing and approving	Tests whether a responsible person reviews and approves maintenance before and after it is performed.	Signed or system-recorded approvals, post-maintenance review notes and change records.	Approvals are verbal, or the approver is the same person who performed the work.
Monitoring	Tests whether maintenance outcomes and repair status are tracked over time.	Trend reports, open maintenance backlog, recurring-issue reviews and evidence of follow-up.	No one tracks overdue or repeated repairs, so the process cannot be shown to work.
Patching and vulnerability fixes	Samples patching records to see whether discovered vulnerabilities are fixed through the maintenance process.	Patch deployment records, vulnerability scan results and the tickets linking them.	Patch logs exist, but no link ties them to the vulnerabilities they were meant to fix.
Equipment removed for off-site work	Checks whether maintenance on removed equipment follows a documented, recorded process.	Sanitization records and the maintenance log entry for the off-site event.	Equipment leaves the site with no record of the maintenance or of its sanitization.

How to implement regular maintenance that passes assessment

This sequence turns maintenance from ad hoc fixes into a documented, repeatable cycle that an assessor can trace from a system inventory through each performed change to a reviewed and closed record. Each step produces an artifact the organization can show as evidence for MA.L2-3.7.1.

Inventory the in-scope systems
Start with the asset inventory for every system inside the CMMC assessment boundary, including servers, endpoints, network devices, cloud workloads and any specialized assets that handle or protect CUI. The system owner confirms each entry, names the maintenance responsibility and records the vendor or manufacturer maintenance documentation that applies. This step is done when the inventory matches the system security plan boundary and an assessor could pick any asset and find its owner, its support status and its maintenance history.
Define maintenance types and cadence
Document the four maintenance types the CMMC Assessment Guide lists: corrective, preventive, adaptive and perfective. For each type, state the triggers, such as a failed component, a scheduled patch window, a change in the operating environment or a feature improvement, and the schedule that applies to each system class. Confirm the cadence with the system owners, since the rule does not set fixed intervals for routine work. The output is a maintenance schedule and procedure that an assessor can compare against the work recorded later.
Set the patching and change process
Define how vulnerabilities discovered through scanning or vendor advisories become patch requests, how each request is tested, and who approves it before it reaches production. Route every planned change through a ticket that records the affected system, the reason, the proposed action, the rollback approach and the approver. The Assistance module of GLPI, which follows ITIL practices, and the helpdesk ticketing in Zammad are two open-source options for this record, though the organization should confirm that the chosen tool fits its change approval workflow. The output is a documented change procedure and a ticket template.
Perform and record the work
The technician carries out the maintenance under the approved ticket and logs the actual work in the same record: date, time, technician, steps taken, any deviations from the plan and the verification performed afterward. Where maintenance is carried out by a vendor or a managed service provider, the organization still owns the record and should require the provider to supply its own log that is attached to the ticket. This step is complete when every change has a closed ticket that matches what was done on the system, not what was planned.
Review and approve completed maintenance
A reviewer who did not perform the work checks each closed ticket against the approved plan and the system's expected state, confirms that verification succeeded and approves the record. SP 800-171A asks for evidence that maintenance is reviewed and approved, so the approval should be visible in the ticket history, not only in a meeting note. Escalate any unapproved or incomplete change to the system owner. The output is an approved ticket for each maintenance event.
Monitor completion and close the cycle
On a regular basis, the owner of the maintenance process compares the schedule with the completed tickets, identifies overdue preventive work and open patch requests, and reports the results to the people accountable for the system security plan. The monthly review sign-off, or the review cadence the organization sets, records that the check happened, what was found and what action was assigned. Feed recurring issues back into the inventory and the schedule. Confirm with the assessor which review cadence and evidence format it expects before the assessment begins.

What maintenance records must show to be accepted

An assessor testing MA.L2-3.7.1 does not accept a statement that maintenance happens. The evidence must show that maintenance was performed on specific systems and that the process around it worked. NIST SP 800-171A lists maintenance records, manufacturer or vendor maintenance specifications and equipment and media sanitization records as potential evidence, and it tests the processes for scheduling, performing, documenting, reviewing, approving and monitoring maintenance and repairs. Each record should therefore link one maintenance event to a system, a date, a performer, a reviewer and an outcome. If any of those five elements is missing, the assessor has to reconstruct the story from other sources, and that rarely ends well.

Routine patching and one-off repairs need different records. Patching is recurring and usually driven by a vulnerability process, so the evidence is a cycle: scan results, the patch decision, the deployment window, the installed version and a verification step. A one-off repair, such as replacing a failed component or correcting a fault after a vendor visit, is an exception event that needs its own ticket with the vendor specification it followed and the post-repair test. An assessor samples both because a clean patch log says nothing about how unplanned work was controlled, and a well-documented repair says nothing about whether systems stay current. Confirm with your assessor which sample sizes and record types they expect, since those are set in the assessment process rather than in the requirement text.

Sanitization records deserve their own entries because equipment leaving for off-site maintenance is where CUI is most likely to escape. Before you rely on any ticketing or asset tool, decide who approves a maintenance event, who signs off on the outcome and how the record proves the reviewer looked at it, not only that a field was filled in. Draft records do not count, so the final, approved version must be retained and the change history must be preserved. Ask your assessor how they want approval shown, whether a ticket state change, a signed form or a system log, and build your records to produce that proof from the start.

Evidence artifacts that satisfy 3.7.1 and how to keep them current

An assessor testing MA.L2-3.7.1 looks for proof that maintenance is scheduled, performed, documented, reviewed and approved, not just a policy that says so. The six artifacts below link together: a schedule sets expectations, tickets and patch logs prove the work happened, and approvals and sanitization records show it was controlled. Keep each one current as a routine task, not a pre-assessment scramble.

Maintenance schedule

The schedule lists planned maintenance for each in-scope system, including patch windows, vendor service intervals and hardware checks. Assessors compare it against tickets to confirm that maintenance happens as planned and that deviations were recorded. Review it at least each quarter and after any change to system ownership or scope. Record every missed window with a reason and a new date, because an unexplained gap reads as an unmanaged process.

Ticket and work order records

Each maintenance action should have a ticket that states the system, the reason (corrective, preventive, adaptive or perfective), the technician, the steps taken and the closure date. Tickets are the most direct proof that maintenance was performed and documented. Helpdesk tools such as GLPI or Zammad can hold this record if they are configured for maintenance categories. Check monthly that no maintenance was done outside the ticketing system.

Patch and vulnerability remediation logs

Patch logs show which vulnerabilities were discovered, which patches were applied, when, and to which systems. The CMMC Assessment Guide names regular patching of discovered vulnerabilities as a common form of security maintenance, so assessors often sample these logs first. Keep the scanner output, the patch decision and the post-patch verification together. Confirm that unapplied patches have a documented reason and an approved exception.

Vendor maintenance specifications

Manufacturer and vendor documents describe the approved maintenance procedures, intervals and tools for each system. SP 800-171A lists these specifications as potential evidence for 3.7.1, and assessors use them to judge whether the work followed supported methods. Store the current version for each asset and note the date it was obtained. When a vendor issues an update, record which systems it affects and when the procedure changed.

Approval and review records

Assessors test whether maintenance is approved before it runs and reviewed after it completes. Approval records show who authorized the change, and review records show that someone checked the outcome. Retain both as signed or system-recorded entries linked to the ticket. Review a sample each month and confirm that no high-impact maintenance lacks approval, since 3.7.1 expects scheduling, performing, documenting, reviewing and approving to work together.

Sanitization records for equipment leaving site

When equipment that held CUI leaves the organization for off-site repair, a sanitization record shows the method used, who performed it, the device identifier and the verification step. These records support 3.7.1 and the related sanitization requirement in the MA family. Keep one record per device and file it with the work order that sent it out. Confirm that every device returned from vendor repair has a matching sanitization or inspection entry before reconnecting it.

What meeting 3.7.1 costs in tooling, staff time and assessment

This table breaks down what meeting MA.L2-3.7.1 costs by component, showing who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to structure a written scope request, since no price is published here and every figure depends on your environment. The main takeaway is that the largest recurring cost is usually staff time for scheduled and emergency maintenance, not the ticketing tool itself.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Ticketing or helpdesk tooling	Software vendor or open-source support provider if you buy support	Recurring if licensed; open-source options such as GLPI and Zammad carry no license fee but still need hosting and administration	Number of users, integrations and whether you need hosted or self-hosted deployment; self-hosting removes license spend but adds server and upkeep time
Maintenance planning and scheduled work	Internal IT and engineering staff	Recurring	Number of systems in scope, patch cadence and how many changes need pre-approval and rollback plans
Emergency and corrective maintenance	Internal on-call staff, sometimes external responders	Recurring and unpredictable	Age of systems, vulnerability volume and how well preventive maintenance is kept current
Patch testing and staging	Internal engineers; any test environment hardware or cloud capacity	One-time to build the test environment, recurring to run it	Diversity of platforms, number of custom applications and whether a representative staging environment already exists
Maintenance records and evidence upkeep	Internal compliance or IT staff	Recurring	Level of automation in the ticketing system and how consistently tickets are closed with approvals and outcomes
Internal or external review of maintenance records	Internal reviewers or an outside consultant you hire for readiness	Recurring for periodic review, one-time for initial gap review	Scope of the review, number of sites and whether an outside party is used; ask for a written scope-based quote
Assessor sampling and assessment fees	Certified third-party assessor (C3PAO) for Level 2 certification, or your own self-assessment team	Recurring per assessment cycle	Scope of the assessed environment and assessor sampling depth. Confirm current assessment timing with the DoW CIO page before budgeting

Open-source ticketing tools that can hold maintenance evidence

GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices. For MA.L2-3.7.1, the useful part is the change record: each planned or unplanned maintenance action can be logged with its request, approval, implementation notes and closure, which gives an assessor a dated trail. The module also offers plannings, statistics, recurrent tickets and a Kanban view, so recurring patch cycles can be scheduled and reviewed rather than handled ad hoc.

Change records: Create a change for each maintenance action, capturing the reason, the affected system and the person who approved it.
Problem linkage: Tie repeated failures to a problem record so corrective maintenance traces back to its cause.
Recurring work: Use recurrent tickets for scheduled patch windows so each cycle leaves its own record.
Reporting: Use statistics to show how many maintenance changes were opened, closed and overdue over a review period.
License: GLPI is licensed under GPL-3.0-or-later. Confirm with counsel what obligations apply if you modify and distribute the software.

Confirm that the module's approval steps, retention settings and access controls meet your own record-keeping policy before relying on it as evidence.

Where maintenance evidence usually fails and how to close each gap

Maintenance evidence fails less often because the work is missing than because the paper trail around it is incomplete. The gaps below cluster around records, approvals, emergency changes, vendor documentation and draft status, and each one can be closed with a process change and a ticket or log that the assessor can follow from start to finish.

Maintenance performed but not recorded

Engineers patch servers, replace drives and adjust firmware, then never write down what changed. SP 800-171A asks whether maintenance is performed, so an assessor looks for proof of each action, not a general statement that patching happens. Require a ticket for every maintenance action on in-scope systems, with the system name, date, performer, what was done and the result. Check a sample of changes in the change log against the ticket queue to find work that was done but never recorded.

Patch records without approval

A patch log shows that updates were installed, but not who authorized them, when they were tested or whether a rollback plan existed. Assessors reviewing maintenance expect evidence that maintenance is scheduled, approved and reviewed, not only executed. Link each patch record to an approval step, a test result and a window in the maintenance calendar. Confirm that the approver is someone other than the person who performed the work where your process allows it.

Emergency work with no ticket

Outages, active exploitation and urgent vendor fixes often bypass the normal queue, and the ticket gets created days later or never. Retroactive records are weaker than contemporaneous ones, and they are easy for assessors to question. Define an emergency maintenance path that still opens a ticket at the start, records the justification, and requires a post-action review within a set period that your policy defines. Ask the team to show you its last emergency change and the ticket that covers it.

Vendor maintenance specifications missing

Teams often follow a vendor procedure from memory or from a forum post, and the official maintenance specification is never filed with the system's documentation. SP 800-171A lists manufacturer or vendor maintenance specifications as potential evidence for 3.7.1. Store the current vendor guidance for each in-scope platform in the configuration record, note the version it applies to, and reference it in the ticket for each maintenance action. Confirm that the stored version matches what is installed.

Draft procedures presented as final

A maintenance policy or procedure marked draft, or a runbook edited last week without a version control record, will not satisfy an assessor. A requirement is met only when the evidence is in final form, so a draft cannot support an otherwise compliant process. Keep maintenance procedures under version control with an owner, an approval date and a revision history. Before an assessment, confirm that every document you plan to show has a final status and that the version in use is the one that was approved.

Questions buyers ask about maintenance evidence and effort

How much effort does MA.L2-3.7.1 take to meet?

Effort depends on how many systems handle CUI and how much of their maintenance is already planned, performed and recorded. No effort figure is supplied for this requirement, so ask for an estimate tied to your environment rather than a generic number. The main drivers are:

The number and type of in-scope systems, including servers, endpoints, network devices, cloud workloads and any operational technology or test equipment
Whether maintenance is scheduled and logged in a ticketing or change system today, or only remembered
The volume of patches, emergency fixes and planned changes each month
How many vendors and maintenance contracts need their specifications collected and reviewed

Most of the effort is process and documentation work, so an organization with mature change records typically has less to build.

Can an organization meet MA.L2-3.7.1 with in-house staff?

Yes. The organization owns its controls, so its own administrators and managers can schedule, perform, document and approve maintenance without outside help. Outside help is optional and usually covers preparing systems, building the maintenance process, configuring records and collecting evidence. Independent assessors are different. Under the CMMC rule, Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and an implementation partner cannot issue or substitute for that assessment. Self-assessments remain available during Phase I, and the assessment path that applies to your contracts should be confirmed with the contracting officer or your DoD prime.

What does an implementation partner need from us for 3.7.1?

A partner needs enough access and information to see how maintenance really happens, not only how it is written down. Typical inputs are:

A current inventory of in-scope systems and the boundary of the CUI environment
Existing maintenance procedures, change calendars, patch policies and recent tickets
Vendor maintenance specifications, support contracts and remote access arrangements
Sanitization and disposal records for equipment that leaves the site
Named owners who can approve maintenance and confirm what was done

Your organization should also confirm which tools hold the records, who can export them and how long they are retained. The scope and deliverables should be written down before work starts, so both sides know what evidence will be produced.

Does regular patching alone satisfy MA.L2-3.7.1?

No. Regular patching is a common form of security maintenance, and the CMMC Assessment Guide names it as one example. MA.L2-3.7.1 covers maintenance more broadly, including corrective, preventive, adaptive and perfective work on organizational systems. An assessor will also test whether the processes for scheduling, performing, documenting, reviewing, approving and monitoring maintenance operate as described. A patch log with no approval trail, no review step and no link to the affected systems will usually leave the requirement open. Patching is a strong starting point, but the records around it carry most of the weight.

Can MA.L2-3.7.1 be placed on a POA&M?

No. MA.L2-3.7.1 is a 3-point requirement under the CMMC Scoring Methodology. If it is not met, its 3 points are subtracted from the maximum score of 110. Because it is worth more than 1 point, 32 CFR 170.21(a)(2) does not allow it on a plan of action and milestones, so it must be fully MET to reach Conditional or Final Level 2 status. Plan any remediation before the assessment, and confirm the current scoring and POA&M rules against the eCFR text, since the rule and the scoring methodology are the sources that govern the outcome.

How does the Phase II suspension affect maintenance work?

The suspension changes timing, not the requirement. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and MA.L2-3.7.1 still applies to any system that handles CUI. The eCFR text of 32 CFR 170.3(e) still lists the original four-phase schedule, so check the DoW CIO page for the current position before setting contract deadlines.

What evidence will an assessor ask for under MA.L2-3.7.1?

An assessor looks for maintenance records, manufacturer or vendor maintenance specifications, and equipment and media sanitization records, along with evidence that the maintenance process runs as described. Each item should be in final form, since drafts do not count toward MET. Ticketing tools can produce much of this record. GLPI's Assistance module, for example, supports tickets, problems and changes following ITIL practices, with plannings and statistics, and GLPI's Assistance documentation describes how those records are created and followed. Zammad can capture maintenance requests that arrive by email. Confirm with your assessor which records they will accept.

How DeployOpen prepares maintenance evidence for 3.7.1

DeployOpen plans, implements and documents self-hosted maintenance workflows inside the client's own environment, so that the records an assessor asks for are produced as a side effect of doing the work. In practice this means configuring a self-hosted ticketing platform such as GLPI, whose Assistance module supports tickets, problems and changes following ITIL practices, so that each maintenance action has a request, an approver, a scheduled window, a record of what was done and a review. The client decides the workflow rules, approval roles and retention periods. DeployOpen configures the platform to enforce them and documents how the process runs.

Much of the evidence for 3.7.1 comes from the patching and maintenance pipeline itself. DeployOpen can help define how vulnerability findings flow into scheduled patch work, how maintenance tickets link to the affected systems and change records, and how vendor maintenance specifications and sanitization records are stored alongside them. Any tooling choice should be confirmed against the client's own systems, and the client should check that the platform can produce the reports its assessor will request. Records must also be in final form, not drafts, to count toward a MET determination.

DeployOpen works under fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Retainers are available for ongoing support, upgrades and continuous testing once the workflow is live. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue assessment reports or certifications. Only an independent assessor, such as a C3PAO for Level 2 certification assessments, can do that. The client owns its controls, its maintenance decisions and its SPRS submissions, and it should confirm the current assessment requirements with the DoW CIO before scoping work.

MA.L2-3.7.1 Perform maintenance