Supplier Corrective Action Request Process in Procurement

Formal process for suppliers to identify root causes, fix defects, and prevent recurrence.

Cover illustration for “Supplier Corrective Action Request Process in Procurement”
Written by
Theo Okonkwo
Published
October 5, 2026
Reading time
10 min read
Sources cited
3 sources ↓

A Supplier Corrective Action Request is a formal demand sent to a supplier when something they shipped, or something they did, failed to meet requirements. The supplier has to find the root cause, fix it, put in place steps to stop it from happening again, and then prove those steps actually worked over time. It's not a stern email that asks a vendor to try harder next quarter. SG Systems Global draws a clean line here: a SCAR missing objective evidence, missing measurable acceptance criteria, or missing proof that the fix held up, is unfinished. Regulators read it the same way.

A SCAR doesn't appear out of nowhere. Something triggers it first, like a nonconforming material report, a nonconformance record, a customer complaint, or a finding from an audit. Once a SCAR is triggered, it often runs alongside an internal corrective and preventive action process, because the defect rarely stays confined to one side of the fence. A SCAR also differs from a supplier audit: an audit checks whether a supplier can perform well, before anything has gone wrong. A SCAR appears in the record only after a failure has already occurred. Both tools matter, and they do different jobs.

In regulated manufacturing, like medical devices under quality system standards or drugs under pharmaceutical manufacturing rules, a SCAR carries extra weight. It becomes evidence that the quality management system can catch a supplier-caused defect, stop it, fix it, and prevent a repeat, all while keeping records that satisfy electronic records and audit-trail regulations. Strip away the paperwork and one test remains: a SCAR either changes how the supplier operates and cuts down repeat failures, or nothing about the supplier's operation changes. If it doesn't, it's theater, dressed up in forms and signatures but changing nothing about how the next batch gets made.

When to issue a SCAR

Deciding to issue a SCAR takes judgment, and if you get that call wrong either way, it does real damage. Issue too few, and defects slide through uncorrected. Issue too many, and the program turns into noise that suppliers learn to tune out.

SG Systems Global frames the decision around three dimensions: severity (does this touch safety, regulatory standing, or the ability to keep operating), frequency (has this same problem shown up again within a given window), and volume (where do the parts-per-million or defects-per-million numbers land). A few screening questions help sharpen the call. Did the supplier violate a certified specification or a Certificate of Analysis? Did the failure touch a critical characteristic flagged in the process FMEA? Answer yes to either, and the case for a SCAR gets a lot stronger.

Not every hiccup deserves the full process. A one-off miss might be better handled with a phone call or a direct conversation, and escalating straight to a formal SCAR for something minor can feel like calling in a fire truck for a toaster that smoked once. That said, a genuine quality partner never pushes back when a SCAR is actually warranted. If a supplier bristles at formal documentation for a real problem, that reaction reveals something about the relationship that's worth paying attention to.

Qualityze draws another useful boundary: SCARs are meant for supplier-related non-conformances specifically, not as a catch-all for every internal or external corrective action a company runs. Keeping that scope narrow protects the tool's meaning. And there's a cost on the other side of the ledger, too. Tacto points out that excessive SCAR activity is itself a supplier relationship risk. If you fire off SCARs for every small variance, the signal gets buried in paperwork and supplier relationships sour, so you need segmentation, treating key suppliers differently from backup ones, to keep the program credible.

Phase 1: Issuing the SCAR, what the formal notice must contain

Once the decision to issue is made, the notice itself has to carry enough detail to make a real investigation possible. A sloppy notice, vague on the problem and silent on deadlines, produces a sloppy response. Suppliers answer the question asked, so the question needs to be precise.

Arena Solutions lays out the baseline fields a SCAR document should capture: order number, part number, quantity received, quantity rejected or flagged, date of delivery, and disposition, whether that's rework or scrap. From there, the supplier fills in the identified issue, the root cause evidence, the corrective action taken, and the closing actions. Each field exists to remove ambiguity from a conversation that has every incentive to drift into vagueness otherwise.

