MA-6(1): Preventive Maintenance

MA-6(1): Preventive Maintenance requires you to perform scheduled, preventive maintenance on defined system components at defined intervals, and to prove it happened with repeatable evidence. To operationalize it, you must (1) set scope (which assets), (2) set cadence (how often), (3) execute and track work, and (4) retain maintenance records tied to each asset and interval. ¹

Key takeaways:

• Define the “what” (components) and “when” (intervals) explicitly, then enforce it through a maintenance schedule and tickets. ¹
• Evidence is the requirement in practice: auditors look for asset-level maintenance logs that match your stated cadence. ¹
• Preventive maintenance must cover operational technology and facilities dependencies when they support system availability and integrity, not just IT servers. ²

MA-6(1): preventive maintenance requirement sounds simple, but it fails in the same predictable ways: the scope is vague (“IT equipment”), the cadence is implicit (“as needed”), and records live in disconnected places (email threads, vendor portals, a CMMS, and ticketing). Assessors then ask a basic question you cannot answer cleanly: “Show me the preventive maintenance performed for these components during the last period, and show it was done on schedule.”

NIST frames MA-6(1) as an execution requirement, not a policy statement: you must perform preventive maintenance on defined components at defined intervals. ¹ For a CCO, GRC lead, or compliance officer supporting a federal system or a contractor environment handling federal data, the fastest path is to treat MA-6(1) like a measurable operational control: asset inventory in, schedule out, tickets created, work performed, evidence retained, exceptions approved.

This page gives you requirement-level implementation guidance you can hand to IT operations, facilities, and third parties, then assess with minimal friction.

Regulatory text

NIST requirement (verbatim): “Perform preventive maintenance on {{ insert: param, ma-06.01_odp.01 }} at {{ insert: param, ma-06.01_odp.02 }}.” ¹

How to read the placeholders (operator interpretation):

• “{{…ma-06.01_odp.01}}” = the components you decide are in-scope for preventive maintenance (for example: servers, network gear, storage arrays, UPS units, HVAC supporting a server room, backup generators, specialized security appliances).
• “{{…ma-06.01_odp.02}}” = the intervals you set (for example: manufacturer-recommended schedule, internal engineering standard, or risk-based interval by asset criticality).

What you must do: define both parameters (components and intervals), perform the maintenance accordingly, and retain records that demonstrate performance against the defined interval. ¹

Plain-English interpretation (what the control is really testing)

Assessors use MA-6(1) to test whether you run your environment like an engineered system instead of an ad-hoc collection of devices. Preventive maintenance reduces outages and integrity risks caused by wear-out failures, degraded cooling/power, latent hardware faults, and overdue firmware or component servicing.

MA-6(1) is not satisfied by a statement like “we patch monthly.” Patching may be related, but preventive maintenance is broader: scheduled upkeep of components that maintain confidentiality, integrity, and availability. You need a plan and proof that the plan is followed. ²

Who it applies to (entity and operational context)

MA-6(1) most directly applies where NIST SP 800-53 is contractually or programmatically required, including:

• Federal information systems (agencies and operators). ²
• Contractor systems handling federal data where the system security plan and assessment procedures map to NIST SP 800-53 controls. ²

Operationally, it applies to teams that own or influence maintenance outcomes:

• IT infrastructure and operations (data center, cloud ops, endpoint engineering)
• Network engineering
• Facilities/physical security (UPS, HVAC, generators, access control power and controllers)
• OT/ICS operations (where applicable)
• Third parties performing maintenance (hardware support, managed services, colocation providers)

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

1) Assign ownership and draw the control boundary

• Name a control owner accountable for MA-6(1) execution across domains (IT + facilities).
• Identify implementers (IT ops, facilities, and third parties) and define handoffs.
• Declare system boundary: which sites, enclaves, and supporting infrastructure are part of the authorized system.

Output: MA-6(1) control statement in your SSP/control matrix that names owner, in-scope components, and evidence sources. ¹

2) Define “components” in a way you can test

Build an in-scope component list using your CMDB/asset inventory. Use categories plus specific asset identifiers.

A practical scoping method:

• Tier 1 (mission-critical): components whose failure causes outage or data loss (core network, identity infrastructure, storage, backup, hypervisors, UPS).
• Tier 2 (supporting): components that degrade resiliency or monitoring (secondary switches, management networks, monitoring collectors).
• Tier 3 (peripheral but in-boundary): lab or low-impact components that still sit inside the boundary.

For each category, define whether preventive maintenance is performed by your staff or a third party.

Tip: If a third party maintains it, MA-6(1) still expects you to manage the requirement and retain evidence. Treat it as shared responsibility, not outsourced responsibility.

3) Define “intervals” and the standard for each component type

You need explicit intervals. Choose one of these defensible approaches:

• Manufacturer schedule (document the model-specific guidance you follow).
• Internal engineering standard (document why your interval is appropriate).
• Risk-tiered intervals (Tier 1 more frequent than Tier 3).

Then document how intervals are triggered:

• Calendar-based (scheduled)
• Runtime-based (hours of operation)
• Condition-based (alerts/thresholds), if you can prove monitoring thresholds and work orders reliably trigger

Output: a preventive maintenance schedule or matrix that maps component class → interval → maintenance activities → evidence. ¹

4) Operationalize through a system of record (tickets or CMMS)

Pick one system as the system of record (SOR) for maintenance execution:

• ITSM ticketing (ServiceNow/Jira) for IT components
• CMMS for facilities equipment
• A controlled spreadsheet is acceptable only if it has change control, approvals, and immutable history. Most teams regret this during audits.

Minimum SOR fields:

