Corrective Action Request: Definition, Examples, and How It Works

Key Takeaways

• A corrective action request is a formal, thorough document. What separates a CAR that closes cleanly from one that only generates a finding is whether the root cause investigation reaches the system-level cause and whether the effectiveness check is defined before the action closes.

• The problem statement is where most CARs fail before the investigation even starts. “Equipment malfunction” doesn’t support root cause analysis. A problem statement that names the asset, the failure mode, and the operational impact gives the investigation a clear direction.

• CAR levels determine the required response. A Level I nonconformity is correctable on the spot. A Level III or IV requires senior management visibility, structured root cause analysis, and formal effectiveness verification before closure.

• In maintenance operations, a CAR investigation depends on asset history. When the CAR record and the asset record aren’t connected, the investigation proceeds from memory.

When a nonconformity surfaces, someone issues a corrective action request (CAR), and what happens next determines whether the problem is solved or just recorded. The hard part is writing a problem statement specific enough to support an investigation, and setting on an effectiveness criterion before the action closes rather than after. Most CARs skip both.

Those two fields require the most evidence and yet receive the least attention. The problem statement gets a category label. The effectiveness check is written at review time and filled in with whatever seems reasonable. Neither produces a record that holds.

What Is a Corrective Action Request?

A corrective action request is a formal document that identifies a nonconformity, requires a root cause investigation, and records the actions taken to resolve it and prevent recurrence. It's the mechanism that connects a detected failure to a documented, verified fix.

It’s often conflated with other similar terms that need their own clarification: 

1. A complaint identifies a problem but doesn’t require investigation. 

2. A correction fixes the immediate instance without addressing the cause. 

3. A CAPA (corrective and preventive action) record is the broader quality system process, which a CAR may be a component of. 

A CAR sits between a correction and a full CAPA. It requires a root cause investigation and a documented corrective action, but it’s typically scoped to a specific nonconformity rather than the program-level quality system review a CAPA triggers.

CAR Levels

Most CAR systems use a four-level scale to determine how much investigation and documentation a given nonconformity requires. The level is set at intake based on severity and scope. Getting that determination wrong early means either over-documenting a spot fix or under-responding to a systemic issue.

Level definitions vary by industry and contracting context. The framework below reflects common practice in manufacturing and maintenance operations.

Table 1: CAR Levels

A Level I doesn’t require a root cause investigation. Levels II through IV do, with increasing formality and senior involvement. The distinction between Level III and IV is usually the systemic scope: A Level III affects a process or asset, while a Level IV affects the quality system itself or a supplier relationship.

What a CAR Contains

A CAR has seven fields. Most are filled in just fine, but two are consistently neglected: the problem statement and the effectiveness verification. Those are also the fields inspectors specifically look at first.

1. Problem statement: The starting point for the investigation, it needs to name the asset or process, the failure mode, the date and location, and the operational impact. “Equipment malfunction” doesn’t give an investigator anywhere to go. “Conveyor motor on Line 3 failed three times in 60 days, each failure causing 4+ hours of unplanned downtime” does.

2. Immediate containment action: What was done to stop the problem from spreading before the investigation started? Quarantining a batch, taking a line offline, suspending a process, etc. Containment isn’t the corrective action. A CAR that presents containment as the corrective action hasn’t addressed the root cause.

3. Root cause analysis: The method used and the documented conclusion. The conclusion needs to name the system-level condition that produced the failure, not the failure itself. “Bearing failure” is a symptom. “PM interval set to OEM defaults and never updated after load increased” is a root cause. 

4. Corrective action plan: What changes, who owns it, and when it’ll be complete. The action must address the root cause, not just the symptom. If the main issue is a PM interval that was never updated, retraining the technician who missed a lubrication step isn’t enough, even if it’s part of the plan.

5. Preventive action: What changes can prevent the same failure mode from appearing in similar assets or processes? If the PM interval was wrong on one asset, the question is whether it’s wrong on others configured the same way.

6. Responsible party: The owner of the corrective action plan. One person, not a team. Shared ownership produces zero accountability.

7. Effectiveness verification: The criterion against which the corrective action will be measured, and the follow-up date. Both need to be defined before the CAR closes, not when someone reviews the file later. “No recurrence of this failure mode within three complete PM cycles” is a criterion. “Monitor for recurrence” isn’t.

Table 2: Weak vs. Strong CAR Field Language

Corrective Action Examples

Root cause analysis looks different depending on where the investigation stops. The following four examples show what it looks like when it reaches the system-level condition and what the corrective action and verification look like when it does.

Example 1: Equipment Failure

A conveyor motor fails three times in 60 days, each failure causing an unplanned production stoppage. 

• The investigation finds the PM interval was set to the OEM default and never adjusted after a line reconfiguration 18 months ago increased the load on the motor. 

