What level of detail is expected in AS9100 corrective action records?

AS9100 does not define a specific corrective action form or word count, but it does set clear expectations for completeness, traceability, and evidence. In practice, an AS9100 corrective action record must contain enough detail that a competent third party (auditor, customer, or internal reviewer) can reliably understand:

• What the issue was
• How it was contained
• What the true root cause was
• What was changed to prevent recurrence
• How you verified that the fix actually worked over time

High-level, vague, or purely narrative records (for example, just writing “retrained operator” or “fixed process”) rarely meet expectations in aerospace environments.

Core elements and expected level of detail

While formats vary (8D, 5-Why, custom CAPA forms, etc.), robust AS9100 corrective action records typically document the following with sufficient detail and objective evidence references.

1. Problem description and context

The issue statement should be specific and traceable, not generic. A typical level of detail would include:

• What failed: part number, revision, lot/batch, work order/serial, process step or machine.
• How detected: inspection step, audit, customer complaint, in-service event, field failure, etc.
• Where and when: facility, line/cell, station, and approximate time window.
• Effect on product: what requirement or specification was not met.
• Risk context: whether delivered product might be affected, and if so, how you assessed the risk.

Auditors usually expect enough detail that they can trace back to the original nonconformance record, inspection report, or customer notification without guesswork.

2. Immediate containment actions

Containment should show how you protected the customer and controlled suspect product, with concrete steps such as:

• Quarantine of specific work orders, lots, or serial numbers.
• 100% inspection or reinspection criteria and results (including references to inspection records).
• Field or customer notifications if applicable (referencing specific communications).
• Temporary process controls implemented to prevent further escapes.

Simply documenting “contained product” without quantities, scope, or method is usually considered insufficient.

3. Root cause analysis

AS9100 requires you to identify the root cause, not only the immediate cause. The level of detail expected here usually includes:

• Structured method: 5-Why, fishbone, fault tree, or similar. The record should show the reasoning, not just the final answer.
• Evidence-based: link to data, records, interviews, or physical evidence used to support the conclusion.
• Systemic view: distinction between special cause (one-off) and systemic causes (e.g., procedure gaps, training system issues, ineffective controls).

Entries like “operator error,” “human error,” or “lack of attention” by themselves are generally not accepted as adequate root causes. The record should explain why the system allowed that error to occur and escape detection.

4. Corrective and preventive actions

The actions section should describe not only what you did, but how it addresses the identified causes. Typical detail includes:

• Specific actions: procedure revisions (with document IDs and revisions), fixture or tooling changes, process parameter changes, software or program updates, training updates, new inspection or test steps, etc.
• Responsibility and timing: named roles or owners, with planned and actual completion dates.
• Scope and extent: where the change applies (cell, line, plant, specific product family, or cross-site).
• Change control: references to engineering change orders, document change requests, or configuration control records where applicable.

High-level items like “update procedure” without referencing which procedure, what changed, and where it is controlled create traceability gaps that auditors will question.

5. Evidence of implementation

Auditors expect more than a check-box that an action is “complete.” Good records point to:

• Updated procedures or work instructions (document number, revision, release date).
• Revised programs or setups (e.g., CNC programs, test sequences), with identifiers and revision control.
• Training completion records, tied to specific content and affected personnel, not just “toolbox talk done.”
• Photographs or screenshots of updated tools, screens, or forms, when appropriate.

The detail should be sufficient that someone could verify the change in the actual process or system without ambiguity.

6. Effectiveness verification

This is where AS9100 corrective action records frequently fall short. The expected detail usually includes:

• Measurement criteria: what metric or evidence you will use (e.g., zero recurrences over X lots, reduced defect rate, audit results, layered process audit checks).
• Verification period: a defined time frame or quantity of production sufficient to provide confidence.
• Results: documented data or observations showing whether the issue recurred, with dates and responsible reviewers.
• Conclusion: a clear statement that the action is effective or not, and follow-on actions if it was not.

Effectiveness sections that just say “effective” with no data or rationale are often flagged as weak in AS9100 audits.

Traceability and cross-references

In aerospace, auditors expect corrective action records to be tightly linked to related records. Typical cross-references include:

• Nonconformance / NCR or MRB disposition records.
• Customer complaints or SCARs.
• Risk assessments or FMEA updates if the failure mode was significant.
• Training records, engineering change notices, and document revisions.
• Work orders, serial numbers, and inspection reports for affected product.

The level of detail should allow a clear thread from the original problem, through decisions and actions, to the current state of the process and product.

Digital vs. paper and brownfield environments

In many aerospace plants, corrective actions span legacy QMS, MES, ERP, and document control systems. This affects how much detail you put directly into the record vs. link by reference:

• Where systems are not integrated, records often need more explicit detail (for example, key fields manually re-entered) so auditors can follow the trail without system access.
• In better integrated environments, the corrective action record can reference other validated systems by ID, provided those links are reliable and accessible during audits.
• Full system replacement to “fix” CAPA documentation is typically high-risk in AS9100 environments due to validation and downtime; incremental improvements to templates, fields, and workflows are more common.

Regardless of tooling, the expectation is that the record is complete, coherent, and traceable at the time of audit.

Common failure modes in AS9100 corrective action records

Some patterns that often trigger findings or observations:

• Problem statements that are too vague to be traceable to specific product or requirements.
• Root causes limited to “human error” without analyzing why controls failed.
• Actions listed without clear link to the identified causes.
• Missing evidence of implementation or dependence on tribal knowledge.
• No objective effectiveness check, or effectiveness declared before enough production has run.
• Inconsistent cross-references between NCR, CAPA, change control, and training records.

Practical benchmark for “enough” detail

A useful internal test is:

• If a qualified person from another site, who did not live through the event, can reconstruct what happened and why your fix should prevent recurrence using only the record and referenced documents, the level of detail is usually sufficient.
• If they need hallway conversations and institutional memory to understand key decisions, the record is likely too thin for AS9100 expectations.