How much detail should be captured in an RCA for AS9100 auditors?

You should capture enough detail in a root cause analysis to let an AS9100 auditor follow the logic, verify the evidence, and see how the result drove correction, corrective action, and effectiveness checks. More detail is not automatically better. If the RCA is vague, unsupported, or disconnected from the actions taken, it will usually fail scrutiny. If it is long but still does not show evidence, ownership, and traceability, it is still weak.

The practical standard is this: an experienced auditor should be able to answer four questions from the record without interviewing three people to reconstruct it.

• What exactly happened, and how was the issue bounded?
• What evidence was used to determine the likely root cause, not just the symptom?
• What was done immediately versus what was changed systemically?
• How will you know the problem will not recur in the same way?

What usually needs to be in the RCA

In most aerospace and other regulated manufacturing environments, a credible RCA record includes the following:

• Problem statement: specific nonconformance, affected part, process, lot, serial, program, date range, and where it was detected.
• Containment or correction: what was done to protect the customer and segregate or control affected product.
• Scope or impact assessment: whether similar product, prior lots, sister lines, suppliers, tooling, or work instructions were checked.
• Root cause method used: 5 Whys, Ishikawa, fault tree, 8D, or another method used consistently enough to be defensible.
• Objective evidence: records, inspection results, training records, machine history, revision history, maintenance data, ERP or MES transaction evidence, supplier records, or document changes that support the conclusion.
• Root cause statement: stated at the process or system level where possible, not just operator error unless the evidence truly stops there.
• Corrective action: the change made to prevent recurrence, with owner, due date, and affected documents or systems.
• Verification of implementation: proof that the action actually occurred.
• Effectiveness review: defined criteria, timing, and result.

That is usually what auditors want to see. They are typically not asking for a long essay. They are asking whether the record is controlled, specific, and supported.

What auditors usually challenge

AS9100 auditors often focus less on the formatting of the RCA and more on whether the organization is solving problems in a controlled way. Common weak points are predictable:

• Root cause equals blame: “operator missed step” with no review of training, work instruction quality, revision control, poka-yoke, inspection design, workload, or tooling condition.
• No evidence trail: conclusions are asserted but not tied to records.
• Correction confused with corrective action: scrap, rework, or retraining is logged, but no systemic prevention step is defined.
• No scope review: one defect is treated as isolated without checking whether the same failure mode exists elsewhere.
• No effectiveness criteria: action is marked complete because a form was closed, not because recurrence risk was actually tested or monitored.
• Change control gap: process changes were made, but document approvals, training updates, validation, or system revision history do not support the change.

If your RCA avoids those failures, the level of detail is usually in the right range.

How much is enough in practice

For a routine internal issue with low scope, a concise but complete RCA may fit on one well-structured record with attachments. For a customer escape, repeat nonconformance, special process issue, supplier problem, or issue tied to airworthiness, configuration, or traceability, the supporting evidence usually needs to be deeper and more formal.

So the right level of detail depends on factors such as:

• severity and recurrence
• whether nonconforming product escaped downstream or to the customer
• product criticality and contract requirements
• whether the issue affects qualified or validated processes
• whether multiple systems or organizations are involved
• customer-specific corrective action response requirements

That dependency matters. AS9100 sets expectations for controlled corrective action, but customer requirements, internal procedures, and product risk often determine how much documentation is actually needed.

Brownfield system reality

In many plants, RCA evidence is spread across QMS, MES, ERP, PLM, maintenance systems, spreadsheets, and email. Auditors will not excuse a weak RCA just because the evidence lives in five systems. If the record depends on fragmented data, someone still has to assemble a traceable package.

That usually means the RCA should reference controlled records rather than copy everything into one form. Revision history, nonconformance records, work instruction versions, training completion, machine maintenance history, and lot or serial traceability should be linkable or attachable. If those links are manual, say so internally and control the process. In brownfield environments, full system replacement is usually unrealistic for this problem alone because of validation cost, downtime risk, integration complexity, and qualification burden.

A simple test

Your RCA probably has enough detail for an AS9100 auditor if:

• another qualified person can understand the issue and reproduce the reasoning
• the stated cause is supported by evidence, not assumption
• the corrective action clearly addresses that cause
• implementation and effectiveness are both visible in controlled records
• related document, training, and system changes are under change control

If those points are not true, adding more words will not fix the problem.

Bottom line

Capture enough detail to make the RCA auditable, evidence-based, and traceable from problem statement through effectiveness review. Do not optimize for length. Optimize for clarity, evidence, and control. The exact depth depends on risk, scope, customer expectations, and how much of the story sits across legacy systems rather than in one governed record.