Under AS9100, the core expectations for risk management are the same whether you are doing design or MRO: you must identify risks, evaluate them, plan actions, implement those actions, and monitor effectiveness within your quality management system. The practical implementation, however, looks very different between design and MRO because the data, levers, and time horizons are not the same.
1. Scope of responsibility
Design (AS9100 including design & development):
- Focuses on product safety, qualification to requirements, and lifecycle reliability.
- Risk is tied to design decisions, configuration baselines, and changes (design changes, DER approvals, etc.).
- Hazard analysis often spans the full life of the product, including how it will be manufactured, operated, and maintained.
MRO (organizations with overhaul/repair scope):
- Focuses on continuing airworthiness, maintenance error prevention, and repair/overhaul effectiveness.
- Risk is tied to in-service conditions, prior maintenance history, deviations to OEM instructions, and findings from inspections.
- Often constrained by Type Certificate holder data, OEM repair manuals, and regulatory approvals for repairs.
2. Timing and nature of risk decisions
Design:
- Risk analysis is largely front-loaded during design and development, and then revisited at design change.
- Common tools include FMEA, FTA, hazard analyses and safety assessments aligned with system engineering artifacts.
- Risk controls are implemented via design choices, requirements, margins, derating, redundancy, and specified verification/validation activities.
MRO:
- Risk analysis is event-driven and continuous: each induction, teardown finding, AD/SB, or field event can trigger new assessments.
- Common mechanisms include risk-based inspection scope, risk-based work scoping, and prioritization of findings (e.g., corrosion, fatigue indications).
- Risk controls are implemented through revised work instructions, inspection points, tooling controls, human factors measures, and escalation rules for unusual damage or nonstandard repairs.
3. Data sources and feedback loops
Design:
- Relies heavily on requirements, modeling, analysis, test results, and controlled design reviews.
- In-service feedback enters more slowly: field reliability data, incident investigations, NCR trends, and change requests.
- Feedback is typically routed through PLM, change control boards, and formal design change processes.
MRO:
- Relies on real-time condition data: teardown findings, inspection results, borescope images, NDT outcomes, and part history.
- In-service issues can appear as AOG events, repetitive defects, or trend data across a fleet or component population.
- Feedback is routed through the MRO shop control system, maintenance records, operator reports, and sometimes directly via airline/operator reliability programs.
In brownfield environments, this often means design risks are mainly tracked in PLM/engineering tools, while MRO risks are tracked in separate MRO or ERP/MES systems. Under AS9100, you must show how those separate systems still support a coherent, traceable risk-based QMS.
4. Risk controls and levers
Design:
- Change design geometry, materials, architecture, or interfaces.
- Adjust safety factors, allowable limits, or environmental envelopes.
- Specify manufacturing process controls and verification steps (e.g., special processes, inspection characteristics) in the technical data.
- Define maintenance intervals and inspection requirements that will later apply in MRO.
MRO:
- Change how maintenance is executed: inspection methods, sequences, task cards, and routing.
- Control who can perform specific repairs (certifications, authorizations, training) and how tools and test equipment are managed.
- Apply or request alternative repairs or deviations (e.g., controlled concessions, engineering dispositions) and manage the risk of non-OEM repairs.
- Adjust sampling, inspection frequency, or additional checks based on risk (e.g., repeat findings on a fleet or batch).
5. Interaction with regulatory and design authority controls
Design:
- Risk management is tightly linked to certification basis, regulatory safety requirements, and design approval (e.g., design authority, DER/ODA processes).
- Safety assessments, failure condition classifications, and development assurance levels influence how risk is controlled and documented.
MRO:
- MRO risk management must respect the approved design and maintenance data. Many risk decisions require coordination with the design approval holder (e.g., OEM, DOA) or regulator.
- Risk-based deviations in MRO (e.g., blending beyond manual limits, non-standard repairs) usually demand formal engineering disposition and documentation traceable to the design authority.
AS9100 expects that these interfaces are defined and controlled. It does not itself grant authority to alter design; it requires that any such changes and deviations be controlled and traceable.
6. Risk-based thinking in processes and documentation
Common AS9100 expectations across both design and MRO:
- Risk-based planning of processes, audits, supplier controls, and changes.
- Documented criteria for when a risk requires formal action (e.g., CAPA, engineering change, additional controls).
- Evidence that risk controls are implemented and monitored (records in QMS, MES, PLM, or MRO systems).
- Change control that evaluates risk before implementation and checks effectiveness after implementation.
Design-specific emphasis:
- Risk-based design reviews and gate criteria (entry/exit gates linked to hazard analysis maturity and verification plans).
- Integration of risk assessments into requirements management and configuration baselines.
MRO-specific emphasis:
- Risk-based planning of inspection depth, test requirements, and sampling for certain part families or damage modes.
- Risk-informed escalation paths for unusual damage, repetitive findings, or maintenance errors (e.g., immediate engineering review vs. routine MRB).
7. System coexistence and practical constraints
In many organizations, design, manufacturing, and MRO are supported by separate, legacy tools (PLM/ERP/MES for production, dedicated MRO or airline maintenance systems, stand-alone QMS tools). Under AS9100, this is acceptable if:
- Risk information can be traced across systems (e.g., a field issue driving both an MRO procedure change and a design change is clearly linked).
- Change control ensures that when design risk assessments change, downstream processes (including MRO) are updated and revalidated as needed.
- You can show auditors a clear, end-to-end story of how risks are identified, assessed, controlled, and monitored, despite the distributed system landscape.
Attempting a full system replacement to unify design and MRO risk management often stalls in aerospace because of validation burden, integration complexity, and the cost of requalifying long-lived equipment and workflows. Many organizations instead layer pragmatic integrations, standardized identifiers (e.g., configuration and part numbers), and cross-functional review boards to maintain traceability without wholesale rip-and-replace.
8. Summary of key differences
- Focus: Design is about creating a safe, compliant product; MRO is about keeping in-service products safe and compliant.
- Timing: Design risk is planned and front-loaded; MRO risk is ongoing and event-driven.
- Data: Design relies on models, requirements, and tests; MRO relies on condition data, history, and field events.
- Controls: Design changes the product definition; MRO changes how maintenance and repair are performed within that definition.
- Interfaces: Design leads with regulatory and certification interfaces; MRO operates within those constraints and must escalate when they are challenged.
AS9100 sets the framework for risk-based thinking in both domains, but it is the underlying data, authority, and operational reality that drive the practical differences between design and MRO risk management.
