Connect981 – Content Dev

RSC Topic: Nonconformance Management and MRB

  • First-Pass Containment

    First-pass containment commonly refers to the immediate actions taken to isolate, identify, and control potentially nonconforming product, material, or process output as soon as an issue is detected. Its purpose is to prevent further use, shipment, or processing of affected items while the organization verifies scope and decides on next steps.

    In manufacturing and regulated operations, first-pass containment is an initial control step, not a final disposition. It may include stopping a line or operation, segregating stock, placing inventory on hold, tagging affected units, blocking transactions in MES or ERP, or increasing inspection on suspect lots. The exact actions vary by process and quality system.

    The term generally includes short-term actions performed before full root cause analysis is complete. It does not by itself mean the issue has been corrected, that corrective action is complete, or that all affected material has been fully identified.

    What it includes

    • Immediate control of suspect product or process output

    • Temporary measures to reduce further escape or use

    • Initial scoping of affected lots, serial numbers, work orders, or time windows

    • Communication to operations, quality, and sometimes suppliers or customers when relevant

    • System-level holds or status changes to preserve traceability and prevent movement

    What it does not include

    • Formal root cause determination

    • Permanent corrective action

    • Final material review or disposition

    • Verification that recurrence risk has been eliminated

    Operational meaning

    In daily workflows, first-pass containment often appears as the first documented response after a defect, test failure, process deviation, or supplier issue is found. Quality teams may open an NCR, place affected inventory in quarantine, trigger additional inspections, and use traceability records to identify where else the issue could exist. In digital environments, containment can also involve transaction locks, alerts, genealogy review, and status changes across MES, ERP, or QMS records.

    Common confusion

    First-pass containment is often confused with correction, corrective action, and disposition.

    • Correction is the action taken to fix a detected problem or affected item.

    • Corrective action addresses the underlying cause to reduce recurrence.

    • Disposition determines what happens to the affected material, such as rework, scrap, return, or use-as-is approval where applicable.

    Containment comes earlier and is mainly about immediate control.

  • NCR response time

    NCR response time commonly refers to the elapsed time between the creation of a nonconformance report or nonconformance record (NCR) and a defined response point in the organization’s workflow.

    The exact endpoint varies by company or system. It may mean time to initial review, time to containment decision, time to disposition, or time to formal closure response. Because of that, the term is best understood as a timing metric for nonconformance handling, not as a single universal standard.

    What it includes

    In manufacturing and quality systems, NCR response time is usually tracked as a workflow measure tied to how quickly an issue is acknowledged and acted on after a defect, deviation, or nonconforming condition is identified. Depending on local definitions, it can include:

    • time from NCR creation to quality review
    • time to assign ownership
    • time to implement immediate containment
    • time to complete disposition or investigation
    • time to issue a supplier response in supplier-related NCR workflows

    It does not automatically mean full corrective action completion unless the process explicitly defines it that way.

    What it is not

    NCR response time is not the same as overall CAPA cycle time, MRB turnaround time, or rework completion time, although those measures may be related. It is also not the same as defect rate or scrap rate. Response time measures speed of handling an NCR, while those other metrics measure quality outcomes, downstream decisions, or production impact.

    How it appears in systems and workflows

    In MES, QMS, ERP-integrated quality modules, or supplier portals, NCR response time often appears as a timestamp-based KPI or SLA-style internal target. Typical workflow events used to calculate it include record creation date, first review date, disposition date, and closure date.

    Teams may use it to monitor backlog, escalation risk, aging nonconformances, and responsiveness across internal departments or suppliers. In regulated environments, the metric is often important because delayed responses can affect segregation, traceability, investigation timing, and evidence quality.

    Common confusion

    NCR response time is commonly confused with NCR resolution time. Response time usually refers to how quickly the NCR receives attention or a defined first action. Resolution time usually refers to how long it takes to complete the full process through disposition, correction, or closure.

    It can also be confused with CAPA response time. An NCR may trigger CAPA, but the two are not identical. NCR handling addresses a specific nonconformance record, while CAPA addresses corrective and preventive actions at a broader system or root-cause level.

  • What is an appropriate level of concession volume for a mature program?

    There is no single acceptable concession volume that applies across all mature programs.

    In general, a mature program should not rely on concessions as a routine operating mechanism. Concession volume should be low, stable, and trending downward or at least remaining within a clearly understood control band. If concessions become a normal path to ship product, that usually indicates unresolved process capability issues, design tolerance problems, supplier variation, inspection escape patterns, or weak change control.

    That said, the right threshold depends on context, including:

    • product criticality and risk tolerance
    • customer and contractual requirements
    • whether the program is production, sustainment, repair, or spares-heavy
    • process capability and measurement system quality
    • supplier quality performance
    • how a concession is defined, classified, and counted in your quality system

    So the practical answer is not a benchmark percentage by itself. The better question is whether concession volume is expected, exceptional, and explainable.

    What good looks like

    For a mature program, concession activity is usually appropriate when all of the following are true:

    • most concessions are isolated rather than repetitive
    • repeat concessions on the same part family, operation, tool, or supplier are rare
    • each concession has clear technical rationale and disposition traceability
    • there is visible linkage to corrective action when recurrence crosses a defined threshold
    • the business is not using concessions to mask chronic scrap, rework, planning instability, or schedule pressure

    If recurring concessions are common, the program may still be shipping product, but it is not operating in a mature state in any meaningful quality or execution sense.

    What to measure instead of asking for a single number

    A raw concession count can be misleading. A better assessment uses a small set of normalized measures such as:

    • concessions per 100 units, lot, or work orders
    • concessions by defect type, process step, and part family
    • repeat concession rate within a defined time window
    • concessions tied to supplier-caused versus internal-caused nonconformances
    • cost, cycle time, and queue impact of concession processing
    • share of concessions closed with permanent corrective action versus administrative closure only

    This matters because a low count can still hide significant risk if the same issue recurs on critical hardware, while a higher count in a complex sustainment environment may be understandable if tightly controlled and non-repetitive.

    When concession volume is too high

    Concession volume is probably too high for a mature program if any of these patterns appear:

    • the rate is flat or increasing after process stabilization
    • the same dimensions, features, documents, or suppliers drive repeated concessions
    • MRB capacity is overloaded and becomes a production bottleneck
    • engineering spends material time reviewing predictable issues that should have been designed out or controlled out
    • operators or supervisors expect concessions as part of normal completion
    • schedule recovery depends on concession approval speed

    At that point, the issue is not just quality. It is also capacity, cost of poor quality, and evidence that process learning is not being converted into standard work, tooling changes, supplier controls, or design updates.

    Brownfield reality

    In many regulated plants, concession volume is distorted by system fragmentation. The same event may touch MES, ERP, QMS, and MRB workflows differently, and some plants still carry part of the record in paper or spreadsheets. That means your concession baseline may be unreliable until definitions, data capture, and workflow ownership are cleaned up.

    Because of that, full system replacement is usually not the first answer. In long lifecycle, qualified environments, replacement programs often fail or stall due to validation effort, downtime risk, integration complexity, and the burden of preserving traceability across legacy records. A more realistic path is often to standardize definitions, improve routing and evidence capture, and integrate existing systems well enough to separate true concession demand from administrative noise.

    Practical guidance

    An appropriate level for a mature program is the lowest level that is sustainable without pushing risk downstream, while keeping each concession exceptional, justified, and traceable.

    If you need a management rule, use this one: concessions in a mature program should be rare enough that recurrence stands out quickly, not common enough that people stop noticing. Set internal thresholds by product family and risk class, then review trend, recurrence, and operational impact together rather than relying on a generic industry target.

    No single concession percentage can tell you whether the program is healthy. Recurrence, concentration, and dependence on concessions for routine output are usually the more important signals.

  • When should a concession be raised instead of closing an NCR with rework?

    A concession should be raised when you intend to accept or ship a known nonconformance without fully bringing the item back to all specified requirements through approved rework. If the part can be restored to conforming condition by defined rework, and that rework can be verified and documented, then you normally close the NCR with rework, not concession. The boundary matters because a concession is an acceptance decision for remaining nonconformance, not a synonym for disposition paperwork.

    Practical rule

    Use rework to return the item to the original approved requirement. Use a concession when the item will remain nonconforming in some respect but is being proposed for acceptance based on risk review and approval. In many regulated environments, a repair can also trigger concession or deviation workflows if the repair changes the design intent, performance basis, inspection method, or approved process path. Local procedure and customer terms decide that line, so do not assume your internal NCR form is enough.

    When concession is usually appropriate

    • The part, assembly, or document record will not fully meet drawing, specification, or process requirements after disposition.
    • A repair is proposed instead of rework, meaning the item is made usable but not restored exactly to original requirements.
    • The customer, design authority, or MRB process requires formal use-as-is or repair acceptance.
    • The nonconformance affects fit, form, function, life, reliability, maintainability, interchangeability, or contractual configuration in a way that needs explicit approval.
    • The product has already moved downstream or been delivered, and acceptance of the condition must be formally recorded and authorized.
    • The requirement cannot be objectively re-verified after correction, or evidence of full restoration is weak.

    When concession is usually not appropriate

    • The issue can be corrected by approved rework that returns the item to the original requirement.
    • Inspection or test can confirm the item now fully conforms.
    • The change is only administrative, such as a correctable documentation error, and your procedure allows controlled record correction without accepting product nonconformance.
    • The team is using concession to avoid scrap, schedule pressure, or repeated rework approvals without a real technical basis for acceptance.

    Common mistake

    The common mistake is treating concession as a convenient way to close difficult NCRs. That is risky. It can hide recurring process failures, bypass proper design authority review, and weaken traceability. In regulated operations, auditors and customers usually look hard at repeated use-as-is or repair dispositions because they often signal process capability, planning, supplier, or training problems that should be escalated through CAPA or RCCA.

    What decides the boundary in practice

    The answer is not purely definitional. It depends on your quality procedure, MRB authority, customer flowdown, product criticality, and sometimes program-specific clauses. Aerospace and similarly controlled sectors often require stricter approval paths for concession than for straightforward rework. Some customers reserve concession approval to themselves or to the design authority. Others allow internal approval only within narrow limits.

    You also need clean configuration and traceability data. In brownfield plants, NCR, MES, ERP, PLM, and QMS records often do not align cleanly. That creates a real failure mode: the shop closes an NCR as rework in MES, while QMS or customer paperwork treats the same event as repair or concession. That mismatch causes evidence gaps later. If your systems are fragmented, manual reconciliation and change control are usually still necessary.

    Questions to ask before choosing concession

    • After disposition, will the item fully meet the original requirement?
    • Is the proposed action rework, or is it really a repair or use-as-is decision?
    • Who has authority to approve that decision under contract and procedure?
    • Does the condition affect safety, performance, life limit, certification basis, or interchangeability?
    • Can the final state be objectively verified and traced in the product record?
    • Does this event indicate a recurring issue that also needs CAPA or supplier action?

    Bottom line

    Raise a concession when the product will be accepted with a known remaining departure from requirement, or when a repair or use-as-is decision needs formal approval beyond normal rework closure. Close the NCR with rework only when approved rework restores full conformity and that conformity is verified. If the distinction is unclear, treat it as an authority and traceability question, not just a paperwork choice.

  • How does traceability to aircraft tail number affect non-conformance management?

    Tail-number-level traceability does not change the basic steps of non-conformance management, but it raises the bar on precision, data quality, and cross-system integration. Every non-conformance must be evaluated in the context of a specific aircraft configuration, usage history, and regulatory exposure.

    What tail-number traceability actually changes

    When you can link parts and operations directly to an aircraft tail number, non-conformance management is affected in several ways:

    • Containment scope becomes aircraft-specific: You are not just asking which lots or serials are affected, but which specific aircraft currently carry them and where those aircraft are in the world and in the maintenance cycle.
    • Risk assessment is tied to real operating context: The same defect can imply very different risk depending on aircraft usage, environment, remaining life on the part, and modification status. Tail-number traceability lets you factor this in, if the data and integrations are mature enough.
    • Configuration status matters more: Non-conformance impact analysis must consider the exact build standard and retrofit status of each aircraft, not just a generic part number. That drives the need for tight linkage between manufacturing genealogy, engineering configuration, and fleet configuration records.
    • Regulatory and customer notifications are more targeted: Instead of broad population assumptions, you can identify the exact aircraft, operators, and authorities potentially affected. This improves focus but requires high confidence in your trace data and reconciliation processes.

    Implications for non-conformance workflows

    With tail-number-level traceability, several aspects of the non-conformance workflow become more demanding:

    • Problem identification and scoping: Root cause and impact analysis must trace from the detected defect back through part genealogy and forward into the fielded fleet. This often spans MES, ERP, PLM, MRO/CMMS, and operator records.
    • Disposition decisions: MRB decisions (use-as-is, rework, scrap, concession) must explicitly consider downstream impact on specific aircraft. A use-as-is decision may be acceptable for some tail numbers and unacceptable for others, depending on mission, environment, or contractual terms.
    • Corrective actions and service bulletins: CAPA and service bulletin planning must use tail-number data to define which aircraft are in scope and which maintenance events can practically incorporate the fix. Poor integration between manufacturing and in-service records can create blind spots.
    • Documentation and evidence packs: Audit trails, concessions, and repair dispositions must be traceable from the non-conformance record to the individual aircraft and its configuration at the time of installation and any subsequent modifications.

    Data and system requirements in brownfield environments

    Tail-number traceability only helps non-conformance management if the underlying data and integrations are reliable. In most brownfield environments, there are significant gaps:

    • Fragmented genealogy: Part genealogy may sit in MES, test systems, and spreadsheets, while aircraft configuration and tail-number assignments live in separate MRO, ERP, or operator systems.
    • Legacy system constraints: Older MES/ERP systems may not natively model tail number or may use custom fields that are inconsistently populated. Retrofitting full, validated integration is non-trivial and must go through change control.
    • Handoffs between manufacturing and in-service records: The handover from production to fleet management is often manual or batch-based. Misaligned serials, part supersessions, and incomplete installation records can break the chain from non-conformance to tail number.
    • Validation and change control burden: Any attempt to “fix” this by replacing core MES/ERP/PLM with a new platform usually faces long validation cycles, qualification testing, downtime risk, and heavy integration effort. Incremental integration and overlay strategies are more realistic in most regulated fleets.

    Because of these realities, organizations often achieve practical tail-number traceability for non-conformance management through:

    • Incremental integration between existing MES/ERP and fleet/MRO systems.
    • Strict rules for serial number capture, installation recording, and data reconciliation.
    • Controlled data marts or traceability services that unify identifiers across systems without trying to fully replace them.

    Risk assessment and containment with tail-number visibility

    When the data chain is intact, tail-number-level traceability improves containment and risk decisions:

    • Faster detection of affected aircraft: Once a defect is found on a batch or process step, you can rapidly enumerate all aircraft potentially affected through part/lot/serial-to-tail mappings.
    • More precise containment actions: Instead of grounding or inspecting an entire fleet or series, you can define a smaller, better-justified affected set, with clear rationale linked to genealogy and configuration.
    • Prioritized response: Tail-number data allows prioritization by mission profile, utilization rates, or operator constraints, if those data are accessible and governed.

    The tradeoff is that your non-conformance process becomes critically dependent on data integrity and cross-system synchronization. Inconsistent serial tracking, unrecorded substitutions, and local workarounds will directly undermine your ability to trust tail-number-based impact analysis.

    Recordkeeping, audits, and long lifecycle considerations

    Aircraft and major components have long service lives, so tail-number-traceable non-conformance records need to be durable and navigable over decades:

    • Long-term accessibility: Non-conformance, concession, and repair records must remain accessible and understandable across multiple system generations, mergers, and IT migrations.
    • Change history and genealogy continuity: Component replacements, overhauls, and modifications must not break the chain of traceability back to original non-conformances and their dispositions.
    • Evidence for regulators and customers: During investigations or audits, you may be asked to show how a specific tail number was affected by a known defect and what mitigation was applied. This relies on consistent identifiers, governed interfaces, and validated reporting, not on any single application.

    Why full system replacement rarely solves the problem on its own

    In many aerospace-grade environments, trying to solve tail-number traceability gaps by replacing MES, ERP, or PLM end-to-end often fails or underdelivers. Typical challenges include:

    • High qualification and validation burden for safety- or quality-critical systems.
    • Downtime and cutover risk for production and maintenance operations that cannot easily stop.
    • Integration complexity across suppliers, partners, and legacy tooling that are not being replaced.
    • The need to preserve historical genealogy and non-conformance data across system boundaries for decades.

    As a result, improving non-conformance management with tail-number traceability is usually achieved through carefully governed integrations, data quality initiatives, and workflow refinements on top of the existing system landscape, rather than wholesale platform replacement.

  • How do regulators view post-factum reclassification of nonconformances as deviations?

    Usually badly, unless the original classification was clearly incorrect and the reclassification is handled under a defined, approved process with full traceability. In most regulated manufacturing environments, a nonconformance identified after the fact is not something you simply relabel as a deviation to make the record cleaner. Regulators, customers, and auditors are likely to ask whether the change reflects a legitimate correction of classification or an attempt to avoid disposition, CAPA, reporting, scrap, or customer notification.

    Why this draws scrutiny

    A deviation is typically prospective: permission to depart from an approved requirement before or during execution, under controlled conditions. A nonconformance is typically retrospective: evidence that product, process, documentation, or execution did not meet requirements. Those are not interchangeable labels.

    When a site reclassifies a recorded nonconformance as a deviation after the fact, the immediate concern is not semantics. It is whether the organization is rewriting quality history. If the event already occurred and affected product or records, the burden is on the site to show why the original record type was wrong, who approved the correction, what risk review was performed, and whether the product impact remains fully assessed.

    What is usually acceptable

    Reclassification can be acceptable when it is a controlled correction, not a convenience move. Common examples include a data-entry mistake, use of the wrong workflow by a trained user, or later evidence showing that an approved deviation already covered the condition and the nonconformance record was opened in error.

    Even then, the original record usually should not disappear. A defensible approach commonly includes:

    • the original nonconformance record retained or superseded, not silently overwritten
    • a documented reason for reclassification
    • approval by the appropriate quality authority, and sometimes MRB or customer authority depending on the program
    • clear linkage between the nonconformance, deviation, affected lots or serials, and any disposition decisions
    • assessment of whether CAPA, risk review, or customer/regulatory notification is still required
    • an audit trail showing who changed what, when, and why

    What is usually not acceptable

    It is hard to defend post-factum reclassification when the practical effect is to downgrade the event or bypass controls. That includes reclassification used to avoid scrap, avoid trend metrics, avoid investigation, fit shipment dates, or convert an unauthorized departure into something that looks pre-approved.

    If product was already built, processed, inspected, released, or shipped outside approved requirements, calling it a deviation later does not usually change the underlying fact pattern. You may still need nonconformance handling, disposition, impact assessment, segregation decisions, customer communication, and in some cases field or recall analysis depending on the sector and product risk.

    What regulators and auditors tend to test

    They usually focus less on the label itself and more on control of the decision. Expect questions like:

    • Was the departure known before execution or only discovered afterward?
    • Did an approved deviation exist before the work occurred?
    • Who had authority to reclassify the event?
    • Was the product impact reassessed, including fit, form, function, safety, and contractual requirements where applicable?
    • Was the reclassification used consistently with written procedures?
    • Were records changed transparently with a reason code and audit trail?
    • Did the change affect escalation thresholds, metrics, or customer reporting obligations?

    If those answers are weak, the issue quickly becomes one of data integrity, procedure adherence, and management pressure, not just terminology.

    Brownfield system reality

    This gets messier in plants where deviation, NCR, MRB, CAPA, and customer concession workflows sit in different systems. A common failure mode is that MES, QMS, ERP, and document control each reflect a different status. One system says deviation, another still shows NCR, and the genealogy or shipping release does not clearly show which authority governed disposition.

    That is not a trivial admin problem. In a regulated environment, inconsistent state across systems creates evidence gaps. If reclassification is allowed at all, it needs governed mappings, role-based approvals, immutable history, and reconciliation across affected systems. In many brownfield environments, that control is partly manual because full replacement of legacy quality and execution systems is usually unrealistic given validation cost, downtime risk, integration debt, and long equipment and program lifecycles.

    Practical bottom line

    Post-factum reclassification is high-risk and should be rare. If the event was truly a nonconformance discovered after execution, treat it as such unless there is strong evidence that the original classification was objectively wrong. If you do reclassify, preserve the record history, document the rationale, assess product and process impact again, and make sure the change does not sidestep required review or traceability.

    That approach does not guarantee a favorable audit outcome, but it is generally more defensible than trying to clean up the record by relabeling the event after the fact.

  • MRB Cycle Time

    MRB Cycle Time commonly refers to the elapsed time it takes for a nonconforming item, material, or event to pass through the Material Review Board (MRB) process from a defined starting point to a defined end point.

    In manufacturing and regulated quality environments, the term is used as a process metric for how long MRB-related decisions take. It usually covers the period from identification or submission of a nonconformance through review, disposition, and administrative closure, depending on how an organization defines the clock. Because start and stop points vary, the metric is only comparable when those rules are clearly stated.

    What it includes and excludes

    MRB Cycle Time typically includes waiting time, review time, routing time, and decision time associated with MRB processing. In digital workflows, it may also include time spent in status queues such as pending review, engineering input, quality approval, or disposition release.

    It does not automatically mean total production delay, total repair time, or customer response time. A part can have a short MRB Cycle Time but still experience long downstream rework or replacement delays. Likewise, production hold time may begin before MRB review starts or continue after the MRB decision is made.

    How it appears in operations

    This metric is often tracked in NCR, QMS, MES, or ERP-connected quality workflows to monitor how quickly nonconforming material is being reviewed and dispositioned. Common dispositions may include use-as-is, rework, repair, return to supplier, or scrap, subject to the organization’s procedures.

    Teams may analyze MRB Cycle Time by product line, defect type, supplier, site, disposition type, or reviewer group to understand where review queues or handoff delays occur.

    Common confusion

    • MRB Cycle Time vs. NCR Cycle Time: NCR Cycle Time may cover the broader nonconformance record lifecycle, including containment, investigation, corrective action, and closure. MRB Cycle Time is narrower and focuses on the review and disposition portion.

    • MRB Cycle Time vs. rework turnaround time: Rework turnaround measures execution after disposition. MRB Cycle Time measures the decision path leading to that action.

    • MRB Cycle Time vs. lead time: Lead time usually refers to the end-to-end time to produce or supply something, not specifically the nonconformance review process.

    Why definition discipline matters

    Organizations often define the start of MRB Cycle Time differently, such as when a defect is detected, when an NCR is opened, when the case enters MRB status, or when all required evidence is complete. The endpoint may be disposition approval, release to execution, or formal record closure. For that reason, the term is most useful when paired with a documented calculation rule.

  • What records do AS9100 auditors typically request for nonconformances?

    AS9100 auditors typically request a cross-section of records that show how you identify, evaluate, disposition, correct, and prevent recurrence of nonconformances. The exact list depends on your QMS structure, digital systems, and audit scope, but the themes are consistent.

    1. Nonconformance & defect records

    Auditors usually start with the core evidence that you recognize and document nonconformances:

    • Nonconformance reports (NCRs) for product, process, documentation, and supplier issues
    • Links from NCRs to specific parts, lots, work orders, serial numbers, and revisions
    • Evidence of who detected the issue (inspection, operator, customer, supplier, internal audit, etc.)
    • Classification/criticality (e.g., minor/major, safety-impacting, flight-critical, special processes)
    • Date/time stamps for detection, logging, and closure to demonstrate timeliness

    In digital environments, this can span MES, QMS, and ERP. Auditors will want to see how you maintain traceability when multiple systems are involved.

    2. Containment, segregation, and risk control

    Next, auditors look for how you prevent suspect product from escaping or being used:

    • Records showing physical segregation or positive control of nonconforming product (quarantine locations, hold tags, status in MES/ERP)
    • Hold/release transactions and status changes with user and timestamp
    • Line stop / work stop / ship hold records, where applicable
    • Evidence of notification to affected internal stakeholders (planning, production, quality, supply chain, MRO) when risk is broad

    Where containment is modeled in multiple systems (e.g., ERP inventory hold plus MES operation block), auditors usually probe for gaps or mismatches.

    3. MRB and disposition decisions

    AS9100 emphasizes controlled disposition of nonconforming outputs. Auditors typically sample:

    • MRB (Material Review Board) records for rework, repair, use-as-is, scrap, or return to supplier
    • Engineering and quality approvals, including signatures or validated e-signatures
    • Technical rationale for disposition decisions, particularly for use-as-is and repair
    • Associated concessions/deviations and customer approvals where required by contract
    • Linkage between MRB decisions and configuration/airworthiness impact for serialized and safety-critical items

    In brownfield environments, parts of MRB evidence may exist in PLM, engineering change tools, or email archives. Auditors often test whether all required disposition approvals are captured in a controlled record, not just in ad hoc communication.

    4. Corrective action and root cause analysis (when required)

    Not every NCR requires a full corrective action, but auditors expect a consistent method to determine when to escalate. They typically request:

    • Corrective action requests (CARs) or CAPA records linked to significant or recurring NCRs
    • Root cause analysis documentation (e.g., 5-Why, fishbone, 8D or RCCA reports)
    • Identification of systemic vs. isolated causes, and justification when no systemic action is taken
    • Defined corrective actions, owners, due dates, and status tracking
    • Risk evaluation: impact on safety, conformity, delivery, and customer obligations

    If problem-solving is done in spreadsheets or local templates instead of a central QMS, auditors typically probe for version control, access control, and completeness of records.

    5. Implementation and effectiveness of actions

    AS9100 auditors nearly always ask for evidence that actions were both implemented and effective:

    • Records showing implementation of process, documentation, or training changes (e.g., revised work instructions, updated control plans, updated inspection plans)
    • Training and qualification records for affected personnel, where new methods or criteria were introduced
    • Verification/validation of effectiveness (e.g., defect trend charts, capability studies, audit checks, sampling results)
    • Documented closure of corrective actions with rationale for why actions are considered effective

    Where systems are fragmented, auditors may challenge the traceability from a CAPA record to actual changes implemented in MES routes, ERP BOMs, PLM revisions, or work instructions.

    6. Linkage to configuration, documents, and change control

    Nonconformances in aerospace often have configuration and document impacts. Auditors commonly review:

    • References from NCRs and CAPA records to applicable drawings, specifications, and revision levels
    • Links to engineering change requests/orders where design changes were triggered by recurring nonconformances
    • Evidence that obsolete instructions, forms, and inspection criteria were removed from use after changes
    • Controlled templates and forms used for NCR, MRB, and RCCA and their current revision status

    In brownfield plants, changes may be updated in PLM but lag in MES or paper travelers. Auditors often test whether nonconformance learnings are actually propagated into the operating instructions and systems used on the line.

    7. Trend, risk, and management visibility

    AS9100 requires using nonconformance data for improvement and risk-based thinking. Auditors usually request:

    • Nonconformance and defect trend reports by part family, process, line, supplier, or program
    • Analysis outputs that feed risk registers, FMEA updates, or control plan adjustments
    • Management review inputs and minutes that show discussion of significant nonconformances and systemic actions
    • KPIs related to nonconformances (e.g., internal PPM, scrap, rework, major vs. minor findings, supplier defect rates)

    If data is pulled manually from multiple systems, auditors may question data integrity, completeness, and repeatability of the analysis.

    8. Supplier and customer-facing nonconformance records

    For organizations with extensive supply chains or direct OEM contracts, auditors also request:

    • Supplier NCRs and associated communications (returns, corrective action requests to suppliers, and approvals)
    • Customer nonconformance/escape reports and returned product records
    • Evidence of timely response to customer-issued corrective actions and 8D/RCCA requests
    • Concession/deviation records and customer approvals where nonconforming product was accepted under controlled terms

    Where supplier and customer quality portals are used, auditors may also ask how data from those portals is integrated into your internal NCR and CAPA system.

    9. System evidence: access, audit trails, and validation

    In digital and mixed paper/digital environments, AS9100 auditors often look at the robustness of the underlying systems:

    • System audit trails showing who created, modified, and closed NCR/MRB/CAPA records
    • User access controls and role definitions for approving dispositions and corrective actions
    • System validation or qualification documentation where systems are used to control and retain quality records
    • Backup and retention policies for nonconformance records consistent with contract and regulatory expectations

    If different plants or business units use different tools (e.g., one site on QMS software, another on Excel), auditors typically test whether each approach is adequately controlled and yields complete, retrievable records for the required retention period.

    10. Brownfield and coexistence considerations

    In long-lifecycle aerospace environments, nonconformance evidence is rarely in a single system. Auditors are accustomed to seeing:

    • Legacy NCR records in older QMS or MES platforms with partial migration to newer tools
    • Mixed paper and electronic MRB records, especially for older programs
    • Email or shared-drive usage to supplement formal systems

    This is not automatically noncompliant, but it increases audit risk if traceability is weak or if records are hard to retrieve or verify. Full replacement strategies can be challenging because they require data migration, re-validation, and re-training under tight downtime constraints. Auditors typically care less about tool standardization and more about whether your chosen mix of systems consistently produces complete, controlled, and retrievable nonconformance records with clear traceability.

    Ultimately, AS9100 auditors look for objective evidence that nonconformances are systematically captured, risk-controlled, technically justified, escalated when needed, and used to drive effective, verified corrective actions. The stronger and more traceable your record set across NCR, MRB, CAPA, and change control, the smoother the audit will be.

  • What is the difference between an NCR and a deviation permit in aerospace manufacturing?

    The short answer is this: an NCR is raised after you find that the product, material, process, or documentation does not conform to a requirement. A deviation permit is an approved planned departure from a stated requirement before manufacture, processing, inspection, or release takes place. If the condition already exists, it is usually not a deviation anymore; it is a nonconformance that needs NCR-type control, even if a later disposition allows use as-is or repair.

    Core distinction

    An NCR, or nonconformance report, is a record that something required was not met. It is evidence of an actual condition. The requirement might come from the drawing, specification, process sheet, traveler, purchase order, contract, approved procedure, or inspection plan.

    A deviation permit is a request and approval mechanism to intentionally work outside the normal requirement under controlled conditions. It is typically time-bounded, scope-bounded, and tied to specific parts, lots, serial numbers, operations, or time periods. It does not erase the original requirement; it documents an authorized exception.

    Why the terms get confused

    They are often confused because both deal with requirements that are not being followed exactly, and both can involve engineering, quality, and customer approval. But they are not the same control.

    • NCR: actual nonconformance has occurred or has been detected.

    • Deviation permit: planned departure is requested in advance.

    In aerospace, the naming is not perfectly standardized across all companies. One site may use deviation, permit, waiver, concession, variance, or production permit with specific internal meanings. Customer contracts and program quality clauses may narrow those meanings further. So the local QMS, customer flowdowns, and regulatorily relevant procedures control the final answer at your site.

    Common timing rule

    The simplest practical rule is timing.

    • If approval is obtained before the departure happens, it is generally handled as a deviation or permit.

    • If the departure already happened or the condition is already present, it is generally handled as a nonconformance through an NCR.

    That timing rule is widely useful, but it still has exceptions. Some organizations require an NCR even when a deviation was approved, especially if execution did not follow the approved limits exactly.

    What each one usually contains

    An NCR usually includes:

    • the part, lot, serial, work order, or operation affected

    • the requirement that was not met

    • the actual condition found

    • containment and segregation status

    • disposition, often through MRB or authorized functions

    • traceability to rework, repair, scrap, use-as-is, or return-to-supplier actions

    • potential linkage to CAPA or RCCA if the issue is systemic

    A deviation permit usually includes:

    • the exact requirement to be departed from

    • the reason the departure is needed

    • the technical justification and risk assessment

    • the scope and duration of approval

    • any customer or design authority approval required

    • special inspection, marking, documentation, or traceability conditions

    What a deviation permit is not

    A deviation permit is not a general excuse to bypass process discipline. It should not be used to hide recurring process failures, poor planning, tooling problems, or training gaps. If the same deviation is needed repeatedly, that is usually a signal that the released process, drawing, routing, tooling, or planning data needs formal change control.

    In regulated aerospace environments, repeated temporary exceptions tend to create audit trail problems, planning ambiguity, and inconsistent as-built records. They also make MES, ERP, and QMS synchronization harder if systems are not tightly integrated.

    How this interacts with MRB, concessions, and waivers

    This is where site-specific language matters most.

    In many aerospace organizations:

    • MRB is the function that reviews and disposes certain nonconformances.

    • Concession often means permission to accept a known nonconforming item, usually after the fact and often with customer involvement.

    • Waiver may mean permission to use or deliver product that does not fully meet specified requirements, but companies use this term differently.

    • Deviation usually means permission before manufacture or before the departure occurs.

    Those are common patterns, not universal definitions. Contract language, customer requirements, and internal procedures can override general industry usage.

    System and workflow implications

    In brownfield aerospace plants, NCR and deviation workflows often cross multiple systems. The NCR may start in MES or QMS, the material hold may sit in ERP, the engineering basis may live in PLM, and customer approval evidence may be stored outside all three. That is a common source of gaps.

    The practical risk is not just terminology. It is broken traceability. If the permit, disposition, affected serial numbers, rework instructions, and final release record are not linked, you can end up with incomplete as-built history or inconsistent downstream reporting. That becomes more serious when parts move through long cycle times, outside processing, or mixed paper and digital travelers.

    Full replacement of these systems is usually unrealistic in established aerospace operations. The qualification burden, validation effort, integration complexity, and downtime risk are too high. Most sites do better by tightening evidence trails, approval routing, master data, and record linkage across the existing stack.

    Practical rule for operators and quality teams

    If you already have a condition that fails a requirement, treat it as a nonconformance unless your procedure clearly says otherwise. If you know in advance that you need to depart from a requirement, do not proceed informally; get the required deviation approval first. If the customer or design authority must approve, internal approval alone is not enough.

    That sounds obvious, but many record integrity problems come from teams trying to solve schedule pressure with informal approvals, email-based exceptions, or traveler annotations that never make it into the controlled quality record.