CAPA: Corrective and Preventive Action Guide

Quality problems cost time and money, and quality teams need a structured way to address problems that have already occurred and risks that could lead to future problems. Corrective and Preventive Action (CAPA) provides that structure.

It's a core part of quality management in standards such as ISO 9001 and ISO 13485, but determining whether an action actually worked can be difficult when teams rely on manually updated records. Connecting shop-floor data to quality workflows, with platforms like FlowFuse, can give teams objective production data to support investigations and effectiveness checks.

This article explains the difference between corrective and preventive action, how each process works, where CAPA systems break down, and how FlowFuse supports CAPA with connected production data.

What Is Corrective Action and Preventive Action?

Corrective action is the action taken to eliminate the cause of an existing nonconformity and prevent it from recurring.

Preventive action is the action taken to address the cause of a potential nonconformity before it occurs.

Under ISO 9001:2015, corrective action is addressed in Clause 10.2. Preventive action is no longer a standalone requirement; the 2015 revision incorporated prevention into the standard's risk-based thinking approach. Quality teams may still use preventive action as part of their risk management practices.

A Simple Example

Say a machine's cutting tool wears down and starts producing parts outside tolerance. Replacing the worn tool and changing the maintenance interval to prevent the same failure from recurring is corrective action because it addresses an actual defect and its cause.

If a technician notices during a routine check that a different tool on a similar machine is wearing faster than expected and replaces it before it produces a bad part, that's preventive action. No defect has occurred; the action addresses a potential failure.

This is the same logic behind preventive maintenance programs and poka-yoke, or mistake-proofing: both aim to prevent a failure before it produces a defect.

Fixing the immediate bad parts, such as scrapping them or sorting the batch, is neither. That's containment. Containment limits the immediate impact, while corrective and preventive actions address the cause.

Root Cause Analysis

Corrective and preventive actions depend on understanding why a problem occurred or could occur. Stopping at the first plausible explanation can result in a fix that addresses the symptom while leaving the underlying cause in place.

A few methods cover most cases:

• 5 Whys: Ask "why" repeatedly, with each answer guiding the next question, until you reach an actionable cause rather than restating the symptom.
• Fishbone (Ishikawa) diagram: Maps potential causes across categories such as people, methods, materials, and equipment. It's useful when a problem may have several contributing causes.
• Fault tree analysis: Works backward from a failure, breaking it into the combination of conditions that had to be present for it to occur. It's commonly used for complex or safety-critical processes; NASA's Fault Tree Handbook is a widely cited reference for the method.

The investigation should draw on multiple sources of evidence, including process records, operator interviews, maintenance logs, and inspection results. A problem can have more than one contributing cause, so addressing only one may not prevent recurrence.

Corrective Action vs. Preventive Action: Comparison

The key difference is when the action is taken: corrective action responds to an existing problem, while preventive action addresses a potential one.

The Corrective Action Process

A corrective action process typically follows these five steps:

1. Identify and document the nonconformance. Record what happened, when it happened, and any immediate containment taken.
2. Investigate the cause. Use an appropriate root cause analysis method and gather enough evidence to understand why the nonconformity occurred.
3. Determine the appropriate response. The severity and impact of the problem determine the response, which can range from changing a process to scrapping product, notifying customers, or initiating a recall.
4. Implement the action. Address the identified cause rather than only correcting the defective output.
5. Verify effectiveness. Monitor the relevant process or quality indicator to confirm that the action achieved its intended result before closing the CAPA.

The Preventive Action Process

Preventive action follows a similar structure, but starts with a potential failure rather than an existing nonconformity:

1. Identify potential failure points. Use FMEA, near-miss trends, maintenance logs, or process capability data to identify where a nonconformity could occur.
2. Assess and prioritize risk. Evaluate likelihood and severity to determine which risks require action.
3. Implement the preventive measure. This might mean changing a maintenance schedule, modifying a process, updating work instructions, or adding mistake-proofing.
4. Monitor the result. Track the relevant process or risk indicator to determine whether the preventive measure achieved its intended result.
5. Document the action. Record the identified risk, action taken, and evidence that the measure was effective.

Both processes can follow the Plan-Do-Check-Act (PDCA) cycle: plan and investigate, implement the action, check whether it worked, then apply what was learned.

Where CAPA Systems Break Down

A CAPA process can look complete on paper and still fail to solve the underlying problem. One common issue is that teams focus on forms and approval chains instead of collecting enough evidence during the investigation. Another is stopping at the first plausible cause and moving directly to a fix.

Even when the right action is identified, closing the CAPA without objective evidence can make it difficult to determine whether the change actually worked.

A strong CAPA process needs clear ownership, an evidence-based investigation, and a defined effectiveness check. Production data can support this. For example, SPC charts built from live process data can show whether a corrective action actually shifted a process back into control.

How FlowFuse Supports CAPA

CAPA investigations and effectiveness checks often require data from multiple systems, including machines, PLCs, databases, and quality systems. When that information is disconnected, teams may have to rely on manual records or piece together evidence from several sources.

FlowFuse connects production systems and data sources so manufacturers can use operational data as part of their existing CAPA process.

For example, FlowFuse can help teams:

• Collect relevant production data when a quality issue or nonconformity occurs using data integration workflows.
• Connect data across machines, PLCs, databases, and quality systems to support root cause investigations.
• Automate workflows and notifications when production or quality events require attention, including production monitoring and notifications.
• Monitor process and quality data after an action is implemented to provide evidence for effectiveness checks, such as through quality dashboards.

FlowFuse does not replace an organization's CAPA or quality management system. Instead, it helps connect the production data and operational workflows that support investigations, corrective actions, and verification that an action actually worked.

Tracking CAPA Effectiveness

Closing a CAPA does not mean the problem is solved. Teams need to check whether the action actually worked.

Useful measures include CAPA cycle time, recurrence rate, overdue actions, and recurring root causes. A Pareto chart can help identify which causes need attention, while MTTF, MTBF, and MTTR can help measure the effect of corrective actions on equipment reliability.

The quality of these measures depends on the data behind them. Production records, process measurements, machine states, and maintenance history can give teams the evidence they need to investigate a problem and confirm that the action was effective.