• The corrective action updates the interval in the CMMS and adds a bearing condition check to the pre-shift inspection. 

• Preventive action: Audit PM intervals for all assets reconfigured in the same period. 

• Verification: Three complete PM cycles with no recurrence, confirmed by reviewing work order history against the updated interval.

Example 2: Process Deviation

A fill line produces batches outside the weight specification on four consecutive runs. 

• The investigation finds the filling head is worn beyond tolerance. The current PM checklist includes a cleaning step but no wear measurement. 

• The corrective action replaces the head and adds a wear measurement to the checklist. 

• Preventive action: Inspect fill heads on all lines using the same checklist. 

• Verification: Subsequent batches within specification on the next production run, confirmed by QC sign-off.

Example 3: Supplier Nonconformity (SCAR)

Incoming fasteners from a supplier fail the torque specification on incoming inspection. 

• The investigation finds that tooling calibration at the supplier has drifted outside tolerance. 

• The corrective action requires the supplier to recalibrate and implement an incoming inspection protocol before shipment. 

• Verification: The next three batches pass incoming inspection without exception.

Example 4: Employee-Related Nonconformity

A technician consistently closes work orders without completing all checklist items. 

• The investigation finds the checklist isn’t rendering correctly on mobile in low-connectivity areas of the facility. This is a system problem, rather than a performance one. 

• The corrective action redesigns the checklist for offline completion. 

• Verification: An audit of the next 20 work orders shows 100% checklist completion.

How to Write a Corrective Action Request

Both good and bad CARs tend to fail at the same three points:

1. Problem statement: Name the observable event. Date, asset or process, failure mode, measurable impact. The test: Could an investigator who wasn’t present reconstruct what happened from this statement alone? If not, it’s not specific enough.

2. Root cause language: Trace to the system condition. “The PM interval didn’t account for actual operating conditions” is a system condition. “Technician failed to lubricate” is a proximate trigger that puts a person in the finding and leaves the scheduling condition unchanged. The same failure will occur with a different technician.

3. Effectiveness verification: Set the criterion before the action closes. “No recurrence within two complete PM cycles” is a criterion that can be applied. “Monitor for recurrence” is a placeholder that produces no actionable follow-up date and no documented check.

The CAR in Maintenance Operations

A CAR investigation needs to answer questions the problem statement can't, like: How many times this failure mode has appeared on this asset in the past 24 months, whether the most recent PM was completed on schedule, and which parts were used at the last service visit. 

Those answers are in the CMMS. When the CAR record and the asset record are in separate systems, the investigator has to reconstruct from memory or wait for a manual data pull. Either way, the investigation starts with an incomplete picture. 

Corrective Action Requests Take Your System Problems From “Detected” to “Closed”

Most CAR audit failures occur because the problem statement didn't give the investigation anywhere to go, the root cause stopped at the symptom, and the effectiveness check got written after closure by whoever was reviewing the file. The document looked complete, but the quality system didn't close.

A CAR that holds is specific from the very first field. The problem statement names what failed, where, when, and what it cost operationally. The investigation reaches the condition that produced the failure instead of the person who was present when it happened. The effectiveness criterion is set before the action closes, and when the follow-up date arrives, the work order history either confirms the fix held or it doesn't.

UpKeep Safety keeps that record connected. CAPAs link to the affected asset, corrective actions that require maintenance work generate directly into the CMMS, and when the follow-up date arrives, the asset history is there to verify against.

Curious to learn more? Schedule a product walkthrough to see UpKeep’s solution in action and discover how it can keep your maintenance on the straight and narrow.

FAQ

What is a corrective action request?

A corrective action request is a formal document that identifies a nonconformity, requires a root cause investigation, and records the actions taken to resolve it and prevent recurrence. It differs from a correction, which fixes the immediate instance without addressing the cause, and from a CAPA record, which is the broader quality system process.

What are the four steps to complete a corrective action request?

Identify the issue and write a problem statement specific enough to support investigation. Investigate the system-level root cause, rather than the proximate trigger. Define and implement a corrective action that addresses the main problem, assigns a named owner, and sets a deadline. Verify effectiveness against a previously set criterion.

What is an example of a corrective action?

A conveyor motor fails repeatedly. The investigation finds the PM interval was set to OEM defaults and never updated after a line reconfiguration increased the load. The corrective action updates the interval in the CMMS and adds a bearing condition check to the pre-shift inspection. Verification could look like three PM cycles with no recurrence, confirmed by reviewing work order history against the updated interval.

How does a corrective action request help with regulatory compliance?

A CAR creates a documented, traceable record connecting a detected nonconformity to a verified fix. In FDA-regulated environments, that record is what an inspector reviews when they pull a CAPA file. It provides the problem statement, root cause determination, action taken, and documented evidence that it worked. CARs that close without a defined effectiveness criterion are one of the most common bases for a 21 CFR 820.100 observation.