MA-2: Controlled Maintenance

MA-2 fails in real life for one reason: maintenance happens, but nobody can prove it happened under control. A patch cable gets replaced, a server drive is swapped, a network appliance gets a firmware update during a support call, or a third party performs a break/fix. The work may be competent, but the organization cannot show (1) it was scheduled or triggered appropriately, (2) it followed manufacturer or vendor specifications, and (3) the records were reviewed for completeness and issues.

For a CCO, GRC lead, or security compliance owner, the fastest path is to operationalize MA-2 as a maintenance record system with governance: defined ownership, a repeatable workflow, and a minimum evidence set per maintenance event. Your goal is not to create bureaucracy for technicians; your goal is to make maintenance verifiable, attributable, and consistent across internal teams and third parties.

This page gives you requirement-level guidance you can implement quickly: scope, roles, a step-by-step runbook, evidence to retain, audit questions to pre-answer, and a practical execution plan. The control text is short, but auditors will test it by sampling maintenance events and looking for gaps.

Regulatory text

Requirement (MA-2): “Schedule, document, and review records of maintenance, repair, and replacement on system components in accordance with manufacturer or vendor specifications and/or organizational requirements;” ¹

Operator interpretation: what you must do

MA-2 has three non-negotiable verbs that auditors will test through evidence samples:

1. Schedule maintenance/repair/replacement for system components.

   • Meaning: you define maintenance triggers and cadence (preventive maintenance, end-of-life replacement, support renewals, warranty schedules, firmware lifecycle), and you can show planned work or an approved break/fix trigger.

2. Document maintenance actions and outcomes.

   • Meaning: each event produces a record that identifies the component, date/time, who did the work (including third party), what was done, what standard/spec was followed, and whether issues were found.

3. Review records of maintenance.

   • Meaning: a designated owner periodically checks maintenance records for completeness, exceptions, and systemic issues (missed maintenance, recurring failures, unauthorized work, or out-of-spec procedures), then tracks remediation.

This is a controls-and-evidence requirement more than a tooling requirement. A CMMS, ITSM, or ticketing platform helps, but MA-2 can be met with disciplined process and consistent records.

Primary sources: NIST SP 800-53 Rev. 5 ², NIST publication DOI reference ³.

Plain-English requirement (what a CCO should tell the business)

You must run maintenance like a controlled operational process. Every significant maintenance action on in-scope system components must be planned (or formally triggered), recorded, and later reviewed against what the manufacturer/vendor requires and what your organization requires (security, availability, safety, configuration integrity). If a third party touches your systems, their work needs the same traceability.

Who it applies to

Entities

• Federal information systems and programs adopting NIST SP 800-53 controls ².
• Contractor systems handling federal data where NIST 800-53 controls are flowed down contractually or used to demonstrate security posture ¹.

Operational context (scope what “system components” means)

Define scope using your system boundaries and asset inventory. In practice, auditors expect MA-2 to cover components where maintenance affects confidentiality, integrity, or availability, including:

• Servers, endpoints, network devices, firewalls, HSMs, storage arrays
• Virtualization hosts and critical hypervisors
• Backup infrastructure and recovery components
• Security tooling appliances (IDS/IPS sensors, email gateways)
• OT/IoT where applicable to the system boundary
• Cloud-managed components to the extent you administer them (guest OS, managed databases configuration), and the shared responsibility boundaries you document

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

Step 1: Assign ownership and write a “control card” (one-page runbook)

Create a short control card that answers, in operator language:

• Objective: Controlled maintenance is scheduled, documented, and reviewed.
• Owner: typically IT Operations, with Security/GRC oversight.
• In-scope assets: reference asset inventory categories and system boundaries.
• Triggers: preventive schedule, break/fix, vendor advisory, vulnerability remediation work, end-of-life replacement, audit finding.
• Workflow: request → approval → execution → validation → record retention → review.
• Exceptions: emergency maintenance path with after-the-fact documentation and approval.

This converts MA-2 from “policy text” into an auditable operating procedure.

Step 2: Map maintenance requirements to asset classes

