Corrective and Preventive Actions (CAPA)

Corrective and preventive actions turn incident findings into concrete changes that reduce recurrence risk. In incident response, CAPA connects root-cause analysis to tracked engineering work and verification that the risk was actually reduced.

A corrective action addresses a known problem or its contributing cause after an incident. For example, if an API returned incorrect data because a missing validation check allowed invalid state into a service, a corrective action might add the validation and repair affected data. The goal is to prevent recurrence of the observed failure.

A preventive action targets a risk before the same type of failure occurs elsewhere or again under a different condition. Examples include adding automated tests for an entire failure class, introducing an invariant check, improving deployment safeguards, or adding monitoring for an unobserved risk. The distinction is about the reason for the action, not simply whether the code change happens before or after an incident.

Good CAPA items are specific, owned, prioritized, and verifiable. An incident review should turn findings into concrete actions with an owner, target date, expected outcome, and a way to confirm completion. "Improve error handling" is weak; "add retry classification for transient database errors, test three failure modes, and verify the alert fires in staging" is actionable.

For a Java backend engineer, CAPA can involve code, tests, observability, infrastructure, deployment processes, or operational documentation. Actions should address contributing causes rather than only symptoms, while avoiding unnecessary changes that introduce new risk. After implementation, teams should verify the intended control works and consider whether similar systems have the same exposure.

Key points

• Corrective actions address causes or consequences identified from an actual incident.
• Preventive actions reduce the likelihood or impact of related failures before they recur or spread.
• Each action should have clear ownership, scope, priority, and a measurable completion criterion.
• CAPA should address contributing causes, not merely patch the immediate symptom.
• Verification confirms that an action was implemented and that the intended risk reduction is real.

Interview questions

What is CAPA, and how does it fit into incident response?

CAPA stands for corrective and preventive actions. Corrective actions address problems or causes identified from an incident, while preventive actions reduce the chance of related failures occurring in the future. After an incident, findings should become concrete actions with owners and verification criteria. The actions can involve code, tests, monitoring, infrastructure, or operational processes.

Give an example of a good corrective action for a Java backend incident.

Suppose a service accepted an invalid state that later caused requests to fail. A weak action would be to restart the service whenever the error appears. A stronger corrective action would validate the state at the service boundary, add regression tests for the failure modes, and repair any affected persisted data. The team should then verify the new validation and tests under representative conditions.

How do corrective and preventive actions differ?

A corrective action responds to a problem that has actually been observed and aims to prevent that problem from recurring. A preventive action addresses a potential or related failure mode before it necessarily causes an incident. For example, fixing a faulty retry policy discovered during an outage is corrective, while applying a standardized retry policy and tests to similar services can be preventive. Both should have concrete acceptance criteria and a way to verify the intended risk reduction.

How would you prevent CAPA from becoming a list of vague follow-up tickets?

I would require each action to identify the failure or risk it addresses, an owner, priority, scope, and an observable completion criterion. I would also distinguish implementation from effectiveness: merging a change proves that work happened, but not necessarily that it reduced the intended risk. For important actions, I would define verification such as a regression test, alert exercise, metric change, or controlled failure test. Periodic review can close actions only after the agreed evidence is available.

How do you decide whether a CAPA should be a code change, test, monitoring improvement, or process change?

I would first identify the contributing failure mode and the control that could have prevented or detected it. If the defect is in application behavior, a code change may be appropriate; if the behavior can regress, automated tests provide a durable guard. If detection was the main weakness, observability or alerting may be more appropriate, while repeated operational mistakes may justify a process or deployment-control change. The chosen action should reduce risk without creating disproportionate complexity or a new operational hazard.