What Is a Corrective Action Request (CAR)?

If you work in quality, you've probably seen a corrective action request land in your inbox — maybe from an auditor, maybe from a customer, maybe from your own inspection process flagging the same defect for the third time. It's one of the most common documents in any quality management system, and also one of the most misunderstood. So let's clear it up: a corrective action request (CAR) is a formal record that says "something didn't meet requirements, and here's the request to find out why and stop it from happening again."

This guide walks through what a CAR actually is, when one gets issued, what goes on the form, how the process runs end to end, and how it differs from a CAPA. No jargon for jargon's sake — just what a quality manager needs to know.

What is a corrective action request?

A corrective action request is a formal, documented request to investigate a nonconformity, find its root cause, and put actions in place so it doesn't recur. The "request" part matters: a CAR is the trigger and the paper trail. It formally assigns someone to own the problem, sets an expectation for a response, and creates the record that the issue was taken seriously and resolved.

The concept sits on top of a distinction that trips a lot of people up. Under ISO 9000:2015 — the vocabulary standard behind ISO 9001 — correction and corrective action are two different things. Correction is the immediate fix: you scrap the bad part, rework the batch, or pull the shipment. Corrective action goes deeper: it's the action to eliminate the cause of a detected nonconformity so it doesn't happen again. A CAR is the vehicle that drives the second one — not just cleaning up the mess, but making sure the mess stops being created.

That's the whole point of raising a corrective action request instead of just quietly fixing the problem. Fixing the symptom keeps you busy. Eliminating the cause keeps you out of trouble.

CAR vs. corrective action vs. CAPA

The terminology around this gets muddy, so here's the plain version:

• Corrective action is the activity — the work of finding and removing a root cause.
• Corrective action request (CAR) is the document that formally kicks off and tracks that work. Some organizations call it a CAR; others call the same record a corrective action report, an NCR-to-CAR, or simply "a corrective action."
• CAPA — Corrective and Preventive Action — is the broader system that houses corrective action alongside preventive action (heading off problems that haven't happened yet).

In short: the CAR is the ticket, corrective action is the work the ticket asks for, and CAPA is the filing cabinet the whole thing lives in.

Is a CAR the same as a CAPA?

Not quite, though people use the terms interchangeably. A CAPA process covers both corrective action (fixing causes of problems that already occurred) and preventive action (eliminating causes of potential problems before they occur). A corrective action request is specifically the corrective half — it's raised in response to something that has already gone wrong. If you're reacting to a nonconformity that already happened, you're in corrective-action territory, and a CAR is how you formalize it.

When is a corrective action request issued?

A CAR isn't warranted for every hiccup. You raise one when a nonconformity is significant, recurring, or carries real consequences — the kind of issue where simply correcting the instance isn't enough and you need to be sure it won't come back. ISO 9001:2015 frames this well in Clause 10.2: when a nonconformity occurs, you react to it, then evaluate whether action is needed to eliminate the cause so it doesn't recur or turn up elsewhere. Corrective action is meant to be proportional — a minor, one-off issue may only need a correction, while a bigger or repeat problem earns a full investigation.

Common triggers for a corrective action request include:

• Internal or external audit findings — an auditor writes up a nonconformity against a requirement.
• Customer complaints — a customer reports a defect or a service failure.
• Non-conformances from inspection — product or process fails a check against spec.
• Deviations and out-of-specification results — something operated outside its defined limits.
• Recurring problems — the same issue keeps reappearing, which is a signal the root cause was never actually removed.
• Supplier quality issues — a supplier ships nonconforming material (this specific case is usually handled with a supplier corrective action request, or SCAR).

The common thread: a requirement wasn't met, and there's reason to believe it could happen again if nobody digs into why.

What's on a corrective action request form

Forms vary between organizations, but a well-built corrective action request captures a consistent set of information so the issue can be worked and, later, proven closed. Expect fields like:

• Description of the nonconformity — what happened, where, and against which requirement.
• Source / trigger — audit, complaint, inspection, deviation, and a reference number.
• Immediate correction / containment — what was done right away to control the problem.
• Root cause analysis — the findings from tools like the 5 Whys or a fishbone (Ishikawa) diagram.
• Corrective action(s) — the specific actions to eliminate the cause.
• Owner and due date — who's accountable and by when.
• Effectiveness verification — the evidence that the action actually worked and the issue hasn't recurred.
• Closure and sign-off — approval that the CAR is complete, with a full audit trail.

That last pair — verification and closure — is where a lot of CARs fall down, which we'll get to.

The corrective action request process, step by step

Most CAR workflows follow the same arc, whether you run them on paper or in software:

1. Identify and document the nonconformity. Capture what went wrong, against which requirement, with enough detail that someone who wasn't there can understand it.
2. Contain it (correction). Take immediate action to control the impact — isolate the product, stop the line, notify who needs to know.
3. Investigate the root cause. Go past the symptom to the actual origin. "Operator error" is almost never a root cause; the real question is why the process allowed the error to happen.
4. Define and implement corrective action. Choose actions that eliminate the cause, and make them proportional to the risk.
5. Verify effectiveness. Confirm with objective evidence that the action worked and the nonconformity hasn't come back — and didn't create a new problem somewhere else.
6. Close it out. Sign off, record the outcome, and keep the trail for your next audit.

Regulated industries lean on this same structure. For medical device makers, for example, the FDA's rules at 21 CFR 820.100 require manufacturers to establish CAPA procedures that analyze quality data, identify actions needed to correct and prevent recurrence, verify or validate those actions, and document everything — essentially the CAR arc, made mandatory.

What is a supplier corrective action request (SCAR)?

A supplier corrective action request (SCAR) is the same idea pointed outward: instead of investigating a problem inside your own operation, you formally ask a supplier to investigate a nonconformity in the material or service they provided, find the root cause, and put corrective actions in place on their end. It's a cornerstone of supplier quality management — a documented way to hold suppliers accountable when their nonconforming product creates risk downstream in your process.

The mechanics mirror an internal CAR — nonconformity, containment, root cause, corrective action, verification — but the response comes from the supplier, and the relationship dynamics are different. SCARs are a big enough topic to deserve their own walkthrough, so we'll cover the supplier side in depth separately.

Common mistakes with corrective action requests

A few failure patterns show up again and again, and every one of them is the kind of thing an auditor is trained to catch:

• Confusing correction with corrective action. Scrapping the bad part isn't corrective action — it's containment. If the CAR closes without a root cause and a change to prevent recurrence, the problem is still live.
• Stopping at "human error." If the root cause is a person, dig further. Why did the process let the error through undetected?
• Skipping effectiveness verification. Closing a CAR because the action was implemented isn't the same as confirming it worked. Auditors verify that root causes were identified and that the nonconformity actually hasn't recurred.
• Letting CARs age out. Overdue corrective actions with no owner and no due date are a classic finding — and a sign the system isn't being driven.
• Poor documentation. If it isn't recorded, it didn't happen — at least as far as an audit is concerned. A clean audit trail is the difference between a defensible CAR and a finding.

Managing corrective action requests in a QMS

Running corrective action requests on spreadsheets and email works right up until it doesn't — usually the week before an audit, when someone has to reconstruct who did what and when. A quality management system keeps the whole lifecycle in one place: the CAR is raised, routed to an owner, linked to the originating non-conformance or complaint, tracked to a due date, verified for effectiveness, and closed with a complete audit trail behind it.

That's exactly what Isolocity's CAPA module is built to do. Corrective action reports sit at the center of the module alongside non-conformances, deviations, out-of-specification records, and customer complaints, with automated reminders for checkpoints and a full audit trail on every record — so nothing quietly ages out and nothing goes missing when the auditor asks. If you'd like to see how it handles a CAR end to end, you can book a demo.

Bottom line: a corrective action request isn't paperwork for its own sake. Done right, it's the mechanism that turns a one-off problem into a permanent fix — and keeps the same nonconformity from showing up in next year's audit.