For each asset class, capture the “specification source” you will follow:

• Manufacturer/vendor specifications: warranties, support KBs, recommended service intervals, firmware guidance.
• Organizational requirements: security patch SLAs (if you have them), maintenance windows, change approval rules, logging requirements, validation tests.

Output artifact: a simple matrix (asset class → maintenance types → required steps → required record fields → reference to vendor spec location).

Step 3: Implement a controlled maintenance workflow in your system of record

Pick a system of record and enforce consistent fields. Options include ITSM tickets, change requests, or a maintenance log. Minimum workflow controls:

• A unique work order/ticket ID for each maintenance event
• Asset identifier (hostname/serial number/cloud resource ID)
• Requester + performer (internal team member or third party tech identity)
• Approver when required (normal path)
• Start/end time and maintenance window
• Procedure reference (link to vendor spec or internal SOP)
• What changed (parts replaced, firmware version, configuration change)
• Validation result (post-maintenance checks)
• Issues/defects found and follow-up actions

If third parties perform maintenance, require them to work through your ticketing process or deliver records that you attach to your ticket.

Step 4: Control access and supervision for third-party maintenance

MA-2 intersects with third-party risk and remote support reality. Put minimum guardrails in place:

• Require authorized support accounts and time-bounded access for remote maintenance.
• Record who approved the session and capture session artifacts where feasible (support case number, session logs, command transcript if available).
• Require return of evidence from the third party (service report, replaced part serials, firmware package hash if provided, before/after versions).

Your contracts and support agreements should require maintenance documentation and cooperation with audits where appropriate.

Step 5: Perform a periodic review of maintenance records (and document the review)

Define a recurring review owned by IT Ops with GRC sampling or oversight. The review should answer:

• Were scheduled items completed?
• Are required fields complete (asset, dates, who performed, procedure reference, validation)?
• Did any maintenance occur outside process (e.g., “quick fix” with no ticket)?
• Are there recurring failures indicating deeper issues?
• Were vendor specs followed, and if not, is there an approved exception?

Track findings to closure in a remediation log.

Step 6: Run control health checks and remediation tracking

Treat MA-2 like a control you can test. Periodically:

• Sample completed tickets and verify evidence completeness.
• Sample assets and confirm they have current maintenance coverage (support contract, lifecycle plan, replacements tracked).
• Verify third-party maintenance deliverables are actually being attached and retained.

If you use Daydream to manage your control library and evidence expectations, set MA-2 up with a defined evidence bundle and recurring health checks so your team can produce audit-ready records without scrambling.

Required evidence and artifacts to retain

Auditors typically request “show me maintenance records for these assets” and then test for completeness. Keep an evidence bundle that is consistent and easy to pull:

Per maintenance event (ticket/work order package)

• Work order/ticket with required fields completed
• Approval evidence (change approval, emergency approval after the fact) when applicable
• Procedure reference (link or attachment to vendor spec or internal SOP)
• Technician notes and actions taken
• Parts replaced (part numbers/serials) and disposal handling notes if applicable
• Before/after configuration or version evidence (screenshots, command output, system report)
• Post-maintenance validation results (health checks, monitoring green, functional test)

Program-level artifacts

• Maintenance policy/SOP aligned to MA-2 control text ¹
• Asset inventory or CMDB scope list for in-scope components
• Preventive maintenance schedule by asset class
• Record review checklist and completed review reports
• Exception register (out-of-cycle or out-of-spec maintenance with approvals)
• Third-party support process documentation (how external maintenance is authorized and recorded)

Common exam/audit questions and hangups

Use these as your pre-audit checklist:

• “Show your maintenance schedule for critical components. How do you ensure it happens?”
• “Pick three assets. Provide maintenance, repair, and replacement records for the last period.”
• “How do you know maintenance followed manufacturer/vendor specs?” (Expect to show procedure references, support KB links, or service reports.)
• “How do you handle emergency break/fix work?” (Expect a documented emergency path with after-the-fact record completion and approval.)
• “Do third parties perform maintenance? Show their records and how you supervise and document the activity.”
• “Who reviews the maintenance records, how often, and what happens when something is missing?”

