Controlled Maintenance

Controlled Maintenance (NIST SP 800-53 Rev 5 MA-2) requires you to schedule maintenance, repairs, and replacements for system components, document each activity, and periodically review the resulting records against manufacturer/third-party specifications and your own requirements. Operationalize it by putting maintenance under formal change/asset workflows, enforcing ticket-level evidence, and running regular record reviews to catch gaps. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• You need a scheduled maintenance program tied to assets, not ad hoc “break/fix” work. (NIST Special Publication 800-53 Revision 5)
• Every maintenance event needs durable records: who/what/when/why, approvals, and results. (NIST Special Publication 800-53 Revision 5)
• Examiners will look for review discipline: proof you check maintenance records and correct deviations. (NIST Special Publication 800-53 Revision 5)

Controlled maintenance is one of those requirements that looks simple until an assessor asks for evidence across a mixed environment: cloud services, endpoints, network gear, hypervisors, and the “owned by a third party” components you still rely on. MA-2 forces you to turn maintenance into a governed operational process with three non-negotiables: a schedule, documentation, and review. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path to maturity is to treat maintenance records as audit artifacts produced by engineering workflows you already run: asset inventory, change management, incident/problem management, patch/vulnerability management, and third-party management. You’re not creating paperwork for its own sake; you’re creating a repeatable trail that shows maintenance is planned, performed according to authoritative specifications (manufacturer or third party), and checked after the fact for completeness and exceptions. (NIST Special Publication 800-53 Revision 5)

This page breaks MA-2 into implementable steps, the evidence you must retain, and the exam questions that typically stall teams. It also gives a practical execution plan so you can move from “we do maintenance” to “we can prove controlled maintenance” quickly. (NIST Special Publication 800-53 Revision 5)

Regulatory text

Requirement (excerpt): “Schedule, document, and review records of maintenance, repair, and replacement on system components in accordance with manufacturer or vendor specifications and organizational requirements.” (NIST Special Publication 800-53 Revision 5)

What the operator must do

• Schedule maintenance activities for system components (planned work, not only reactive fixes). (NIST Special Publication 800-53 Revision 5)
• Document each maintenance, repair, or replacement event with enough detail to stand alone as evidence. (NIST Special Publication 800-53 Revision 5)
• Review records on a recurring basis to confirm the work followed manufacturer/third-party specifications and your internal requirements, and to identify gaps or unauthorized maintenance. (NIST Special Publication 800-53 Revision 5)

This is broader than “patching.” MA-2 covers hardware swaps, firmware upgrades, break/fix repair, lifecycle replacements, and maintenance performed by third parties. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what auditors mean by “controlled maintenance”)

Controlled maintenance means:

1. You can name the components in scope (or at least the classes of components) and show how maintenance is planned for them. (NIST Special Publication 800-53 Revision 5)
2. You can produce a record for each maintenance action that ties back to the asset and the change/ticket that authorized it. (NIST Special Publication 800-53 Revision 5)
3. You can show governance after the fact: someone checks the maintenance trail and resolves missing approvals, incomplete records, or deviations from required procedures/specs. (NIST Special Publication 800-53 Revision 5)

If your team says “maintenance happens in Jira/ServiceNow/Git,” the next question is “show me the fields, the approvals, and the review evidence.” MA-2 is won or lost on traceability. (NIST Special Publication 800-53 Revision 5)

Who it applies to (entities and operational context)

Entities

• Cloud Service Providers operating in a FedRAMP Moderate context. (NIST Special Publication 800-53 Revision 5)
• Federal Agencies running or authorizing information systems in the same baseline context. (NIST Special Publication 800-53 Revision 5)

Operational context (where MA-2 bites)

• Production infrastructure (network devices, hosts, hypervisors, storage, HSMs, etc.).
• Endpoints and fleet where component replacement and repair occur.
• Third-party maintained components (colocation, managed network, managed databases) where you still need records or attestations of maintenance performed under contract/SLA. (NIST Special Publication 800-53 Revision 5)
• Emergency/break-glass work that bypasses normal scheduling still needs documentation and later review. (NIST Special Publication 800-53 Revision 5)

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

1) Define scope and map it to your asset inventory

