A SCAR closes on proof, not on the supplier's own word

One document, answering to two clauses

A SCAR isn't named in ISO 13485 — it's an industry convention, not a defined term the standard uses — but the obligations behind it are. Clause 7.4.1 requires supplier control proportionate to the effect the purchased product has on the finished device, including re-evaluation when a supplier's performance calls the relationship into question. Clause 8.5.2 requires reviewing nonconformities, determining their causes, and taking action to prevent recurrence, and the clause doesn't carve out an exception for nonconformities that originated outside the manufacturer's own walls. A defective lot from a supplier is still a nonconformity in the receiving organization's own quality system the moment it's detected, and 8.5.2's corrective-action duty attaches to it exactly the way it would to an in-house process escape. A SCAR that reads as a one-way complaint to the vendor, with no corresponding record in the manufacturer's own CAPA system, has satisfied neither clause on its own.

A containment action isn't a root cause, even when the supplier signs it

The most common way a SCAR fails is the same failure mode this blog has already traced in ordinary CAPA logs: a fast, plausible-sounding response gets accepted as if it closed the question. “Replaced the affected lot” and “retrained the operator” are containment, not cause — they describe what happened to the bad parts and the person who made them, not what allowed the process to produce them in the first place. A supplier's own 8D or corrective-action report can look complete and still stop one layer short, at the mechanism rather than the reason the mechanism failed. A SCAR record that accepts a supplier's stated root cause without checking that the proposed fix would actually have prevented the specific failure described has recorded the supplier's confidence, not evidence.

Effectiveness is verified by the receiver, on the receiver's own incoming product

Clause 8.5.2 requires verifying that corrective action doesn't just get implemented but actually works, and for a supplier-caused nonconformity that verification can't be delegated back to the party whose process just failed. The check has to run on the manufacturer's own incoming inspection or acceptance data across however many subsequent lots it takes to show the failure rate has actually moved, not on the supplier's internal test report certifying its own fix. A SCAR marked closed on the date the supplier's response letter arrived, with no later look at whether the next several shipments actually came in clean, has closed the file before the evidence the clause requires existed.

The outcome belongs back in the supplier file, not just the CAPA log

A closed SCAR is exactly the kind of event a supplier qualification file needs as a re-evaluation trigger, rather than a stand-alone record that lives only in the CAPA system and never touches the supplier's own standing. A pattern of SCARs against the same vendor, each closed individually without ever reopening that supplier's qualification status, is a file answering 8.5.2 nonconformity by nonconformity while leaving 7.4.1's re-evaluation duty untouched in between.

Where this meets the file

A SCAR record needs fields for both clauses it answers to at once: a verified root cause distinct from the containment action, a stated method and data window for effectiveness verification on the receiver's own incoming product, and a link back to the supplier file it should be feeding as a re-evaluation input. A supplier corrective action request template built around that structure, alongside the launch catalog's supplier-qualification and CAPA templates, is previewed there now. If your program handles supplier corrective action differently, the shelf takes that correction directly.