Learn how to build a maintenance plan with assets, functions, criticality, strategies, activities, frequencies, acceptance criteria, responsibilities, and evidence.
Check it out!
A maintenance plan is the structured document that defines which assets and functions will be maintained, which activities will be performed, under what conditions and frequencies, by whom, with which resources, acceptance criteria, evidence, and review rules. Its purpose is not merely to organize a task schedule: it is to transform operational, reliability, safety, and lifecycle requirements into controllable and traceable actions.
A technically consistent plan starts with the required function of the asset and the risk associated with losing that function. From there, it relates failure mechanisms and modes to the appropriate strategies — preventive, predictive, condition-based, planned corrective, or others — and establishes criteria capable of justifying each intervention. Frequencies copied from generic lists, without considering criticality, history, environment, operating condition, and applicable recommendations, produce a calendar; not necessarily a good maintenance plan.
It is also necessary to distinguish the maintenance plan from merely registering work orders in a CMMS or EAM. The system can control dates, resources, and records, but Engineering needs to define the technical content: scope, method, frequency, limits, responsibilities, risks, required documentation, and treatment of results. When these elements are clear, the software becomes a governance tool for the plan rather than the source of the strategy.
What a Maintenance Plan Needs to Control
The level of detail depends on the type of facility, criticality, and operating regime, but some elements form the minimum structure required for the plan to be executed, audited, and improved.
| Element | Question the plan needs to answer | Consequence of a weak definition |
| Asset and function | What needs to remain available and for what purpose? | Tasks disconnected from expected performance |
| Criticality | What is the consequence of losing the function? | Prioritization based only on apparent urgency |
| Strategy | Why will the action be preventive, predictive, condition-based, or corrective? | Excessive maintenance or unnecessary exposure to failure |
| Activity | What exactly must be inspected, measured, tested, adjusted, or replaced? | Vague work orders and non-comparable results |
| Frequency or trigger | When should the activity occur? | Arbitrary intervals or late reaction |
| Acceptance criterion | What characterizes an acceptable condition, deviation, or failure? | Reports without an objective conclusion |
| Owner and competence | Who executes, analyzes, approves, and decides? | Undefined interfaces and risk of diffuse responsibility |
| Evidence | Which record proves execution and result? | Loss of traceability and audit difficulty |
| Deviation treatment | What happens when the condition is not acceptable? | Accumulated findings without an Engineering decision |
ABNT NBR 5462 treats maintenance as a combination of technical and administrative actions, including supervision, intended to maintain or restore an item to a condition in which it can perform its required function. This definition helps avoid a common mistake: reducing the plan to a list of field activities and forgetting planning, decision-making, verification, and support.
From Required Function to Plan Content
When a plan originates from a historical task list without linkage to function, criticality, and failure mode, the organization may spend more and remain exposed to the same risks. Maintenance Engineering makes it possible to review the strategy and technically justify what should remain, change, or be eliminated.
The plan should be built backwards: first define the result that needs to be preserved; then identify the threats to that result; and finally define the tasks capable of preventing, detecting, or treating those threats.
When the organization starts directly from a frequency spreadsheet, it tends to inherit historical activities without knowing whether they are still necessary. A function-oriented approach makes it possible to question why each task exists and whether it actually controls a relevant failure mode.
Esse raciocínio se conecta à Reliability and Availability Engineering, especially in systems where downtime, redundancy, and recovery capability are business criteria.
Asset Registers, Hierarchy, and Documentation Come Before Scheduling
If asset registers, diagrams, inventory, and actual condition do not converge, frequency is no longer the main problem: first, a reliable asset and documentation baseline needs to be established. This diagnosis also reveals risks that may require documentation updates, design work, or upgrades.
A plan cannot be properly controlled if the organization does not know precisely which assets it has, where they are, how they relate, and which documents represent their current configuration. Duplicate identifiers, equipment without location, outdated diagrams, and undocumented changes make maintenance less reliable even when work orders are completed on time.
The hierarchy should represent the facility in a way that supports decision-making: system, subsystem, equipment, component, or another technically appropriate level. The objective is not to create an excessively detailed tree, but to allow history, failures, costs, inspections, and risks to be associated with the correct object.
A Engineering Asset Management organizes this foundation by relating asset registers, criticality, documentation, condition, and lifecycle. When the existing condition is poorly known, the starting point may be an inspection or Engineering Technical Due Diligence to reconcile documents with field reality.
Criticality and Failure Modes Define Different Priorities
Not all assets warrant the same strategy, frequency, or level of control. Criticality represents the importance of the asset or function in light of failure consequences. Safety, environmental impact, operational continuity, quality, production, legal requirements, redundancy, and cost may alter the classification.
This analysis needs to interact with failure modes. A critical asset does not necessarily require more frequent maintenance under all circumstances; it should receive controls suited to the mechanisms that may degrade its function. If the failure mode is not time-related, periodic replacement may create cost without reducing risk. If a detectable condition variable exists, a predictive strategy may be more efficient. If there is no significant consequence and recovery is simple, planned corrective maintenance may be justifiable.
The principle is to replace the question “how many months between maintenance activities?” with “which failure are we trying to prevent or detect, and which strategy produces the best decision?”.
How to Define Frequencies Without Turning the Plan into an Arbitrary Calendar
Frequency is a consequence of the strategy. It may be established by an applicable regulatory or legal requirement, manufacturer guidance, reliability analysis, operational experience, environmental condition, number of cycles, operating hours, criticality, or observed behavior.
For predictive tasks, frequency needs to consider the degradation rate and the window available between detection of a potential failure and loss of function. For time-based preventive tasks, it is necessary to assess whether there is a technically defensible relationship between age or use and failure probability. For compliance inspections, applicable requirements and the specific conditions of the facility may define their own controls.
The final branch of the tree is relevant to Engineering Consulting: when a high-consequence failure cannot be prevented by a technically effective task, insisting on maintenance may mask the need for design modification, redundancy, modernization, or asset replacement.
Acceptance Criteria Turn Execution into Technical Evidence
A work order to “inspect panel” does not define what an acceptable panel means. The plan needs to establish what will be observed or measured, how the result will be recorded, and which condition requires treatment. Without criteria, different teams may reach incompatible conclusions about the same condition.
Criteria may come from design documents, specifications, applicable standards, manufacturers, baselines, operating limits, trends, or approved procedures. The key is not to turn any reference into a universal limit. Load conditions, configuration, environment, equipment class, and purpose may change the assessment.
The record should also preserve sufficient evidence for future analysis. An “OK” result may be inadequate when the measured value, test condition, photograph, instrument, date, or responsible person is needed to compare performance and justify decisions.
Responsibilities Need to Cover Execution, Analysis, and Decision-Making
A good plan separates roles. The person who executes the activity may not be the same person who interprets a deviation, approves an intervention, or authorizes a design change. In complex facilities, this separation reduces conflicts and improves traceability.
| Functional role | Typical responsibility in the plan |
| Operations | Provide operating condition, record symptoms, and coordinate windows |
| Maintenance | Execute tasks, record evidence, and address occurrences within the authorized scope |
| Engineering | Define criteria, analyze failures, assess risks, and approve technical changes |
| Safety | Verify safety controls and interfaces applicable to the activities |
| Supply | Procure materials and services according to specifications and technical requirements |
| Oversight or Owner’s Engineering | Verify third-party compliance, evidence, measurements, pending items, and acceptance |
The matrix should be adapted to the organization. The central point is to prevent a critical anomaly from ending in a report without an owner for the decision, or a contractor from changing a system without the client’s technical governance.
Legal, Normative, and Documentary Requirements Need to Enter the Plan in the Right Context
The maintenance plan should map the requirements applicable to the facility, but it should not turn standards into a generic list of frequencies they do not establish. Each obligation needs to be interpreted according to scope, applicable edition, facility type, existing documentation, and defined responsibilities.
In electrical installations, for example, maintenance needs to align with NR-10, technical documentation, and applicable design standards, including relevant requirements of NBR 5410 and NBR 5419 when related to the installation under analysis. The Electrical Installation Record, where applicable, should not be treated as a file separate from operational reality: changes, inspections, diagrams, procedures, and records need to remain consistent.
This means that a maintenance finding may create a need for documentation updates, risk analysis, a technical report, an engineering project, or an upgrade. The maintenance activity does not replace these Engineering deliverables.
Resources, Safety, and Execution Conditions Are Part of the Task
An activity is executable only if the plan considers competent personnel, appropriate instruments, materials, spare parts, permits, operating condition, and the intervention window. Technical and logistical delays also affect restoration time, a concept explicitly addressed by NBR 5462.
This dimension is especially relevant for assets whose shutdown requires coordination with production, IT, facilities, safety, suppliers, or other disciplines. The frequency may be correct on paper and the organization may still systematically fail because it does not plan downtime, access, or resources.
The CMMS or EAM Should Execute the Strategy, Not Invent It
Once assets, tasks, triggers, criteria, and responsibilities are defined, the digital platform can turn the plan into controllable routines. Work orders, alerts, histories, evidence, costs, and backlog remain linked to the asset and feed subsequent analysis.
Configuration quality matters. Too many free-text fields make comparison difficult; inconsistent failure codes prevent analysis; closures without evidence create a false sense of control. Requirements, Evidence, and Acceptance Criteria Management is applicable when the organization needs to structure traceability among requirement, execution, verification, and acceptance.
How to Review the Plan Based on Actual Performance
A maintenance plan is not a static document. Recurring failures, false alarms, tasks with no findings, process changes, retrofit, load changes, new requirements, and obsolescence are signs that the strategy needs to be reassessed.
The review should use operational evidence: failure history, downtime, MTBF, MTTR, recurrence, backlog, costs, inspection results, asset condition, and work-order quality. The article on Maintenance KPIs shows how to distinguish activity indicators from indicators that actually support decisions.
The review also needs to reach the design level when maintenance is no longer the appropriate response. Recurring failures caused by inadequate specification, capacity limitations, lack of redundancy, or obsolescence should generate an Engineering decision, not merely more work orders.
When the Maintenance Plan Becomes an Engineering Program
In organizations with many systems, suppliers, and requirements, the plan stops being merely an operational document and becomes part of asset governance. The work may involve inventory and hierarchy, criticality analysis, FMEA/FMECA, documentation review, procedures, responsibility matrices, contracting specifications, indicators, and a management-of-change process.
When significant gaps are identified, the sequence may advance to studies, projects, budgeting, procurement, oversight, testing, and commissioning. In existing facilities, an upgrade Master Plan may be more appropriate than trying to correct every finding simultaneously because it allows prioritization of risks, dependencies, CAPEX, and implementation windows.
This is also a typical field for Owner’s Engineering: the owner maintains independent technical representation to structure requirements, engage specialists, oversee execution, verify deliverables, and accept results without depending exclusively on the solution proposed by each supplier.
Final Considerations
A high-quality maintenance plan connects function, risk, strategy, task, frequency, criterion, responsibility, and evidence. It should not be evaluated by the number of rows in a spreadsheet, but by its ability to guide consistent decisions and keep assets capable of performing their functions.
When integrated with reliability and asset management, the plan becomes part of the organization’s Engineering system. Information produced in the field feeds failure analysis, documentation updates, projects, investments, and lifecycle decisions — allowing maintenance, operations, and Engineering to work from the same technical basis.
When the plan identifies recurring failures, obsolescence, capacity limitations, or interventions that depend on multiple suppliers, the solution requires Engineering coordination. Diagnosis, specification, procurement, oversight, and commissioning make it possible to address the cause and technically verify the result.
Technical references
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 5462:1994 — Reliability and maintainability — Terminology. Available at: https://www.abntcatalogo.com.br/.
[2] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 55001:2024 — Asset management — Management systems — Requirements. Available at: https://www.iso.org/standard/83054.html.
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60300-3-10:2025 — Dependability management — Part 3-10: Application guide — Maintainability and maintenance. Available at: https://webstore.iec.ch/en/publication/65334.
Frequently asked questions
It should identify assets and functions, criticality, strategy, activities, triggers or frequencies, acceptance criteria, owners, resources, evidence, and rules for treating deviations and reviewing the plan itself.
Frequency depends on the strategy and may consider applicable requirements, manufacturer guidance, the relationship between failure and time or use, observed condition, criticality, environment, history, and response capability. It should not simply be copied from a generic table.
No. The plan technically defines what should be maintained and how. Maintenance Planning and Control organizes planning, scheduling, resources, backlog, and execution control for that set of activities.
The system can register and control tasks, but the technical criteria of the strategy need to be defined by the organization or responsible Engineering function. Automating a poorly structured plan merely automates its weaknesses.
No. The strategy should be suited to the failure mode, detectability, criticality, and consequence. Some assets may justify predictive, condition-based, or planned corrective maintenance.
When there are critical assets, recurring failures, inconsistent documentation, unjustified criteria, safety requirements, multiple suppliers, modernization efforts, or findings that require design work, risk analysis, or lifecycle decisions.
Related technical materials
Related solutions
- Electrical Safety and NR-10 Compliance: Design, Risks, Documentation, and Controls
- Requirements, Evidence, and Acceptance Criteria Management
- Technical Knowledge Management and Lessons Learned
Related services
- Maintenance Engineering: Strategies, Reliability, Plans, and Indicators
- Reliability and Availability Engineering: Criticality, Failures, Performance, and Continuity
- Engineering Asset Management: Registers, Criticality, Lifecycle, and Performance
Main content on this topic
- Predictive Maintenance: What It Is, How It Works, Techniques, and Application Criteria
- Maintenance Engineering: Planning, Reliability, Backlog, and Performance
- Preventive, Predictive, and Corrective Maintenance: How to Define the Right Strategy
