Connect981 – Content Dev

RSC Sphere: Quality, Compliance and Traceability

The Quality, Compliance and Traceability Sphere demonstrates how audit-grade credibility is built directly into execution workflows. It connects nonconformance, corrective action, inspection, traceability, and audit evidence into a continuous operational loop. The content emphasizes how quality systems must interact with live work rather than exist as parallel documentation processes. This sphere proves that compliance and execution can reinforce each other instead of competing for attention.

  • Do all aerospace suppliers have to comply with AS9102 Rev C?

    No. Aerospace suppliers are not automatically required to comply with AS9102 Rev C. Compliance depends on what is contractually required by your customer and what your own quality system and procedures specify.

    When AS9102 Rev C typically applies

    AS9102 is a standard for First Article Inspection (FAI). In practice, you are expected to comply with AS9102 Rev C when one or more of the following are true:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • The customer (prime or Tier 1) explicitly invokes AS9102 on the purchase order, statement of work, or quality clauses.
    • Your customer’s quality requirements reference AS9102 and specifically call out Rev C.
    • Your organization’s QMS procedures state that FAIs will be performed to AS9102 (and those procedures are the basis for your internal or external audits).
    • You participate in a customer portal or digital FAI workflow (for example Net-Inspect) that has been updated to require Rev C forms and rules.

    If none of these apply, you are not automatically required to use AS9102, and you are not forced to move from Rev B to Rev C unless your customer or internal procedures say so.

    Contract and flowdown determine the obligation

    In regulated aerospace supply chains, the controlling documents are contracts, POs, and associated quality clauses. These define:

    • Whether FAI is required at all for a given part or assembly.
    • Which standard applies (AS9102 vs. customer-specific FAI formats).
    • Which revision (e.g., AS9102 Rev B vs. Rev C) and any customer-specific interpretations.
    • Scope and exceptions such as standard parts, commercial off-the-shelf items, or lower-risk hardware.

    Two similar parts for two different primes may have very different FAI expectations. You cannot safely generalize “all aerospace work must be AS9102 Rev C.” You need to treat this as a configuration-controlled requirement per customer, program, and sometimes per part family.

    AS9100 vs. AS9102: related but not identical requirements

    AS9100 (the aerospace QMS standard) expects that you control first article inspections in a structured way, but it does not itself force you to use AS9102 or a particular revision. Many primes use AS9102 as the default and flow it down, but that is a customer and industry practice, not a universal legal obligation.

    If you are AS9100-certified, your auditor will look for:

    • Evidence that you perform and control FAIs where required.
    • Alignment between your documented procedures and your actual practice.
    • Proper use of the standard you claim in your procedures (AS9102 Rev C if you say you follow Rev C).

    They do not automatically require AS9102 Rev C unless it is part of your documented system or customer flowdown.

    Common exceptions and edge cases

    Even when AS9102 Rev C is invoked, it often does not apply to every item you ship:

    • Standard parts / COTS: Many customers exempt standard hardware and catalog items. Check their quality clauses and the AS9102 exemption criteria.
    • Simple build-to-print machining and sheet metal: Some customers accept reduced-scope FAI packages or their own forms instead of full AS9102, especially for low-risk parts. Others do not. It is customer-specific.
    • Distributors and brokers: These organizations may not perform AS9102 FAIs themselves, but they may be required to collect and maintain FAI packages from upstream manufacturers.
    • Repair and MRO work: First article expectations can be different for repair/overhaul vs. new production. AS9102 may not be the controlling standard for MRO unless specifically invoked.

    Rev B vs. Rev C migration considerations

    Many suppliers operate in brownfield environments with a mix of AS9102 Rev B and Rev C requirements depending on customer and program. Some realities to account for:

    • Customer-by-customer transition: Some primes mandate Rev C on all new or changed parts; others are slower to transition and still accept Rev B FAIs. You may need to support both simultaneously.
    • Legacy FAI packages: Existing, accepted FAIs built under Rev B are rarely reworked just to meet Rev C, unless a significant design or process change triggers a new or partial FAI and the customer explicitly requires Rev C going forward.
    • System coexistence: Older PLM, MES, or QMS tools may embed Rev B assumptions (fields, forms, ballooning conventions). Updating to Rev C often requires careful configuration, validation, and controlled rollout to avoid mismatched forms and data loss.
    • Validation burden: In regulated, long-lifecycle programs, changing FAI processes or software (e.g., adopting digital AS9102 Rev C in Net-Inspect or another system) can trigger validation, retraining, and documentation updates. Many plants delay migration until a customer or major program forces the change.

    Practical steps for suppliers

    To avoid incorrect assumptions and rework, suppliers should:

    • Map requirements per customer and program: Maintain a controlled matrix that clearly lists which customers require AS9102, which revision, and any exceptions.
    • Lock this into your QMS: Ensure your FAI procedure references how you determine when to use AS9102 and which revision, rather than assuming a single rule fits all work.
    • Align systems and forms: Configure your FAI templates, digital FAI tools, or MES/QMS forms so they match the required revision and customer-specific rules. In mixed environments, provide clear operator guidance on which template to use when.
    • Control changes: Treat migration to Rev C as a formal change: update procedures, train staff, and preserve traceability between old and new formats. Avoid ad hoc switchovers that create confusion during audits.
    • Clarify ambiguous cases with customers: When requirements are silent or contradictory (e.g., AS9100 referenced but not AS9102; or Rev not specified), seek written clarification rather than guessing.

    Summary

    AS9102 Rev C is widely adopted but not universally or automatically mandatory for every aerospace supplier. Its applicability is defined by customer flowdown and your own QMS. Many suppliers must support both legacy and current revisions in a brownfield stack of systems and programs, which makes configuration control, change management, and traceability essential.

  • What makes a corrective action effective and auditable in aerospace CAPA?

    An aerospace corrective action is effective and auditable when it is transparently tied to root cause, proportionate to risk, controlled through documented changes, and proven in use with objective evidence. Auditors do not just look for a closed CAPA record; they look for a logical, traceable chain from problem detection through sustained effectiveness.

    1. Clear link from nonconformance to root cause

    Corrective action must start from a specific, documented problem:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • A defined nonconformance (NCR) or systemic issue with unique IDs.
    • Evidence of containment to protect current and delivered product.
    • A structured root cause analysis (e.g., 8D, RCCA, 5 Whys, fishbone) appropriate to the risk and complexity.

    For an auditor, an “effective” action is impossible to judge if the true root cause is unclear or mixed with symptoms. The CAPA record should show:

    • Problem statement, constrained in scope and fact-based.
    • Description of data used (defect trends, process history, FAI data, previous CAPAs, etc.).
    • Chosen root cause(s) and how each was validated or ruled out.

    2. Corrective actions that address the verified root cause

    An action is effective when it actually changes the conditions that allowed the issue, not just the defect instance. Typical characteristics:

    • Directly tied to root cause: Each action in the plan should trace back to a specific cause or contributing factor.
    • Risk-based: Actions must be proportionate to severity and occurrence (often linked to FMEA or similar risk tools).
    • Systemic in scope: Addresses all affected part numbers, routings, programs, and suppliers, not just the work order or lot that failed.
    • Preventive dimension: Where feasible, include design, process, training, or poka-yoke style changes that reduce recurrence likelihood.

    Auditors will challenge “actions” that are just reminders to be careful, operator re-training with no process change, or one-time sorting activities.

    3. Documented, controlled implementation

    In aerospace, corrective actions almost always touch controlled elements: work instructions, routings, tooling, inspection plans, software, supplier requirements, etc. For auditability, you need:

    • Formal action plan: Steps, owners, due dates, required approvals, and dependencies.
    • Change control: Evidence that affected documents and systems (QMS, MES, ERP, PLM, drawings, specs) were revised under your change management procedure.
    • Configuration management: Clear indication of which parts, serials, and date ranges are built under old vs new conditions.
    • Training and qualification: Training records, sign-offs, and where needed, qualification/recertification of operators or special processes.

    In brownfield environments, implementation often spans multiple legacy systems and paper processes. Your CAPA needs to show how changes were synchronized across those systems and how version mismatches are prevented or monitored.

    4. Objective evidence that the action is in use

    Auditors expect to see the corrective action embedded in day-to-day operations, not just documented on paper:

    • Updated work instructions visible and in force at the point of use (paper or digital).
    • MES/ERP routing or inspection steps updated and actually used in recent work orders.
    • Revised inspection plans or sampling schemes reflected in recent inspection records.
    • Tooling, fixtures, or software changes physically present and identified with correct revisions.

    Evidence can come from system logs, travelers, checklists, training systems, and operator interviews. In mixed digital/paper environments, auditors will look for consistency between records and actual practice.

    5. Demonstrated effectiveness over time

    The core test of effectiveness is sustained performance, not just immediate compliance. A robust CAPA typically includes:

    • Defined effectiveness criteria: For example, zero recurrences of the specific failure mode over a defined period or quantity, reduction in defect rate below a specified threshold, or improved process capability (Cp/Cpk) for the affected characteristic.
    • Monitoring plan: What data will be reviewed (NCR trends, scrap, rework, escapes, LPA findings, process audit results) and at what frequency.
    • Documented review: A dated effectiveness check entry that references data sources and explicitly states whether the criteria were met.
    • Escalation path: Clear rule for what happens if the action is not effective (new or extended CAPA, design review, supplier escalation, etc.).

    In many aerospace organizations, effectiveness review is a separate step and must be approved by quality leadership. Skipping or trivializing this step is a common audit finding.

    6. End-to-end traceability and record integrity

    For aerospace CAPA, being auditable is largely about traceability and data integrity:

    • Traceability chain: NCR → containment → root cause analysis → action plan → change records → training → verification → effectiveness review.
    • Cross-references: CAPA linked to affected part numbers, programs, contracts, customers, and related CAPAs or audits.
    • Immutable records: Version-controlled records with time stamps, user IDs, and change history (whether in QMS software, MES, PLM, or controlled spreadsheets).
    • Data integrity: Controls against backdating, uncontrolled overwrites, and undocumented edits. This is especially important where older systems and manual logs are still used.

    In brownfield plants, traceability frequently spans multiple tools: a QMS for CAPA, a separate MES for travelers, ERP for routings, and PLM for drawings. An auditor will often test one CAPA across these systems, so documented links and consistent identifiers are critical.

    7. Governance, ownership, and escalation

    Effective aerospace CAPA is not just technical; it requires visible management control:

    • Defined ownership: A named CAPA owner responsible for driving actions and reporting status.
    • Cross-functional involvement: Engineering, manufacturing, quality, supply chain, and sometimes supplier or customer reps as needed.
    • Management review: Periodic review of open/overdue CAPAs, repeat issues, and systemic themes at an appropriate leadership forum.
    • Prioritization by risk: Higher-risk CAPAs (safety, flight-critical, regulatory findings, customer escapes) receive faster, more rigorous treatment.

    Auditors often ask for examples of how CAPA information flows into management review and how management decisions have changed resourcing, process control, or system roadmaps in response.

    8. Fit to your specific QMS and system landscape

    What is “effective and auditable” is ultimately judged against your own QMS procedures and contractual or regulatory commitments. Two key implications:

    • Document what you really do: If your procedures over-promise relative to what your tools and staffing can support, you create built-in audit risk.
    • Align systems with process maturity: In mixed legacy/digital environments, it is better to show a realistic, controlled hybrid process than to claim a fully digital CAPA flow that does not exist in practice.

    Replacing all legacy systems at once to “fix” CAPA rarely works in aerospace due to validation burden, downtime risk, and integration complexity. Incremental steps that tighten traceability, standardize root cause analysis, and digitize high-risk areas first are usually more credible and sustainable, provided they are reflected in your controlled procedures.

  • How do you decide whether a change requires partial or delta FAI?

    There is no universal rule that fits every program or customer. The decision between a partial FAI and a delta FAI is driven by three things: the governing standard (AS9102 or equivalent), customer / contractual requirements, and your internal FAI and change-control procedures. Within those boundaries, the basic logic is to trace what changed and reverify only the characteristics and process elements affected by that change.

    Start from the governing requirements

    Before deciding scope, confirm:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • Which revision of AS9102 (or other standard) applies.
    • Customer-specific FAI or PPAP-like requirements, including any mandated triggers for full vs partial FAI.
    • Contract or PO language that may override your internal practice (for example, requiring full FAI when drawing revisions change, regardless of impact).
    • Your internal FAI procedure and how it defines initial, partial, and delta FAI, including required approvals.

    If there is a conflict, customer and contractual requirements typically take precedence over internal practice, as long as they do not contradict the base standard.

    When a partial FAI is typically required

    A partial FAI is generally used when the form, fit, or function could be affected, but not all characteristics or operations are impacted. Typical triggers (subject to customer rules) include:

    • Drawing, model, or specification revision that changes some, but not all, features.
    • Process flow or work instruction changes that impact a subset of characteristics, operations, or setups.
    • Significant NC/CAPA-driven changes where corrective actions modify methods, tooling, or parameters relevant to specific features.
    • Tooling, fixture, or program changes that could influence dimensions, orientation, or repeatability for targeted features.
    • Material or source changes that may affect mechanical, thermal, or surface performance for certain characteristics only.

    In a partial FAI you:

    • Use the current FAI format (e.g., AS9102 forms) for the part.
    • Identify only the characteristics and records impacted by the change.
    • Reverify and document those items, referencing the baseline (initial) FAI for unchanged characteristics.

    Unchanged characteristics are typically not re-measured but must still be traceable back to a previously accepted FAI package.

    When a delta FAI is typically sufficient

    In practice, many organizations use the term “delta FAI” for an even narrower scope than a formal partial FAI. This is usually appropriate when:

    • The change is extremely localized (e.g., a single dimension, tolerance, or note clarified without impacting related features).
    • A previously nonconforming characteristic has been corrected with no changes to the rest of the design or process.
    • A minor CNC program tweak, offset change, or fixture adjustment affects one or a few dimensions only.
    • Minor gage or method change affects how one characteristic is measured, not its underlying process capability.

    In a delta FAI you typically:

    • Document only the specific characteristics that changed or were corrected.
    • Reference the last accepted (initial or partial) FAI package as the baseline.
    • Show clear traceability from the change record (ECO, deviation close-out, CAPA) to the updated characteristic results.

    Some customers do not formally distinguish between “partial” and “delta” and expect any reduced-scope activity to follow their partial FAI rules. In those cases, treat delta FAI as a subcategory of partial FAI and align with their terminology to avoid audit issues.

    Risk- and impact-based decision process

    Most robust procedures use a structured impact assessment to decide whether you need full, partial, or delta FAI. A practical approach is:

    1. Identify the change driver
      Examples: drawing revision, model update, new material, process change, machine move, NC/CAPA, new supplier, or significant lapse in production.
    2. Map the change to affected items
      Using ECN/ECR, PLM, or configuration management, determine which of the following are touched:
      • Design characteristics (dimensions, GD&T, material specs, surface requirements).
      • Manufacturing operations, routings, or setups.
      • Tooling, fixtures, programs, or inspection methods.
      • Suppliers or special processes (heat treat, plating, NDT).
    3. Assess potential impact to form, fit, function, or safety
      If there is any plausible impact, err toward at least a partial FAI unless the customer has explicitly waived it.
    4. Define the FAI scope
      Based on the mapping:
      • Full FAI: major design change, new part number, new manufacturing site, or fundamentally different process path.
      • Partial FAI: multiple affected features, operations, or materials, but the part number and core design intent remain the same.
      • Delta FAI: tightly localized change or correction affecting one or a very small number of characteristics.
    5. Document the rationale
      Record why you chose partial vs delta (risk, impact analysis, customer requirements) and get appropriate approvals. This is often what auditors ask to see.

    Brownfield and system coexistence considerations

    In mixed PLM/MES/QMS environments, the main risk is missing impacted characteristics because design, routing, and inspection data are spread across systems. To make reliable partial/delta FAI decisions, you need:

    • Good configuration control so that the FAI is clearly tied to a specific drawing/model revision, routing, and work instruction set.
    • Traceable ballooning and characteristic lists that link drawing items to operations, tools, and inspection plans, even if those live in different systems.
    • Clear integration or at least stable reference IDs so that when an ECO hits the PLM, affected characteristics in MES or inspection software can be reliably identified.
    • Robust change control so process or tooling changes outside PLM (for example, on the shop floor or at suppliers) still trigger a formal FAI impact review.

    Trying to replace all core systems at once to “fix” FAI is usually impractical in aerospace-grade or similarly regulated environments due to validation, downtime, and integration risk. A more realistic approach is to tighten FAI and change-control linkages between existing PLM, QMS, and MES systems and then selectively digitize FAI forms and ballooning.

    Common pitfalls in deciding partial vs delta FAI

    Typical failure modes to watch for include:

    • Treating all changes as paperwork-only and skipping the impact analysis, which can lead to missed FAIs and audit findings.
    • Informal “delta” checks done on the shop floor without documentation or linkage back to the formal FAI package.
    • Under-scoping partial FAI, for example updating one dimension but ignoring related datums, patterns, or GD&T that are indirectly affected.
    • Over-reliance on tribal knowledge where a single engineer decides scope without a documented method or peer review.
    • Ignoring supplier changes (special processes, raw material mills, outside machining) that should trigger partial FAI at the supplier or at incoming inspection.

    Practical guideline to distinguish partial vs delta FAI

    Within the constraints of your customer and internal procedures, a practical rule-of-thumb is:

    • If the change affects multiple features, operations, or process steps, treat it as a partial FAI.
    • If the change is constrained to one or a very small number of characteristics, with no ripple effects, a delta FAI is usually sufficient.
    • If you are unsure about impact, or the part is safety-critical, default to the more conservative scope or obtain written customer concurrence on the chosen approach.

    Ultimately, the decision must be backed by a documented impact assessment, consistent with AS9102 and customer-specific expectations, and traceable in your QMS.

  • When should an aerospace nonconformance trigger a formal CAPA?

    A formal CAPA should be triggered when a nonconformance indicates a credible risk of systemic failure, safety or airworthiness impact, regulatory exposure, or recurring quality escapes. In aerospace, this decision must follow documented criteria in your quality system and be supported by objective evidence and risk assessment, not only by the severity of a single defect.

    Typical triggers for a formal CAPA in aerospace

    While specific thresholds belong in your internal procedures, aerospace organizations commonly require a CAPA when one or more of the following apply:

    • Safety or airworthiness impact is credible
      Nonconformances that could affect flight safety, structural integrity, or critical system performance, even if detected before shipment or installation. This includes issues on safety-critical characteristics, key characteristics, or special processes.
    • Regulatory or customer obligations are implicated
      Events that may require notification to aviation authorities or customers (e.g., potential reportable occurrence, significant escape, or field issue), or that are raised through regulatory or customer findings.
    • Evidence of systemic or process-level failure
      Nonconformances that indicate a breakdown of a controlled process, such as repeated similar defects, failures linked to the same operation, program, supplier, or design feature, or issues suggesting your FMEA/control plans are ineffective.
    • Repeat or clustered occurrences
      Same or similar nonconformances recurring within a defined period, lot, or configuration, even if each individual event is classified as minor. Clustering in time, product family, or workstation often indicates underlying systemic causes.
    • Formal findings from audits or inspections
      Major or repeated minor findings from internal audits, customer audits, or regulatory surveillance that point to ineffective controls, documentation, or previous corrective actions.
    • Supplier or sub-tier systemic issues
      Supplier nonconformances that show a pattern (e.g., multiple lots affected, multiple part numbers, repeated failures to meet agreed controls or special process requirements).
    • Field issues, escapes, or service disruptions
      Nonconformances discovered after delivery or installation, especially if they cause rework, AOG events, service disruption, or concessions that require engineering disposition across multiple units.
    • Failures of previous corrective actions
      Recurrence of a problem that was previously addressed by a corrective action, indicating that prior root cause analysis or fixes were incomplete or ineffective.
    • Risks to key business or program objectives
      Nonconformances that materially affect on-time delivery, cost, or contractual obligations (e.g., repeated scrapped high-value hardware, program-level delays tied to the same cause).

    When a nonconformance may stay at the local level

    Not every nonconformance should trigger a formal CAPA. In a mature system, many issues are addressed by contained corrective actions at the point of occurrence. In general, local correction and containment (without a full CAPA) can be appropriate when:

    • The event is clearly isolated and low risk to safety and airworthiness.
    • There is no pattern of recurrence in recent data for the same process, part, or supplier.
    • The cause is obvious, promptly eliminated, and effectively prevented through routine process control (e.g., work instruction clarification, minor fixture adjustment) without needing full root cause analysis.
    • It falls below defined thresholds in your risk and escalation matrix for cost, severity, detectability, or occurrence.

    Even in these cases, the nonconformance and decision not to open a CAPA should be recorded, traceable, and periodically reviewed so that patterns are not missed.

    Defining clear CAPA triggers in your QMS

    Because expectations differ by customer, regulator, and product line, the triggers for CAPA must be explicitly defined in your quality procedures, not handled ad hoc. Common good practices include:

    • Risk-based criteria
      Use a defined risk model (e.g., severity, occurrence, detection rankings) linked to decision rules, so CAPA decisions are consistent and auditable.
    • Data-driven thresholds
      Specify quantitative triggers such as a certain number of similar defects within a time frame, scrap/rework cost thresholds, or statistical signals from SPC or defect trend charts.
    • Category-based rules
      Define nonconformance categories that always require CAPA (e.g., critical characteristic escape, suspected counterfeit part, loss of special process control, unapproved repair on safety-critical hardware).
    • Explicit supplier escalation rules
      Clarify when supplier nonconformances escalate from SCAR or local actions into a formal CAPA within your own QMS.
    • Governance and review
      Have a cross-functional group (e.g., MRB, quality board, safety board) periodically review nonconformance data and confirm that triggers are being applied as intended.

    Brownfield and system coexistence considerations

    In most aerospace environments, nonconformance data, CAPA records, and risk assessments are distributed across multiple systems (MES, ERP, QMS, PLM, supplier portals) and sometimes paper. CAPA triggers will only work reliably if:

    • Nonconformances from all relevant sources are visible in one consolidated view or report.
    • Linkages between events, lots, part numbers, and processes are maintained so systemic issues can be detected.
    • Changes to triggers or escalation rules are managed under documented change control and, where applicable, validated before use.

    Attempts to replace legacy systems purely to improve CAPA triggering often run into qualification burden, downtime risk, and integration complexity. Many organizations instead overlay analytics and reporting on existing systems, and phase in changes under disciplined change control.

    Traceability and documentation expectations

    Regardless of whether a formal CAPA is opened, aerospace regulators and customers typically expect:

    • A clear record of the nonconformance, including classification and risk assessment.
    • Traceability from the event to the decision (why CAPA was or was not initiated).
    • Evidence of containment, disposition, and verification of any local corrective actions.
    • Periodic review of nonconformance data to confirm that CAPA triggers remain effective.

    Defining explicit, risk-based criteria and applying them consistently is usually scrutinized more closely than the absolute number of CAPAs opened.

  • What features should ISO 9001-focused QMS software include?

    ISO 9001 does not require any specific software, but in complex industrial and regulated environments most organizations use QMS software to make the system workable and auditable. An ISO 9001-focused QMS should support the full Plan-Do-Check-Act cycle, integrate with existing systems, and produce reliable evidence for audits without claiming compliance guarantees.

    Core document & record control

    At minimum, ISO 9001-focused QMS software should support:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Document control for QMS documents (procedures, work instructions, quality plans), including:
      • Version control with full revision history and change rationale
      • Approval workflows with role-based signoff and timestamps
      • Controlled release and effective dates
      • Obsolescence handling and access to prior revisions for traceability
    • Record management for quality records (inspection results, training records, audits, NCRs, CAPAs), including:
      • Retention rules and disposition tracking
      • Searchable metadata (part, order, supplier, process, date)
      • Secure storage with backup and disaster recovery controlled by IT

    In brownfield plants, document control often straddles shared drives, PLM, MES, and QMS. The QMS must either integrate with or clearly reference the system of record for each document type to avoid version conflicts.

    Risk-based thinking & context

    ISO 9001 emphasizes risk-based thinking, but not a specific tool. Practical capabilities include:

    • Risk registers for organizational, process, and product risks, with owners and review cycles
    • Configurable risk scoring (likelihood, impact, detectability) with your own scales and criteria
    • Linking risks to controls and actions (procedures, training, process controls, CAPAs)
    • Evidence of risk review during changes, new products, and major process revisions

    Some organizations use separate tools for FMEA, process hazard analysis, and enterprise risk. The QMS should at least reference where these live and provide traceable links so auditors can follow the logic from risk to control to evidence.

    Nonconformance, corrective action, and improvement

    ISO 9001 clauses on nonconforming outputs and improvement are a major driver for QMS software. Useful features:

    • Nonconformance management (NCRs), including:
      • Configurable NCR forms for product, process, and supplier issues
      • Classification by severity, area, customer, part, and process
      • Integration or at least mapping to ERP/MES data (work order, batch, lot, serial)
      • Support for MRB, deviations, and concessions with decision logging
    • Corrective and preventive actions (CAPA) with:
      • Structured workflows for containment, root cause analysis, action planning, effectiveness checks
      • Owner and due date tracking, escalations for overdue items
      • Links between NCRs, complaints, audit findings, and CAPAs
      • Analytics on trends, recurrence, and closure time
    • Continuous improvement tracking (beyond formal CAPA), such as improvement ideas, kaizen events, and problem-solving projects if your culture supports it.

    Many plants already have NCR workflows in MES or ERP. In those cases, the QMS may function as the CAPA and analysis layer, pulling or referencing defect and scrap data instead of replacing the operational system.

    Audit management and evidence trails

    To support internal audits, external audits, and customer visits, the QMS should provide:

    • Internal audit planning with schedules, scopes, and auditor assignments
    • Configurable checklists aligned to ISO 9001 clauses and your own processes
    • Findings and observations tracking linked to NCRs or CAPAs where needed
    • Audit trail and traceability for key QMS changes (who changed what, when, and why)
    • Evidence management so each requirement or process has linked records that can be shown in an audit without file hunting

    For regulated sectors, granular audit trails and immutable logs are especially important. The software must make it easy to demonstrate that the documented system matches the executed system, but it cannot itself guarantee audit outcomes.

    Training, competence, and awareness

    ISO 9001 requires control of competence, not a specific LMS. Helpful software capabilities:

    • Role- and job-based training matrices mapping roles to required competencies and courses
    • Training records with completions, expirations, and recurrent requirements
    • Linkage from document changes to training so procedure revisions trigger training updates and acknowledgments where appropriate
    • Support for multiple training channels (classroom, on-the-job, e-learning) with consistent record capture

    In plants where HR systems or learning platforms are already in place, the QMS may only hold critical quality-related training records or provide references and links, rather than duplicating all HR training data.

    Change management and configuration control

    Robust change control is critical in long-lifecycle and aerospace-grade environments. QMS software should support:

    • QMS change control for policies, procedures, and process descriptions, with impact assessments and approvals
    • Traceability from change requests to risk assessments, training, and updated documents
    • Visibility into upcoming and recently implemented changes for operations, quality, and IT

    Product configuration (BOM, CAD, technical data) usually lives in PLM or ERP. The QMS should integrate with or reference those systems rather than trying to replace them, particularly in aerospace and other regulated sectors where requalifying PLM or ERP is extremely costly.

    Customer focus, complaints, and feedback

    To meet ISO 9001 requirements for customer focus and feedback, the QMS should make it practical to:

    • Log and classify customer complaints and inquiries, with linkage to orders, parts, and lots
    • Initiate NCRs and CAPAs from customer issues and trace them to closure
    • Capture customer satisfaction metrics if you track them (OTD, quality performance, survey results)
    • Generate inputs for management review about customer-related performance and risks

    Where CRM or service systems already exist, the QMS often consumes complaint and return data via integration instead of acting as the front-end for customer interactions.

    Management review, KPIs, and performance data

    ISO 9001 expects structured management review and use of data. QMS software should help by providing:

    • Configurable dashboards and reports for NCs, CAPA status, on-time closure, audit findings, and key quality KPIs
    • Support for management review records: agendas, minutes, decisions, and actions with follow-up tracking
    • Ability to ingest or reference data from ERP/MES for scrap, rework, delivery performance, and returns

    In most plants, quantitative performance data still comes from ERP/MES and data warehouses. The QMS should focus on linking these metrics to actions, risks, and decisions, instead of trying to become the primary data platform.

    Integration in brownfield environments

    In regulated, long-lifecycle operations, QMS software usually has to coexist with an existing stack that is expensive and risky to replace. Realistic integration expectations include:

    • Reference, not replacement, of ERP/MES/PLM as systems of record for orders, parts, and technical data
    • APIs or file-based interfaces to exchange key identifiers (work order, serials, lots, supplier codes) for traceability
    • Configurable master data mappings that can be maintained under change control
    • Clear data ownership definitions to avoid duplicate or conflicting records across systems

    Full replacement strategies for ERP or MES just to deploy new QMS functionality often fail due to qualification burden, downtime risk, validation costs, and the complexity of re-establishing traceability. In most cases, a layered QMS that integrates with existing systems is a lower-risk option.

    Security, access control, and validation

    Especially in aerospace, defense, and other regulated sectors, QMS software should support:

    • Role-based access control with least privilege for viewing, editing, and approving records
    • Configurable electronic signatures for approvals where appropriate, aligned with your regulatory context
    • Comprehensive system logs for configuration changes, permission changes, and data changes
    • Support for validation and change control (test evidence, configuration documentation, and repeatable deployment practices)

    Security baselines, network segregation, and compliance with standards like ISO 27001 or NIST controls are typically governed by your broader IT policies, not the QMS alone. The QMS should fit into that framework rather than defining it.

    Configuration, flexibility, and limitations

    Finally, because every plant and quality system is different, practical ISO 9001-focused QMS software should be:

    • Configurable in workflows, fields, roles, and forms without deep custom code where possible
    • Transparent about what is configuration versus customization, so you can assess validation and lifecycle impact
    • Capable of exporting your data in usable formats, to avoid lock-in and support audits and investigations

    No QMS software can guarantee ISO 9001 certification or audit results. It can only support your processes, evidence, and discipline. The actual outcome depends on process maturity, training, leadership follow-through, and the quality of integrations and data.

  • What is an example of a non conformance?

    In a regulated manufacturing environment, a nonconformance is any verified departure from an approved requirement, specification, or procedure. It can relate to product, process, documentation, or data.

    Concrete examples of nonconformance

    • Dimensional out-of-tolerance part: A CNC-machined aerospace bracket is inspected and one critical hole diameter measures 10.12 mm against a drawing requirement of 10.00 mm ± 0.05 mm. The characteristic is clearly out of tolerance, so the part is nonconforming and must be segregated and dispositioned.
    • Wrong material used: A batch of medical device components is produced using stainless steel grade 304, but the approved bill of materials and material specification require 316L for corrosion resistance and biocompatibility. Even if the parts appear functional, they are nonconforming to the specification.
    • Unapproved process route: An operator skips a required in-process inspection step documented in the work instruction because the line is behind schedule. The product may pass later checks, but the process deviation itself is a nonconformance that must be recorded.
    • Using the wrong document revision: A technician builds an assembly using work instructions at Revision B, while the controlled document system shows Revision D as the current approved version. Any product built under the obsolete revision is nonconforming unless formally justified and accepted.
    • Environmental or equipment setpoint out of range: A validated oven used for cure cycles runs at 185 °C for a lot, while the validated and documented setpoint is 200 °C ± 5 °C. Even if later tests look acceptable, the cure process is nonconforming to the qualified parameters.
    • Labeling or traceability error: A pharmaceutical batch is labeled with an incorrect expiry date or missing lot number, breaking traceability requirements. The labeling defect is a nonconformance regardless of product quality.

    Why context and systems matter

    Whether an issue is treated as a nonconformance depends on how requirements are defined and controlled in your own systems: drawings, specifications, work instructions, MES routes, ERP master data, and QMS procedures. In brownfield plants with multiple legacy systems, misalignment between these sources is a common root cause of nonconformances.

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    Because equipment, software, and documentation are often validated and tightly controlled, even seemingly minor deviations (for example, using a not-yet-approved parameter change to reduce scrap) must be logged as nonconformances instead of treated as informal experiments. Replacement of systems just to “eliminate” nonconformances usually fails if requirements and change control are not cleaned up at the same time.

    In all cases, the key is traceability: you need to be able to show which requirements were violated, how the nonconformance was detected, what the disposition was (scrap, rework, use-as-is with justification, concession), and what corrective and preventive actions, if any, were taken.

  • What are the most significant additional AS9100 requirements beyond ISO 9001?

    AS9100 is built on ISO 9001, not separate from it. If you implement AS9100, you must first meet ISO 9001, then address additional aerospace-specific requirements. The exact impact depends on your scope (design vs build-to-print vs MRO), customer contracts, and current process maturity.

    1. Product safety and FOD (Foreign Object Debris) control

    AS9100 adds explicit requirements around product safety that go well beyond ISO 9001’s generic risk language:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • Defined product safety policies and responsibilities.
    • Controls to prevent, detect and remove FOD throughout manufacturing, assembly, test and packaging.
    • Training and awareness specific to product safety and FOD (signage, housekeeping, point-of-use controls).
    • Documented FOD prevention procedures and records of inspections or sweeps where risk is high (e.g., fuel systems, flight controls).

    In brownfield plants this often drives changes to layout, housekeeping standards, tool control, cleaning and inspection steps, and how work instructions, MES and checklists capture FOD checks.

    2. Risk management beyond ISO 9001 “risk-based thinking”

    ISO 9001 requires risk-based thinking in a general sense. AS9100 goes further and expects structured risk management for product realization:

    • Formal risk assessment and mitigation for key processes and programs (e.g., PFMEA or equivalent).
    • Risk reviews at defined stages (bid/no-bid, contract review, design reviews, industrialization, major changes).
    • Actions to reduce risk tied into planning, work instructions and control plans.
    • Monitoring of risk and effectiveness of mitigations over the program life, not just at launch.

    Practically, this usually requires linking engineering, program management and operations planning tools, or at least ensuring that risk registers are actually reflected in routing steps, inspection plans and traveler content.

    3. Configuration management

    AS9100 requires an explicit configuration management process, beyond normal document control:

    • Defined configuration items (part numbers, assemblies, software, documents) and their relationships.
    • Clear rules for baselining configurations for contracts and serial numbers.
    • Control of changes to configuration, including impact analysis and approvals.
    • Ability to show which configuration is built into which unit (as-built configuration traceability).

    In a mixed ERP/MES/PLM/QMS environment, this can be difficult. AS9100 does not mandate specific tools, but auditors expect that engineering changes, travelers, work instructions and inspection plans align, and that you can trace which revision was used for a given serial number.

    4. Counterfeit parts prevention

    AS9100 introduces specific requirements to prevent counterfeit or suspect parts entering the supply chain:

    • Documented counterfeit parts prevention program.
    • Controls on sources of supply, particularly for electronic components and high-risk commodities.
    • Verification methods (certifications, testing, traceability back to original manufacturers or authorized distributors).
    • Segregation, reporting and disposition process for suspect or confirmed counterfeit material.

    This frequently forces tighter supplier qualification, increased incoming verification, and better linkage between purchasing data, receiving inspection and nonconformance workflows across ERP, QMS and supplier portals.

    5. Special processes and process validation

    AS9100 pays particular attention to special processes where results cannot be fully verified by subsequent inspection (e.g., heat treatment, NDT, plating, welding):

    • Defined criteria and approval processes for special process suppliers.
    • Qualification and periodic requalification of processes, equipment and personnel.
    • Detailed records to demonstrate conformity of each batch or lot (parameters, certifications, operator qualifications).
    • Flowdown of customer and regulatory special process requirements to internal and external providers.

    In brownfield operations, these controls often live partly on paper, partly in vendor portals, and partly in MES or QMS. AS9100 increases scrutiny on consistency, traceability and evidence that the validated process is the one actually being run.

    6. More prescriptive supplier control and flowdown

    ISO 9001 requires control of external providers. AS9100 adds aerospace-specific expectations:

    • Risk-based supplier selection and monitoring, including on-time delivery, quality performance and special approvals (e.g., Nadcap, customer approvals where applicable).
    • More detailed purchasing data and technical flowdown (configuration, key characteristics, special processes, inspection requirements, FAI expectations).
    • Verification of purchased products at supplier or upon receipt, sometimes including delegated inspection programs.
    • Control of sub-tier suppliers and flowdown of applicable requirements.

    These requirements usually drive updates to purchasing templates, PO terms, supplier scorecards and integration between ERP, QMS and supplier portals. Poor integration or incomplete data often becomes visible under AS9100 audits.

    7. Product realization planning and first article expectations

    While AS9100 does not equal AS9102, it reinforces structured planning of product realization:

    • More detailed planning from contract review through manufacturing, including control of key characteristics and inspection points.
    • Clear definition of verification, validation and testing activities, including acceptance criteria.
    • Stronger expectation that new parts and major changes follow a controlled introduction process that typically includes first article inspection (FAI) following AS9102 when required by customer or contract.

    Plants with many legacy parts often need to reconcile historical practices with current AS9100 and AS9102 requirements, especially when customers change their expectations mid-program.

    8. Preservation, packaging and delivery controls

    AS9100 tightens expectations on preserving product conformity after inspection and test:

    • Environmental controls (humidity, temperature, cleanliness) where they affect product integrity.
    • Packaging methods that protect against physical, ESD or contamination damage.
    • Traceable labeling that supports configuration, lot and serial tracking throughout the supply chain.
    • Control of storage life and shelf-life items, including rotation and reinspection as applicable.

    For many sites, this requires better linkage between inventory management, labeling, and quality records, and may expose gaps in how ERP and physical warehouse practices align.

    9. Expanded control of nonconforming product and concessions

    ISO 9001 already requires control of nonconforming outputs. AS9100 adds more rigor:

    • Defined criteria for use-as-is and repair dispositions, often with stronger engineering involvement (MRB).
    • Formal customer notification and approval for concessions/deviations where required contractually.
    • More emphasis on trend analysis of nonconformities and escape prevention, not just individual fixes.

    In practice, this often exposes weaknesses in paper-based MRB, email-based deviation approvals and fragmented CAPA systems. Digital NCR/MRB workflows and traceable approval trails become more important, especially across long product lifecycles.

    10. Human factors and awareness

    AS9100 calls out human factors explicitly when establishing, implementing and maintaining processes for nonconformity and corrective action, and in other risk-related areas:

    • Considering fatigue, stress, training, and work environment when analyzing causes of defects or escapes.
    • Reinforcing awareness of individual contributions to product safety, quality and regulatory compliance.

    This typically affects how you conduct root cause analysis, design training and communicate with the shop floor, rather than adding new standalone procedures.

    11. Quality management system documentation and records

    AS9100 keeps ISO 9001’s more flexible stance on documentation, but aerospace expectations are less forgiving in practice:

    • Greater emphasis on documented, repeatable processes where risk is high (special processes, configuration changes, MRB, FAI, software and firmware handling).
    • Robust control of documented information across long equipment and program lifecycles.
    • Traceable records that can be produced quickly for audits, customer investigations and incident reviews.

    For brownfield sites with mixed paper and digital systems, this can be a major challenge. Full replacement of legacy systems is rarely feasible due to validation cost, downtime and integration risk, so most organizations incrementally digitize high-risk workflows while keeping compatible paper or hybrid records where necessary.

    12. No guarantee of compliance, and strong dependence on context

    AS9100 describes what needs to be controlled, not exactly how. Two plants can both claim AS9100 alignment yet implement controls very differently. The impact of “additional requirements beyond ISO 9001” depends heavily on:

    • Scope of activities (design authority vs build-to-print vs MRO).
    • Existing maturity of configuration management, supplier quality and risk management.
    • Legacy systems (ERP, MES, PLM, QMS) and how well they are integrated and validated.
    • Customer-specific flowdowns and regulatory obligations (e.g., defense vs commercial).

    No tool or template can guarantee AS9100 certification or specific audit outcomes. Organizations typically move iteratively: bring current practices into line with the standard, close obvious gaps, then use internal audits and customer feedback to refine controls over time.

  • How often should aerospace organizations review their risk register?

    There is no single mandated review frequency that fits every aerospace organization, but in regulated, complex environments a multi-layered cadence is usually expected.

    Typical baseline cadences

    For most aerospace manufacturers, MROs, and system integrators, a practical pattern looks like:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • Quarterly formal review of the enterprise or site-level risk register, tied to management review, internal audits, or steering committee meetings.
    • Monthly operational review of high and emerging risks in production, MRO, supply chain, and IT/OT security, often embedded in existing performance or safety meetings.
    • Event-driven updates any time a significant change or incident occurs, such as configuration changes, process transfers, major quality escapes, supply disruptions, or cybersecurity events.
    • Annual deep-dive reassessment of the overall risk framework, criteria, and assumptions, often aligned with QMS, SMS, or ISMS review and strategic planning.

    The register should be treated as a living artifact. If risks and mitigations remain unchanged between reviews, that should be explicitly confirmed and documented, not assumed.

    Factors that should drive review frequency

    The appropriate cadence depends on your specific context. Common drivers include:

    • Program phase and lifecycle: Development, industrialization, and ramp-up typically justify more frequent reviews than stable, mature production, because design, suppliers, and processes are still changing.
    • Regulatory and customer expectations: Commitments under AS9100, internal process audits, OEM/customer contracts, and aviation authority expectations can implicitly set minimum review expectations, especially where safety or continued airworthiness is involved.
    • Risk profile and tolerance: Safety-critical systems, complex assemblies, and software-heavy products often require tighter monitoring than lower criticality parts or services.
    • Change volume: High rates of engineering change, supplier churn, site transfers, or digital transformation justify more frequent reviews because underlying assumptions age quickly.
    • Incident history: Repeated escapes, audit findings, cyber incidents, or recurring supply issues are strong signals that the risk register is stale or incomplete and needs more frequent attention.
    • System maturity: Organizations with integrated QMS/MES/ERP and strong metrics can review efficiently and more often. Fragmented, manual environments may be forced into less frequent but more intensive reviews, with higher risk of blind spots.

    Brownfield and system coexistence considerations

    In brownfield aerospace environments, risk data is typically scattered across QMS, MES, ERP, PLM, safety management systems, and spreadsheets. Review cadence and quality are constrained by:

    • Integration gaps: If nonconformances, CAPA, maintenance data, and supplier performance are not linked to the risk register, reviews rely on manual compilation and expert memory, which slows frequency and can miss systemic risks.
    • Legacy tools: Older QMS or risk tools might not support easy re-prioritization or trending, so organizations gravitate to quarterly or annual reviews simply because it is operationally manageable.
    • Validation and change control: Introducing or modifying digital risk tooling in aerospace often requires validation, qualification, and formal change control. This is one reason why full replacement of legacy risk tools is rare; incremental integration and overlay approaches are more realistic.
    • Downtime and data availability: MES or ERP downtime, data quality issues, or delayed batch uploads can impact when risk analyses are credible. Some sites time reviews around known data availability windows.

    Because full system replacement is difficult in long-lifecycle aerospace environments, many organizations end up with a hybrid model: the “official” risk register in a QMS or governance tool, supplemented by operational risk views derived from MES, maintenance, or supplier data. Review cadence must acknowledge this split and ensure both views are reconciled.

    Minimum practical expectations

    Given typical aerospace risk, traceability, and compliance obligations, it is difficult to justify reviewing an enterprise or site-level risk register less frequently than:

    • Quarterly for formal, documented review of significant operational, quality, safety, and cybersecurity risks, with evidence of updated status and actions.
    • Immediately after major events, such as significant escapes, accidents or serious incidents, large-scale rework or scrap, critical supplier failure, or material OT/IT security events.

    Some organizations choose monthly formal reviews during high-risk periods (e.g., industrialization, certification, first article for new programs, major facility moves), then relax to quarterly once the risk profile stabilizes.

    Practical ways to operationalize the cadence

    For leadership teams in manufacturing, quality, and IT/OT, a workable approach is to:

    • Define clear triggers that force an out-of-cycle update, such as yield drops beyond a threshold, repeated NCRs on a key characteristic, or changes to critical software or OT assets.
    • Align reviews with existing forums such as management review, internal process audits, safety boards, and cyber risk committees, so risk register updates leverage work already being done.
    • Use stratified views: keep one master risk register but maintain filtered views for production, MRO, supply chain, and IT/OT, so each function can review at an appropriate cadence without fragmenting the source of truth.
    • Link to data where possible: even partial integration with MES, QMS, and supplier data helps focus reviews on risks that are actually moving.
    • Document rationale: when the cadence or scope of review is adjusted (e.g., from monthly to quarterly), record the justification and supporting evidence, since this is often probed in audits and customer reviews.

    Ultimately, the right frequency is the least intensive cadence that still gives leadership early warning of deteriorating conditions, within the constraints of existing systems, validation requirements, and resource limits.