The notice has to spell out risk and impact alongside the defect itself. A supplier told simply "this part failed inspection" has no sense of what that failure costs downstream. A supplier told that the failure affected a critical characteristic, triggered a quarantine, or put a shipment at risk understands the stakes and responds accordingly.

Deadlines matter just as much as content. Containment action is typically expected the same business day. Root cause analysis usually runs within a handful of business days. Corrective and preventive action implementation generally gets about a month. Standardizing the SCAR form across every supplier cuts down on the back-and-forth that happens when problem descriptions are unclear, since unclear descriptions are one of the most common reasons SCAR responses come back late or incomplete.

Phase 2: Containment, stopping the defect from spreading before root cause is known

Containment has to happen the same day the SCAR goes out. Investigations take days to run properly, and defective material doesn't wait politely in a warehouse for someone to figure out what went wrong. It keeps moving unless something stops it.

The buyer side carries specific, immediate responsibilities. SG Systems Global spells it out: place the suspect lots on hold in the warehouse management system, block directed picking so nobody can grab affected stock without noticing, and if the material already got used in production, open a nonconformance record tied to the batch record. If the problem traces back to labeling or artwork, printing needs to be suspended and label verification rechecked before anything else ships. Traceability data and outbound tracking events need to communicate the scope clearly enough that a recall, if it ever came to that, could move fast.

The supplier carries a parallel obligation: confirm interim containment measures on their end, whether that means halting a production line, segregating suspect inventory, or pulling a batch back from distribution. If the supplier can't demonstrate that containment, the issue escalates to a Material Review Board, where the decision about disposition and next steps moves up a level.

The 8D problem-solving framework treats containment as its own mandatory discipline, step three out of eight, and for good reason. Root cause analysis comes in steps four and five, but it can't start until the defect is bounded. Chasing a cause while the defect keeps spreading is like trying to mop up a bathtub overflow without turning off the faucet first. Something has to stop before anyone can figure out why it started.

Phase 3: Root cause analysis, what a credible investigation looks like

Root cause analysis is where most SCAR programs quietly fall apart, and not because the available tools are weak. The tools work fine. The failure happens when a shallow answer gets accepted as if it were a real one. "Operator error"

A real investigation response reads more like a forensic report than a memo. SG Systems Global describes what that looks like in practice: a problem statement built on facts, proof that containment actually happened, root cause analysis using tools like 5-Why or Ishikawa (fishbone) diagrams, identification of the escape point (where the defect slipped past existing checks), the systemic cause behind it, and a risk assessment tied to the whole chain.

The point of 8D, 5-Why, and fishbone diagrams is to push past the first plausible explanation and keep asking until the answer connects to something systemic, not incidental. A credible investigation has to tie the failure back to the supplier's own process FMEA and process controls. If the failure mode doesn't even appear in their FMEA, that gap is itself a finding, since it means the supplier never accounted for a failure that just happened. Evidence has to be concrete: calibrated measurements backed by measurement system analysis, photos, device logs, batch records with audit trails attached. If a failure gets caught at incoming inspection, the supplier should be able to show how their own sampling plan was validated, and what their acceptable quality level or process capability numbers (Cp or Cpk) looked like before the shipment ever left their dock.

An automotive electronics case from Tacto shows what this looks like when it works. A supplier receives a batch of defective electronic components, runs a full 8D analysis, and traces the failure to a calibration error in their own test system. That's a systemic cause, tied to a specific piece of equipment and backed by evidence, so it's no hand-wave toward human error. MAHLE's supplier quality timeline backs this pace up with a number: root cause analysis and corrective actions are expected within 5 working days of the SCAR going out. Research from ASQ Quality Progress (Sikder, Jabil Inc., July 2024) names root cause corrective action as one of five required phases for a SCAR to count as complete, not an optional nicety tacked onto the paperwork.

Phase 4: Corrective and preventive actions, fixing the defect versus fixing the system

