Prevention that sticks: CAPA & the hierarchy of controls

A fix you have to remember is a fix that decays — the strongest controls don’t depend on anyone behaving.

The idea

Corrective action repairs this occurrence. Preventive action removes the whole class of cause so it can’t happen the same way again. The two are different jobs, and closing an incident with only the corrective half is how the same failure comes back next quarter.

When you choose the preventive action, rank the options by the hierarchy of controls: eliminate, substitute, engineer, administrate, retrain. The higher you reach, the less the fix relies on a tired human doing the right thing — and “we told them to be more careful” is the weakest rung there is.

How it works

Two questions, always asked in order:

1 · Corrective, then preventive. First stop the bleeding on the current occurrence. Then ask the harder question: what class of cause let this happen, and how do I remove it? A CAPA that only answers the first question isn’t finished.

2 · Rank the preventive options by the hierarchy. Reach as high up the ladder as is feasible. Effectiveness climbs as human dependence falls:

strongest  ELIMINATE     remove the hazard         no human needed
           SUBSTITUTE    swap for a safer design   almost none
           ENGINEER      guard / interlock         built into the tool
           ADMINISTRATE  procedure, checklist      relies on adherence
weakest    RETRAIN       "be more careful"         relies on memory

recurrence risk stays FLAT for eliminate / substitute / engineer
recurrence risk CREEPS BACK for administrate / retrain
  -> people forget, staff turn over, the shortcut returns

The bottom two rungs still matter — but only as a layer on top of a stronger control, never as the whole fix. And every near miss is free failure data: it’s the warning that a weak control is drifting, arriving before the real failure does.

When to use it

Watch out for

• Closing the CAPA with only a corrective action. “Restarted the service, incident resolved” fixes the occurrence and leaves the cause class untouched. Name the preventive action explicitly.
• Defaulting to retraining because it’s cheap. “Reminded the team to double-check” feels like action but sits on the weakest rung — it fades with the next hire.
• Treating near misses as good news. A caught near miss means the control nearly failed. Log it, count it, act on it — it’s the cheapest failure data you’ll ever get.
• One control, no depth. Even a strong engineering control can fail; a thin administrative layer behind it catches the rare miss. Prefer layers over a single barrier.
• Not verifying the fix held. A preventive action isn’t done when it’s installed — it’s done when months of data show the recurrence curve stayed flat.

Worked example

Interview prompt: “An engineer deployed a config that took down checkout because they skipped the staging step. What’s your fix?”

Weak answer stops at: “I’d roll back and remind the team to always test in staging.” That’s a corrective action plus the weakest control — the next new hire will skip staging again. A strong answer climbs the ladder: “Corrective: roll back and restore checkout. Preventive: I’d engineer it out — make the deploy pipeline physically refuse a production push that hasn’t passed staging, so the unsafe path no longer exists. As a backing layer, a checklist and clearer ownership. And I’d watch the near-miss rate — blocked deploys that would have skipped staging — as the signal the control is working.” That answer shows you know corrective from preventive, and that you reach for a control that doesn’t decay.

Check yourself