• Identify system component categories in scope (compute, network, storage, security appliances, endpoint classes, critical SaaS dependencies).
• Ensure each in-scope component has an asset record (owner, environment, criticality, location, lifecycle state).
• Decide what “maintenance” includes for each category (examples: fan replacement, RAID rebuild, firmware upgrade, certificate module replacement).
  Output: a scoped maintenance register tied to assets. (NIST Special Publication 800-53 Revision 5)

2) Convert maintenance into a scheduled program

• Establish a maintenance calendar per component category (routine checks, lifecycle refresh planning, firmware windows).
• Add triggers for non-routine maintenance: vendor security advisory, repeated incidents, end-of-support, hardware health alerts.
• Align scheduled work with your change management process (standard/normal/emergency changes).
  Output: a schedule that exists outside individuals’ memory. (NIST Special Publication 800-53 Revision 5)

3) Build a maintenance record standard (ticket template + required fields)

Minimum fields to enforce in your system of record:

• Asset/system identifier(s) affected
• Maintenance type (repair/replacement/preventive/firmware)
• Requestor and executor (internal or third party)
• Planned start/end and actual start/end
• Approval evidence (change approval, CAB outcome, emergency approval)
• Procedure reference (manufacturer/third-party spec link or internal runbook)
• Pre-checks and post-checks (health checks, validation steps, rollback plan)
• Outcome, exceptions, and follow-up actions
  Output: every maintenance event produces consistent evidence. (NIST Special Publication 800-53 Revision 5)

4) Control third-party maintenance explicitly

Where a third party maintains components:

• Require maintenance documentation in the contract/SOW (work orders, service reports, RMA details, completion notes).
• Define record delivery timelines and retention expectations aligned to your program.
• For managed cloud dependencies, require attestations or maintenance reporting appropriate to the service boundary.
  Output: you can demonstrate “document and review” even when you don’t hold the wrench. (NIST Special Publication 800-53 Revision 5)

5) Add a formal review loop (the step most programs miss)

Designate a reviewer function (often IT operations lead + compliance sampling):

• Review maintenance records for a period and verify: approvals present, required fields complete, procedure references included, and post-validation done. (NIST Special Publication 800-53 Revision 5)
• Track exceptions as tickets: missing records, deviations from specs, unauthorized maintenance, or recurring component failures requiring replacement planning.
• Feed results into corrective actions: template changes, training, access control tightening, third-party escalation.
  Output: documented review evidence plus a remediation trail. (NIST Special Publication 800-53 Revision 5)

6) Make it auditable: traceability across systems