Hangups usually come from incomplete tickets (no asset ID), missing evidence of review, and third-party work happening off-system.

Frequent implementation mistakes (and how to avoid them)

1. Relying on “tribal knowledge” schedules.
   Fix: Put preventive schedules in a calendar or ticket automation tied to asset classes and support contracts.

2. Treating maintenance as separate from change control.
   Fix: Route planned maintenance through your change process when it can affect configurations, availability, or security posture. Use an emergency change path for break/fix.

3. No linkage between ticket and the asset.
   Fix: Make asset ID a required ticket field. No asset ID, no closure.

4. Third-party maintenance happens via email and phone with no retained record.
   Fix: Require a ticket ID for any maintenance action and attach vendor service reports and support case numbers.

5. No documented review.
   Fix: Create a recurring “maintenance record review” task with a checklist and a short report. Save it in your compliance repository.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for MA-2. Practically, MA-2 gaps show up during audits, customer diligence, incident investigations, and availability events. If you cannot prove maintenance history and adherence to vendor specifications, you lose credibility quickly during a security incident root-cause analysis and during authorization or reauthorization reviews under NIST-aligned programs ².

Practical 30/60/90-day execution plan

First 30 days: establish control design and minimum recordkeeping

• Name an MA-2 owner and backup; publish a one-page control card.
• Define in-scope asset categories and confirm you have an inventory/CMDB source of truth.
• Decide the system of record (ITSM/ticketing) and enforce required maintenance fields.
• Define the minimum evidence bundle per maintenance event and where it is retained.

Day 31–60: operationalize workflows and third-party touchpoints

• Build preventive maintenance schedules for priority asset classes (network, compute, backup, security appliances).
• Implement an emergency maintenance/break-fix workflow with after-the-fact documentation rules.
• Update third-party support procedures: access approval, ticket linkage, required service reports.
• Train technicians and service owners on what must be captured in tickets.

Day 61–90: prove operation with review and sampling

• Run your first maintenance record review cycle and document results.
• Sample closed maintenance tickets for completeness; open remediation items for gaps.
• Validate vendor-spec alignment for a sample set (show procedure references and evidence).
• Stand up recurring control health checks in your GRC tooling (including Daydream) so evidence collection becomes routine.

Frequently Asked Questions

Does MA-2 require a specific maintenance tool (CMMS/ITSM), or can we use spreadsheets?

MA-2 requires scheduling, documentation, and review of maintenance records, not a specific tool ¹. Spreadsheets can work short-term, but auditors will expect consistent fields, access control, and reliable retention.

What counts as “maintenance” versus “change,” and do both need tickets?

Treat any activity that repairs, replaces, updates, or services a system component as maintenance in MA-2 scope ¹. If the activity changes configuration, firmware, or availability expectations, route it through your change approval path and retain the same record bundle.

How do we show “in accordance with manufacturer or vendor specifications” without attaching huge manuals to every ticket?

Store vendor specs in a controlled repository and reference them by link, document ID, or support KB number in each maintenance ticket. For high-risk work, attach a relevant excerpt or service report that demonstrates the procedure followed the vendor guidance.

We use cloud services. What maintenance records do we need if the cloud provider maintains the infrastructure?

Scope MA-2 to the components you administer within your system boundary (guest OS, configurations, managed service settings) and document your maintenance on those. For provider-managed layers, retain shared responsibility documentation and provider attestations where they support your compliance narrative ².

How should we handle emergency break/fix where work must happen immediately?

Define an emergency path that allows immediate action but requires a ticket, minimum details, and after-the-fact approval plus validation evidence. Auditors usually accept emergency maintenance when the record is complete and exceptions are reviewed.

What’s the minimum proof an auditor will accept for “reviewed records”?

Keep a recurring review artifact: a checklist, the sample set reviewed, identified gaps, and remediation tickets with closure evidence. The review needs an owner, a date, and a clear outcome tied to maintenance records ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5 DOI