A fix that only addresses the single batch in front of everyone will not stop the next one from occurring. Recurrence is the scoreboard here. If the same defect returns in six months, the corrective action didn't correct anything systemic, no matter what the paperwork claimed at the time.

SG Systems Global separates three layers that get conflated constantly. A correction fixes the specific instance in front of you, like running extra screening tests or purging affected stock. A corrective action removes the root cause behind that specific problem. A preventive action goes wider still, changing processes, checks, tolerance limits, training, or supplier controls so similar issues don't crop up somewhere else in the system. Only actions that change behavior and leave a record behind count as real: updated work instructions under formal document control, revised control plans tied back to the process FMEA, statistical process control alerts, physical device interlocks, corrected label templates, new inbound verification steps.

Watch for the poster-on-the-wall move. Retraining a worker, hanging a reminder sign, or telling a shift supervisor to "be more careful" doesn't change a work instruction, doesn't change a process control, and doesn't leave anything to verify later. That's a promise, not a preventive action, and defect data six months later won't show a promise.

Every real change needs to go through Management of Change, so it needs a risk assessment and a plan for checking effectiveness afterward. A change nobody can verify in the data might as well not have happened, as far as the SCAR process is concerned. MAHLE's own timeline puts a number on this stage too: implemented corrective actions, including steps to prevent recurrence, are expected within 20 working days. That benchmark forces the system-level fix to happen on a clock instead of drifting indefinitely, so suppliers can be held to it.

Phase 5: Verification of effectiveness, the gate that determines whether the SCAR can close

Diagram: The Five Phases of a Complete SCAR. Visualizes: Show the five sequential phases that ASQ Quality Progress (Sikder, Jabil Inc., July 2024) identifies as required for a SCAR to count as complete: (1) Issuance — formal notice with order…

Verification of effectiveness decides whether everything before it meant anything. Skipping it, or rushing it, is exactly where a well-run SCAR process collapses into paperwork that looks finished but isn't. If you close a SCAR before effectiveness is proven, the same defect can show back up, now hidden behind a case number marked closed.

SG Systems Global lays out what objective verification actually requires: a defined observation window, which might mean tracking a set number of future deliveries or holding to a fixed calendar period, clear acceptance criteria (zero critical defects, parts-per-million rates under a set threshold, no new nonconformance records triggered), and a named data source to check against, whether that's receiving inspection results, line checks, or field returns. Verification has to run across that defined window before anyone can sign off on closure. That's the standard, not a suggestion.

If verification fails, the SCAR reopens, and it comes back with higher severity attached and real consequences for sourcing decisions down the line. It's a hard gate, built to require proof of a result before a program can declare victory. Closure needs signatures, timestamps, and records that can't be quietly edited after the fact, because electronic records and audit-trail regulations enforce that directly in regulated manufacturing settings.

Research from ASQ Quality Progress (Sikder, Jabil Inc.) names effectiveness and closure as the fifth and final required phase of a complete SCAR, so it isn't an optional follow-up. The number that reveals whether a program's closures were real or premature is the recurrence rate, the share of issues that come back with the same supplier after a SCAR was supposedly closed. Tacto puts the benchmark for an effective SCAR program at a recurrence rate below 10%. That single figure separates a quality system doing its job from one generating paperwork that nobody downstream can actually rely on.

Methodology & sources

  1. Supplier Corrective Action Request (SCAR): Definition & Application

    Provided the benchmark that an effective SCAR program should have a recurrence rate below 10%, and the warning about excessive SCAR activity damaging supplier relationships.

  2. Supplier Corrective Action Request (SCAR)

    Served as the primary source throughout the article for definitions, the three-dimension decision framework, containment steps, root cause analysis structure, and the distinction between correction, corrective action, and preventive action.

  3. Healing Ways

    Identified root cause corrective action and effectiveness verification as required phases of a complete SCAR, cited as ASQ Quality Progress research by Sikder of Jabil Inc.

Theo Okonkwo