Assessors commonly test whether you can trace: Asset → maintenance ticket → change record → implementation evidence → validation results → reviewer sign-off.
If those live in multiple tools, document the linkage approach (IDs, cross-links, exports). (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository or produce them from your ticketing system on demand:

1. Controlled Maintenance policy/standard describing scheduling, documentation requirements, and review responsibilities. (NIST Special Publication 800-53 Revision 5)
2. Maintenance schedule/calendar (by component category or system) and how it’s updated. (NIST Special Publication 800-53 Revision 5)
3. Maintenance records (tickets/work orders) with required fields completed. (NIST Special Publication 800-53 Revision 5)
4. Manufacturer or third-party specifications referenced by procedures (links, PDFs, runbooks with versioning). (NIST Special Publication 800-53 Revision 5)
5. Review evidence: completed review checklists, sampling logs, sign-offs, and exception tracking tickets. (NIST Special Publication 800-53 Revision 5)
6. Third-party maintenance artifacts: service reports, RMAs, completion confirmations, or contractual clauses requiring such records. (NIST Special Publication 800-53 Revision 5)

Practical tip: if you can’t retain manufacturer specs due to licensing, retain a controlled internal runbook that cites the specific document name/version and captures the required steps. (NIST Special Publication 800-53 Revision 5)

Common exam/audit questions and hangups

Questions you should be ready for

• “Show the maintenance schedule for key system components and evidence it is followed.” (NIST Special Publication 800-53 Revision 5)
• “Provide a sample of maintenance records for repairs and replacements, not just patching.” (NIST Special Publication 800-53 Revision 5)
• “How do you ensure maintenance follows manufacturer/third-party specs?” (NIST Special Publication 800-53 Revision 5)
• “Who reviews maintenance records, how often, and what happens when records are incomplete?” (NIST Special Publication 800-53 Revision 5)
• “How do you capture third-party maintenance activity and confirm it meets your requirements?” (NIST Special Publication 800-53 Revision 5)

Hangups that trigger findings

• Maintenance tickets exist, but no review evidence exists. (NIST Special Publication 800-53 Revision 5)
• Repairs/replacements happen under incidents, but asset linkage is missing. (NIST Special Publication 800-53 Revision 5)
• Third parties perform work, but you only have invoices and no maintenance detail. (NIST Special Publication 800-53 Revision 5)

Frequent implementation mistakes (and how to avoid them)

1. Treating MA-2 as “patch management.” Fix by explicitly including repair and replacement events in scope and sampling those in reviews. (NIST Special Publication 800-53 Revision 5)
2. No standard for records. Fix with a mandatory template and required fields in the ticketing system. (NIST Special Publication 800-53 Revision 5)
3. Emergency work lacks retroactive documentation. Fix by requiring post-implementation notes and approval capture as part of emergency change closure. (NIST Special Publication 800-53 Revision 5)
4. Third-party blind spots. Fix with contract language and an intake process for third-party maintenance reports. (NIST Special Publication 800-53 Revision 5)
5. Review is informal. Fix by defining a reviewer role, documenting the method (sampling or full review), and tracking exceptions to closure. (NIST Special Publication 800-53 Revision 5)

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources, so focus on assessor expectations and operational risk. Controlled maintenance failures usually show up as:

• Availability risk (unplanned outages from poorly executed repairs or replacements).
• Security risk (unauthorized component changes, firmware downgrades, introduction of unmanaged parts).
• Audit risk (inability to demonstrate the maintenance trail across third parties and internal teams). (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

First 30 days: make maintenance evidence real

• Publish a Controlled Maintenance standard that defines scope, required record fields, and review ownership. (NIST Special Publication 800-53 Revision 5)
• Update ticket templates to force asset IDs, approvals, procedure references, and validation steps. (NIST Special Publication 800-53 Revision 5)
• Identify where third parties touch infrastructure and start collecting their maintenance artifacts. (NIST Special Publication 800-53 Revision 5)

Days 31–60: connect workflows and close gaps

• Map top component categories to a schedule and align with change windows. (NIST Special Publication 800-53 Revision 5)
• Run the first record review cycle, log exceptions, and fix systemic issues (missing fields, weak approvals, lack of post-checks). (NIST Special Publication 800-53 Revision 5)
• Add contract/SOW clauses or operational requirements for third-party maintenance documentation where missing. (NIST Special Publication 800-53 Revision 5)

Days 61–90: prove repeatability

• Demonstrate traceability from asset to maintenance record to review sign-off for a representative sample across component types. (NIST Special Publication 800-53 Revision 5)
• Operationalize metrics that don’t require statistics to be meaningful: trend exception themes, recurring component failures, and recurring documentation gaps.
• If you use Daydream, configure it to centralize maintenance evidence requests to third parties, track receipt of service reports, and maintain an audit-ready evidence library aligned to MA-2. (NIST Special Publication 800-53 Revision 5)

Frequently Asked Questions

Does Controlled Maintenance require preventive maintenance, or is break/fix enough?

MA-2 explicitly requires you to “schedule” maintenance, so a pure break/fix approach is hard to defend. Define scheduled activities appropriate to your component types and document exceptions. (NIST Special Publication 800-53 Revision 5)

What counts as a “system component” for MA-2?

Treat any hardware or software element that supports the system boundary as a component, especially items that can be repaired, replaced, or maintained. Use your asset inventory to define scope and ownership. (NIST Special Publication 800-53 Revision 5)

How do we show compliance when a third party performs the maintenance?

You still need documentation and review. Require service reports/work orders contractually, ingest them into your evidence repository, and review them against your requirements the same way you review internal tickets. (NIST Special Publication 800-53 Revision 5)

Can we meet MA-2 with change tickets alone?

Often yes, if change tickets include the required maintenance record fields and you can show a review process and results. Many teams still need a separate maintenance/work order record for repairs that occur under incidents. (NIST Special Publication 800-53 Revision 5)

What does “review records” mean in practice?

It means a defined person or role checks completed maintenance records for completeness and conformance, and tracks exceptions to closure. Keep the review output as evidence, not just an informal conversation. (NIST Special Publication 800-53 Revision 5)

How granular do maintenance records need to be?

Detailed enough that an independent reviewer can confirm what changed, who approved it, what procedure was followed, and whether validation occurred. If you can’t reconstruct the event later, the record is too thin. (NIST Special Publication 800-53 Revision 5)