Supplier Corrective Action Report (SCAR) — Complete

What Is a SCAR?

A Supplier Corrective Action Report (SCAR) is a formal document sent by a customer to a supplier when a nonconformity is detected. Aligned with IATF 16949 Clause 10.2.4 and AIAG core tool standards, this guide provides a complete framework for supplier 8D response management. It requires the supplier to:

• Investigate root causes
• Implement corrective actions
• Provide evidence of effectiveness

Most OEMs require suppliers to respond using the 8D methodology format.

SCAR vs 8D

SCAR = The REQUEST document sent TO the supplier 8D = The RESPONSE document sent BY the supplier

They are complementary: you issue a SCAR, the supplier responds with an 8D.

When to Issue a SCAR

Issue a SCAR when:

• Recurring defect (same part, same defect, 2+ occurrences)
• Safety or regulatory nonconformity
• Customer line stoppage caused by supplier defect
• Supplier fails to meet PPAP requirements
• Significant PPM spike (statistically out of control)

Do NOT issue a SCAR for:

• One-time, isolated incident with clear cause and fix
• Issues resolved during regular supplier communication
• Cosmetic issues below specification threshold

SCAR Response Requirements

A complete SCAR response should include:

1. D1 — Team: Cross-functional team members with names and roles
2. D2 — Problem Description: 5W2H with objective evidence (photos, data, dates, lot numbers)
3. D3 — Containment: Actions taken, quantities, dates, clean point
4. D4 — Root Cause: 5-Why and fishbone with TRC, MRC, and escape point
5. D5-D6 — Corrective Actions: Permanent fixes with implementation dates and verification data
6. D7 — Prevention: System changes, FMEA updates, horizontal deployment
7. D8 — Verification: Evidence package (photos, data, capability studies)

Timeline Expectations

Common SCAR Mistakes

1. Vague problem descriptions — "Quality issue with Part X" is unacceptable. Be specific: "0.5mm burr on Part X P3 edge, Lot#A938, detected at customer incoming inspection"
2. Accepting "operator retrained" as D6 — retraining is not a permanent corrective action
3. No verification data — "Implemented" without capability study data is not verified
4. Supplier ghosting — no response after initial acknowledgment

Worked Example: Burr on a Machined Edge

A customer receives a shipment of machined brackets and finds a burr on the P3 edge during incoming inspection. The SQE issues a SCAR with this D2 statement: "0.5mm burr on Part X P3 edge, Lot#A938, 14 of 200 pieces affected, detected at customer incoming inspection on 12 March." The supplier's D3 containment quarantines 1,850 pieces in its warehouse and 600 pieces at the customer, sorts 100% with a deburr gauge, and declares a clean point at lot A941. D4 uses 5-Why and lands on a worn deburr tool that was not replaced at the defined interval, plus an escape point where the final visual check had no gauge and no sampling standard. D5-D6 replaces the tool on a fixed count-based interval, adds a deburr gauge to the final check, and records a 30-piece capability study of the edge dimension before and after. D7 updates the control plan and PFMEA and deploys the tool-interval change to two similar lines. D8 closes with the capability data, updated work instructions and a follow-up audit.

Step-by-Step SCAR Checklist

• Before issuing: confirm the defect with objective evidence (photos, measurements, lot traceability) and check whether it meets the issue criteria above.
• D0/D1: assign an owner, confirm the supplier contact, and verify the team has the right functions (quality, engineering, production).
• D2: write the problem in 5W2H form with numbers, not adjectives.
• D3: confirm containment quantity, location, method and clean point date.
• D4: verify the root cause explains both the occurrence (TRC) and the escape (MRC), and that the 5-Why reaches a system cause, not a person.
• D5-D6: check each action has an owner, a date and verification data.
• D7: confirm FMEA, control plan and work-instruction updates, plus horizontal deployment.
• D8: review the evidence package and close only when effectiveness is demonstrated.

Failure Modes and How to Detect Them

How to Verify the Output

Do not accept a SCAR response on the strength of its wording. Verify by re-checking the evidence: confirm the containment quantity matches the shipped quantity, confirm the clean point is traceable to a lot number, and confirm the D6 verification data comes from a capability study or a defined inspection sample rather than a single good part. For D8, request a follow-up audit or a sample of recent production data to show the fix holds over time. If the supplier cannot produce this, the SCAR stays open.

How the SCAR Links to Neighbouring D-Steps

A SCAR is not a standalone document; it sits inside the wider 8D flow. D2 feeds directly into D4, because a vague problem statement produces a vague root cause. D3 containment protects the customer while D4 is being worked, and a weak D3 makes every later step unreliable. D5-D6 must trace back to the D4 root cause, and D7 must show the system change that prevents recurrence. D8 closes the loop by proving the fix works, which then feeds the next SCAR's D2 with better data.

Key Takeaways

1. SCAR is the request, 8D is the response
2. Be specific in problem descriptions — data beats adjectives
3. Set clear deadlines and escalate promptly when missed
4. Retraining alone is never a valid permanent corrective action
5. When a supplier's 8D blames "operator error", push back — ask what system failed