A corrective action stops a problem recurring. Most of what gets recorded as one is a repair — the thing you do to the affected item, which changes nothing about the next occurrence.
A corrective action is a change made so that a problem which has already occurred does not occur again. That definition rules out most of what gets logged under the heading. Replacing the faulty part, refunding the customer, redoing the report — those are corrections. They deal with the instance in front of you and leave the mechanism that produced it entirely intact.
The distinction sounds pedantic until you look at a register where the same issue appears four times in a year, each with a corrective action recorded and closed. What was recorded was the repair, and the repair works exactly once.
Grading matters as much as the distinction. Not every issue deserves a full investigation, and treating all of them alike is how CAPA systems collapse under their own weight. A quick assessment of severity and recurrence decides whether something gets a correction and a note, or the full analysis.
Almost every weak CAPA register has the same shape: actions defined, actions implemented, actions closed the same week. Effectiveness verification requires waiting — a month, a quarter, however long it takes for the situation to arise again — and checking whether it did. Without that step the register records intentions, and an auditor reading it learns only that somebody wrote something down.
Verification also catches the common failure where the action was implemented but did not work, or worked and created a new problem somewhere else. That is not rare and it is not embarrassing; discovering it a year later, from a customer, is.
When an investigation ends at somebody made a mistake, the action recorded is almost always retraining or a reminder. It is fast, it is cheap and it very rarely works, because the conditions that made the mistake likely — an ambiguous form, two similar part numbers, a step with no confirmation — are unchanged, and the next person will hit the same conditions.
The stronger question is what made the error easy. Answers that change something physical or procedural — a check that catches it, a field that cannot be filled wrongly, a step reordered — survive staff turnover. Training is a supplement to those, not a substitute.
Ettex Records suits this shape: one row per issue with the description, the correction, the cause, the action, the owner, the due date and the verification date, filterable to what is open, what is overdue and what is awaiting verification. That last filter is what makes the process real rather than aspirational — the pending-verification list is the one people otherwise forget.
It is a register rather than a quality system. There is no workflow with approval gates, no electronic signature, no audit trail meeting a regulated standard, no linkage from an action to a controlled document revision, and no effectiveness reminders that fire by themselves. Where a regulator prescribes how CAPA must be managed — pharmaceutical, medical devices, aerospace — that specification governs, and dedicated validated software is usually the right answer rather than a general register.
A change made so that a problem which has occurred does not recur. It follows an investigation into the cause.
A correction fixes the affected item — the rework, the refund. It does nothing about the next occurrence.
Corrective and preventive action taken together: fixing causes of problems that occurred and addressing causes of problems that plausibly could.
Without checking after enough time has passed, a register records intentions rather than outcomes — including actions that were implemented and did not work.
Rarely on its own. If the conditions that made the error easy are unchanged, the next person will make the same one.
No. Grade by severity and recurrence — treating everything alike is how the process becomes unmanageable.
Separate the repair from the fix, distrust investigations that end at human error, give every action one owner and a date — and never close one before verifying it worked.
A conflict of interest policy is mostly a register and a habit. The point is not to forbid overlapping interests but to have them written down before anyone has reason to ask.
A record of processing activities lists what personal data you hold, why, where it goes and how long you keep it. It is dull to build and it answers half the questions anyone will ever ask you.
A performance review is a conversation with a written record attached. Most of what makes it useful happens in the eleven months before it, and most of what makes it dreaded is the surprise.