How detailed do operational risk assessments need to be under AS9100 Rev D?

AS9100 Rev D requires you to identify, assess, and control operational risks that could affect product conformity, on-time delivery, and customer satisfaction. It does not prescribe a single format or a fixed level of detail, but certification bodies will expect your risk assessments to be:

• Proportionate to risk and complexity: Higher-risk processes (special processes, key characteristics, safety-critical parts, complex assemblies, software-driven operations) need more detailed analysis than low-risk, low-complexity tasks.
• Structured and repeatable: You need a consistent method (e.g. FMEA-style, risk matrix, hazard list) with defined criteria for likelihood, severity, and priority, even if the template is simple.
• Documented and traceable: It must be clear what was considered, what the risks are, how they were scored, and what controls or actions you chose. Auditors typically sample this to see that decisions are evidence-based, not ad hoc.
• Integrated with operational controls: The output of risk assessments must connect to real controls in your QMS and operations: work instructions, inspection plans, special process controls, supplier requirements, training, maintenance, etc.
• Maintained over time: Risks and controls must be reviewed and updated when you change processes, tooling, software, suppliers, or when nonconformances, escapes, or delivery issues reveal new risks.

What “sufficient detail” usually looks like

The level of detail is judged against your own context and the standard’s intent, not a page count. In practice, assessments are usually considered adequate when they:

• Identify concrete failure modes or scenarios, not just generic labels (e.g. “incorrect heat treat cycle for landing gear components,” not just “process risk”).
• Explicitly evaluate likelihood and consequence using your defined scale (qualitative or quantitative) so risk ranking is reproducible.
• Link each high or medium risk to specific controls: process parameters, inspection points, digital traveler checks, interlocks, training, supplier controls, or monitoring plans.
• Show residual risk after controls and explain why it is acceptable per your criteria.
• Reference the affected processes and documents: routing steps, work instructions, control plans, software versions, or programs/part families.

If an assessor cannot trace from a high-level risk (e.g. late delivery of critical parts) down to specific operational controls and records, the risk assessment is usually seen as too superficial.

Minimum expectations under AS9100 Rev D

For most aerospace manufacturers and MROs, operational risk assessments should at least cover:

• Scope definition: Which product line, process family, or value stream is being assessed.
• Risk identification: Key operational risks that can affect conformity and on-time delivery (process stability, capacity and bottlenecks, special processes, key characteristics, configuration control, software revisions, rework pathways, supplier failures, logistics, etc.).
• Risk evaluation: A defined method to rate risks (e.g. 3×3 or 5×5 matrix) with documented criteria, not just intuition.
• Risk treatment: Actions and controls proportionate to risk, assigned owners, and due dates where improvement is needed.
• Link to QMS processes: How risks and actions link into production planning, configuration management, change control, NCR/CAPA, and management review.
• Evidence of review: Dates, participants, and triggers for revisiting the assessment (e.g. after major changes or significant nonconformances).

Very high-level lists like “risk: machine failure, mitigation: maintenance” with no prioritization, no traceability to specific assets, and no link to maintenance plans are usually inadequate for AS9100 Rev D expectations.

Aligning depth of analysis with process risk

AS9100 Rev D allows you to scale the level of detail to your context, but you need to be able to justify your choices. A common pattern is:

• Tier 1 (high risk): Safety-critical parts, special processes, complex assemblies, or new technologies. Use detailed risk tools (e.g. FMEA-like analysis) with characteristic-level or step-level detail and explicit links to inspection and process controls.
• Tier 2 (medium risk): Significant contributors to delivery or quality that are not directly safety-critical. Use a structured risk register or matrix with enough detail to drive actions and monitoring, but not necessarily down to every feature.
• Tier 3 (low risk): Standard, low-complexity processes with stable history. A lighter-weight checklist or high-level risk review may be sufficient, provided performance data supports the reduced depth.

Auditors usually look less at whether you used a specific method and more at whether your method is applied consistently, is scaled rationally to risk, and is linked to measurable outcomes (nonconformances, delivery performance, escapes, etc.).

Brownfield and system coexistence considerations

In most regulated aerospace environments, risk assessments have to coexist with legacy MES, ERP, PLM, and QMS systems. Typical constraints and tradeoffs include:

• Distributed data: Risk controls often live across multiple systems (QMS, MES, ERP, maintenance, training). Overly granular risk models that cannot be traced into those systems become difficult to maintain and defend.
• Change control burden: Very detailed risk assessments that reference specific work instruction steps, machine IDs, or software versions can create heavy change-control workload whenever something shifts. Depth must be balanced against your ability to keep it current under formal change management.
• Long equipment lifecycles: You will often have to assess risk across new and very old assets, with variable data quality. Expect to rely less on theoretical scoring and more on actual performance data and NCR/CAPA history for older equipment.
• Integration limitations: Trying to fully replace legacy risk-related modules (e.g. in an existing QMS) can introduce significant validation and downtime risk. Many organizations instead layer a structured risk assessment process on top of existing tools and link via document references and shared IDs rather than deep technical integration at first.

In this context, risk assessments that are too detailed can be as problematic as those that are too shallow. The key is to choose a level of detail you can maintain reliably within your existing change control, validation, and IT constraints.

Evidence auditors typically look for

To assess whether your operational risk assessments are detailed enough, auditors will usually:

• Sample a high-risk value stream and ask to see the corresponding risk assessment.
• Trace a few top risks to actual controls in routings, work instructions, inspection plans, and training.
• Check that recent significant nonconformances, escapes, or chronic delivery issues are reflected in updated risk assessments and actions.
• Verify that risk-based thinking appears in management review, planning, and change control decisions.

If you can clearly show how your assessments informed concrete controls and improvements, and you can justify why the level of detail matches the risk, you are typically operating at the right level of detail for AS9100 Rev D expectations.