When should an aerospace customer issue a SCAR to a supplier?

An aerospace customer should issue a SCAR when the supplier issue requires formal corrective action, documented root cause analysis, and objective evidence that the fix is implemented and effective. In practice, that is usually when normal receiving rejection, routine supplier communication, or a one-time nonconformance record is not enough to control recurrence or risk.

A SCAR is generally appropriate when one or more of these conditions apply:

• Repeat nonconformances for the same or closely related issue, especially after prior notification or containment.
• Major requirement violations, such as drawing, specification, process, configuration, traceability, or documentation failures.
• Escapes that reached production, assembly, test, or the customer, particularly if the issue was not detected by the supplier’s controls.
• Breakdowns in the supplier’s quality system, for example ineffective inspection, uncontrolled changes, missing records, calibration failures, or process discipline problems.
• High operational or program risk, including impact to flight hardware, critical characteristics, serialized parts, special process control, delivery commitments, or downstream rework and disruption.
• Inadequate prior corrective action, where the supplier responded before but did not remove the cause or prevent recurrence.

A SCAR is usually not necessary for every isolated defect. If the issue is minor, fully contained, low risk, and clearly non-recurring, a supplier NCR, rejection, debit, or routine corrective action request may be enough. Overusing SCARs can create noise, slow response to genuinely systemic issues, and weaken supplier prioritization.

What should drive the decision

The decision should be based on risk and evidence, not frustration alone. A practical trigger model often considers:

• Severity of the nonconformance
• Likelihood of recurrence
• Detectability before use or shipment
• Impact on safety-critical or mission-critical applications
• Traceability and record integrity implications
• Program, schedule, and cost impact
• Whether the supplier’s existing controls failed or were bypassed

Many aerospace organizations formalize this in supplier quality procedures using thresholds such as repeat count, defect class, escaped defect status, or risk ranking. Those thresholds vary by customer, program, and contractual flowdown. There is no universal industry-wide rule that every supplier defect requires a SCAR.

What a SCAR should require

If you issue a SCAR, the expectation should be more than containment. The supplier should normally provide:

• Immediate containment of affected product and suspect inventory
• Impact assessment, including shipped product if applicable
• Root cause analysis with evidence
• Corrective action and preventive controls
• Implementation dates, owners, and changed documents or methods
• Objective evidence of effectiveness over time

In regulated aerospace environments, this matters because the issue is not just defect correction. It is also about preserving traceability, documenting what changed, and showing that the change was controlled. If the supplier’s systems are fragmented across ERP, QMS, MES, and manual records, response quality can vary significantly.

Brownfield and supplier system reality

Many suppliers still manage SCAR-related evidence across email, spreadsheets, portals, legacy QMS tools, and paper-based shop controls. That does not prevent issuing a SCAR, but it does affect cycle time, evidence quality, and closure confidence. Customers should expect uneven data quality and should define required evidence clearly.

Trying to solve supplier corrective action problems by forcing a full system replacement is often unrealistic in regulated, long-lifecycle aerospace environments. Qualification burden, validation cost, downtime risk, and integration complexity often make replacement slower and riskier than improving the workflow around existing systems. In many cases, better trigger criteria, clearer evidence requirements, and stronger cross-system traceability are more effective than a platform reset.

Practical rule of thumb

Issue a SCAR when the problem indicates a meaningful failure of the supplier’s process or quality system, or when recurrence would create unacceptable operational, traceability, or compliance risk. Do not issue one for every defect by default, but do not delay when the evidence shows the issue is systemic, repeated, escaped, or poorly controlled.