AS9100 expects operational risk assessments to be specific enough that risks can be clearly understood, owned, and controlled at the process level. Very high-level, generic lists of risks are not sufficient on their own. However, the standard does not dictate a single format or level of granularity, so the right depth is context dependent.
What “specific enough” usually means in practice
For most aerospace manufacturers and MROs, risk assessments should typically:
- Be process-specific: Tied to defined processes (e.g., CNC machining of turbine blades, composite layup, special processes, critical inspection points), not just to the company or site generically.
- Reference actual products or families: Especially for critical parts, key characteristics, or special requirements. Grouping similar part families is acceptable if the risks and controls are demonstrably similar.
- Identify concrete failure modes: E.g., “incorrect torque value applied due to outdated WI” rather than “assembly error.” This supports effective controls and later root cause analysis.
- Link to real controls: Work instructions, inspection plans, qualifications, Poka-Yoke, automation, layered process audits, etc., with traceable identifiers (document numbers, system IDs).
- Quantify impact and likelihood (or equivalent ranking): Even a simple High/Medium/Low approach is fine if applied consistently with clear criteria.
- Connect to responsibilities: Clear process owners, review cadence, and triggers for reassessment (e.g., design changes, supplier changes, process deviations, new equipment).
The detail should be sufficient that an internal or external auditor can see a logical chain:
- How you identified operational risks.
- Why you consider some risks higher than others.
- How those risks are mitigated and monitored in day-to-day operations.
When risk assessments are usually too generic
Risk management is often considered weak under AS9100 when:
- You only have a single, site-level risk register that lists items like “supplier risk” or “human error” with no linkage to processes, parts, or controls.
- Risk logs are obviously copy-paste templates across very different processes without reflecting their particular failure modes.
- “Mitigations” are vague (e.g., “training” or “inspection”) with no reference to specific procedures, frequencies, or acceptance criteria.
- Critical operations (special processes, key inspection points, safety-critical assemblies) are not called out with higher specificity and control.
- There is no evidence that risk assessments are updated as changes occur (engineering changes, new machines, NPI, supplier transitions).
In these cases, the issue is not the format, but that the assessment does not drive or reflect operational decisions.
Minimum expectations vs. higher maturity
At a minimum, to align with AS9100 expectations, operational risk assessments generally should:
- Be documented and controlled (document control, versioning, change history).
- Cover core and high-risk processes across the value stream (order review, planning, manufacturing steps, inspection, test, packing, shipment, and key suppliers).
- Show how risks feed into planning and controls (e.g., traveler content, WI, inspection plans, capacity planning, special approvals).
- Be reviewed periodically and when triggers occur (new product, process change, significant nonconformances, major supplier issues).
At higher maturity levels, organizations often:
- Use FMEA or similar structured tools for process and product-family risks.
- Quantify risk more consistently and link it to control strength, sampling frequencies, and escalation paths.
- Digitally link risks to MES travelers, digital work instructions, and nonconformance workflows so that operational data continually informs risk prioritization.
Balancing specificity with practicality
In brownfield, high-mix, low-volume environments, trying to maintain a separate, detailed risk assessment for every part number often fails. A practical approach is to:
- Organize by process + risk-relevant attributes: E.g., grouping parts by material class, tolerance band, safety criticality, or special process needs, and tailoring one risk model per group.
- Focus on the highest risk areas: Safety of flight, regulatory-significant features, special processes, outsourced processes, and past chronic nonconformance areas.
- Avoid full replacement of existing tools: Enhance existing PFMEA, control plans, or router notes rather than creating a new parallel risk system that cannot be sustained.
- Integrate with existing systems where possible: ERP/MES/PLM/QMS integration is often partial; make sure whatever you build does not require disruptive system replacement to stay current.
Overly granular risk logs that cannot be kept up to date usually create more audit exposure than a well-structured, process-family approach that is actually maintained.
How auditors typically evaluate specificity
While auditors differ, common lines of inquiry include:
- Can you show how you identified and assessed operational risks for this specific product, process, or program?
- Can we trace from the documented risks to the actual controls on the floor (WI steps, inspection points, sign-offs, equipment controls)?
- Have your significant nonconformances, escapes, or customer complaints led to updates in your risk assessments and controls?
- Can process owners explain the main risks and how they are managed, in language consistent with the documented assessments?
If the answer to those questions is consistently yes, the level of specificity is usually sufficient, regardless of whether you use FMEA, risk registers, or another structured method.
Dependencies and constraints
The right level of specificity depends on several factors:
- Process complexity and novelty: New or complex processes usually demand more granular risk analysis than stable, well-understood processes with strong historical performance.
- Customer and regulatory flowdowns: Some primes and authorities expect explicit FMEA, control plans, or critical-to-quality (CTQ) lists; your assessments must at least meet those specifics.
- QMS and data maturity: Plants with fragmented data and legacy systems may need simpler but clearly owned and regularly reviewed assessments to remain realistic.
- Change and validation burden: In heavily validated, long-lifecycle environments, any change to how risk is assessed and controlled must respect change control and revalidation costs. Favor incremental improvement of existing structures over wholesale replacement.
In summary, AS9100 requires operational risk assessments to be specific enough to be actionable and traceable at the process and product-family level, but it does not require unmanageable, part-by-part documentation. The goal is a maintained, coherent link between identified risks, operational controls, and evidence of ongoing review and improvement.
