Common AS9100 mistakes tend to come from treating the standard as a documentation project instead of a way to run the operation. The details vary by plant and supply chain tier, but the same failure modes show up repeatedly.
1. Treating AS9100 as a paperwork exercise
Typical issues:
- Writing procedures to match the standard clause-by-clause, rather than how work is actually done.
- Creating forms and logs that no one uses, or that are filled out after the fact for audits.
- Separating the “AS9100 system” from the real production, planning, and engineering processes.
Risk: Audits may pass on paper, but the QMS will not prevent escapes, recurring nonconformities, or customer findings. In regulated environments this creates traceability gaps and weak objective evidence.
2. Weak process ownership and unclear accountability
Typical issues:
- No clearly defined process owners with authority to change and improve the process.
- RACI ambiguity across quality, engineering, production, and supply chain for key controls like FAI, concessions, and nonconforming product.
- Quality expected to “own” AS9100 alone instead of shared ownership across functions.
Risk: Processes drift, changes are made informally, and no one feels responsible for systemic issues surfaced in audits, MRB, or CAPA.
3. Risk-based thinking done superficially
Typical issues:
- Risk registers created once for certification, then not updated when product mix, suppliers, or systems change.
- FMEAs written to satisfy customers but not referenced during design changes, routing changes, or capacity shifts.
- Operational risks (IT outages, data integrity, legacy equipment failures, supplier instability) not linked to controls in everyday planning.
Risk: The organization claims to use risk-based thinking, but production scheduling, engineering changes, and supplier decisions ignore known high-risk areas.
4. Poor integration of design, manufacturing, and quality
Typical issues:
- Design and manufacturing using different bills of material or configuration rules, causing mismatches on the floor.
- Engineering changes not fully propagated into routings, NC programs, work instructions, inspection plans, and gauge programs.
- Quality planning (control plans, inspection plans, sampling) not updated when design or process changes occur.
Risk: Nonconformities emerge because the shop is effectively building an obsolete or ambiguous configuration, while documentation suggests control exists.
5. Inadequate configuration and document control
Typical issues:
- Multiple, unsynchronized sources of truth for drawings, models, work instructions, and inspection criteria (PLM, shared drives, paper, operator copies).
- Uncontrolled local edits to work instructions or setup sheets created to “get parts out” without formal change control.
- Obsolete documents still available on the floor or in test areas.
Risk: Traceability and configuration management are undermined. When a defect is found, it is hard to know which revision was actually built or inspected, particularly in long-lifecycle programs.
6. Nonconforming product and MRB handled informally
Typical issues:
- Scrap, rework, and concessions logged inconsistently or only when costly, leading to underreported nonconformities.
- Material Review Board decisions not clearly documented, with incomplete data on defect type, cause, and disposition.
- Use-as-is decisions taken under schedule pressure without full technical risk assessment or customer approval where required.
Risk: Incomplete history of nonconformities makes it difficult to demonstrate control, perform effective root cause analysis, or defend decisions to customers or regulators.
7. CAPA used as a form, not a problem-solving process
Typical issues:
- Corrective actions focusing on retraining or updating a procedure without addressing underlying design, process, or system issues.
- Root cause analysis done superficially, with no data verification or validation of the identified root cause.
- Effectiveness checks either not done, or done as a simple statement rather than using objective performance data.
Risk: Recurring issues persist, customers see the same nonconformities, and external auditors identify repeated findings over multiple cycles.
8. Supplier control focused on approval, not ongoing performance
Typical issues:
- Initial supplier approvals are thorough, but ongoing surveillance is minimal or based only on on-time delivery and overall PPM.
- Special processes, outside processing, and lower-tier suppliers not fully visible or controlled.
- Changes at the supplier (equipment, personnel, process, sub-tier sources) not detected until quality issues appear at incoming inspection or in the field.
Risk: AS9100 requirements for supplier control are met on paper, but real control is weak, especially for high-risk processes and critical characteristics.
9. Underestimating evidence expectations for audits
Typical issues:
- Relying on tribal knowledge instead of maintained records that show planning, execution, review, and improvement.
- Data dispersed across MES, ERP, QMS, spreadsheets, and email without clear linkage to orders, serial numbers, and configurations.
- Inability to quickly retrieve objective evidence for samples selected by the auditor, especially in older programs or legacy systems.
Risk: Auditors question the effectiveness of the QMS because the organization struggles to demonstrate what actually happened, even if the work was done correctly.
10. Neglecting legacy systems and brownfield realities
Typical issues:
- AS9100 procedures that assume clean, integrated systems when actual operations run on a mix of legacy MES/ERP, manual workarounds, and local spreadsheets.
- Interfaces between systems (e.g., ERP to MES, PLM to shop floor, QMS to calibration) not documented or validated.
- Attempts to “fix” gaps with a full system replacement that stalls due to validation burden, downtime risk, and integration complexity.
Risk: The documented QMS diverges from real information flows. Traceability, data integrity, and change control suffer, particularly during system changes or partial deployments.
11. Inadequate change management and validation for system changes
Typical issues:
- Changes to ERP, MES, QMS, PLM, or inspection software implemented without impact assessment on AS9100 processes.
- Insufficient validation or parallel runs before switching off old systems or tools.
- Poor communication of changes to operators, inspectors, planners, and engineers.
Risk: Unintended side effects produce silent failures in planning, traceability, or inspection records that appear months later as customer or regulator findings.
12. Training and competence treated as one-time events
Typical issues:
- Initial AS9100 training provided during implementation, then rarely refreshed or tailored to roles (e.g., operators vs planners vs buyers).
- Competence requirements defined generically and not aligned with actual process risks or special processes.
- On-the-job training not documented, making it difficult to prove competence for key tasks during audits.
Risk: Skill gaps persist in critical areas like configuration management, data entry, special processes, and problem solving, even though everyone has a training record.
13. Management review focused on slides, not decisions
Typical issues:
- Management review seen as an annual obligation, not a working mechanism to steer quality and risks.
- Metrics presented without clear actions, owners, and due dates.
- Inputs such as audit results, customer feedback, risks, and resource needs discussed, but not used to drive specific changes.
Risk: Top management appears committed formally, but there is little evidence that the QMS drives resource allocation, priorities, or systemic improvements.
Practical ways to avoid these mistakes
To reduce the likelihood of these common pitfalls:
- Map real processes first, then align them to AS9100 requirements, not the other way around.
- Assign clear process owners and make them accountable for performance, risk, and improvement.
- Integrate risk, configuration control, CAPA, and supplier oversight into existing planning and engineering workflows.
- Document and validate system interfaces and changes, recognizing legacy constraints and long equipment lifecycles.
- Use internal audits and customer feedback to test whether the QMS works in practice, not just on paper.
The specific controls and evidence needed will depend on your product mix, customer requirements, system landscape, and process maturity; the goal is not perfection against a template, but a QMS that reliably reflects and controls how you actually operate.