• Asset ID / hostname / serial number / location
• Maintenance type (preventive)
• Scheduled due date and completion date
• Work performed (checklist or linked procedure)
• Performed by (person or third party)
• Evidence attachments (photos, vendor report, logs)
• Exception/deferral approvals with rationale

5) Execute, review exceptions, and close the loop

• Run the scheduled maintenance.
• If maintenance is deferred, document the deferral, risk acceptance, compensating controls, and the rescheduled date.
• Trend recurring deferrals; repeated “pushes” signal a broken process and will show up in sampling.

6) Make it assessable: sampling, reconciliations, and management review

Build a lightweight monthly or quarterly reconciliation:

• Pull list of in-scope assets.
• Pull completed preventive maintenance records.
• Identify overdue items and document remediation.
• Review metrics qualitatively (overdue list, aging items, repeat deferrals). Avoid invented percentages.

Where Daydream fits naturally: Daydream helps you map MA-6(1) to a clear control owner, an implementation procedure, and recurring evidence artifacts so your maintenance process stays audit-ready instead of being rebuilt during every assessment cycle. ¹

Required evidence and artifacts to retain

Keep evidence that ties component + interval + performance together.

Core artifacts (keep in one evidence folder per period):

• Preventive maintenance policy/standard or SOP excerpt covering scope and intervals
• Preventive maintenance schedule/matrix (component class → interval)
• Asset inventory/CMDB extract showing in-scope components
• Ticket/CMMS export showing work orders completed in the period
• Work instructions/checklists (what “maintenance performed” means)
• Vendor maintenance reports (if third party performed)
• Deferral/exception approvals and risk rationale
• Management review notes (operational review of overdue/deferrals)

Common exam/audit questions and hangups

Auditors and assessors commonly ask:

1. “What components are covered by MA-6(1)?” If you answer with categories only, expect follow-up sampling by asset ID.
2. “What interval did you define for each component type, and why?” “As needed” usually fails because it is not an interval. ¹
3. “Show evidence for these sampled assets for the last period.” They will pick a mix: critical systems, edge devices, and something maintained by a third party.
4. “How do you handle deferred maintenance?” They want to see approval and rescheduling, not silent backlog.
5. “How do you know the CMDB is complete?” Expect a completeness discussion and reconciliation process.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Scope written as “all IT assets”	Not testable; cannot sample	Define component classes and include asset IDs via CMDB extracts
Intervals not defined (“as needed”)	Direct conflict with “at intervals” language	Set explicit intervals per component class 1
Evidence split across systems with no crosswalk	You cannot prove completion	Use one SOR and attach vendor reports/tickets to assets
Third-party maintenance treated as “their problem”	You still own compliance	Contractually require reports and keep them with your evidence set
Preventive maintenance confused with patching only	Too narrow	Include power/cooling, hardware servicing, and relevant infrastructure in boundary 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for MA-6(1), so this guidance focuses on assessment and operational risk.

Operational risk is straightforward: missed preventive maintenance increases the chance of unplanned downtime, degraded resiliency (battery/UPS failures), and cascading incidents during peak load or disaster recovery. Compliance risk is also straightforward: MA-6(1) is easy to sample and easy to fail if your “components and intervals” are not explicit and backed by records. ¹

A practical 30/60/90-day execution plan

First 30 days (Immediate: make the requirement testable)

• Assign MA-6(1) control owner and implementers (IT + facilities).
• Define in-scope component classes and produce an initial asset list from CMDB.
• Draft the preventive maintenance interval matrix by component class.
• Choose the system of record for work orders and decide how evidence will be attached/exported.

By 60 days (Near-term: run the process end-to-end)

• Convert the matrix into scheduled tickets/work orders.
• Run preventive maintenance for a pilot subset (prioritize mission-critical components).
• Implement exception/deferral workflow with documented approvals.
• Build an evidence packet template (what you will hand an assessor).

By 90 days (Ongoing: stabilize and audit-proof)

• Expand scheduling to full in-scope inventory.
• Perform the first reconciliation between CMDB scope and maintenance completion records.
• Add a standing ops review agenda item: overdue maintenance, deferrals, and recurring issues.
• Update SSP/control narrative and evidence mapping so MA-6(1) stays current as assets change. ¹

Frequently Asked Questions

Do we have to follow the manufacturer’s preventive maintenance schedule exactly?

NIST requires defined intervals and performance against them, not a specific vendor schedule. If you deviate, document your rationale and keep it consistent across the component class. ¹

Does MA-6(1) apply in cloud environments where we don’t touch hardware?

Yes, but the scope shifts. You still have components you control (guest OS, configurations, backups, network constructs) and you must define preventive maintenance activities and intervals for those; for provider-managed hardware, retain shared responsibility documentation and relevant reports where available. ²

What counts as acceptable evidence?

Evidence must show the asset, the scheduled interval, and completion (ticket/work order + checklist/output + dates + performer). Screenshots can work, but exports and signed vendor reports reduce audit friction. ¹

How do we handle preventive maintenance performed by a third party?

Put reporting requirements in the contract or SOW (work performed, date, assets covered, technician/company) and store those reports in your evidence repository tied to your asset IDs. You remain accountable for demonstrating performance. ²

We can’t get perfect CMDB accuracy. Will that fail the control?

Assessors expect reasonable completeness controls. Maintain a reconciliation step (inventory to maintenance records), document gaps and remediation, and show that critical components are consistently covered.

Is patching enough to satisfy MA-6(1)?

Patching may be one preventive maintenance activity, but MA-6(1) is broader: it requires preventive maintenance on defined components at defined intervals. If your scope includes only software, document why hardware and facilities are out of boundary for the system. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5