ProductSafety.help
The Safety File - preventive product safety, filed in order

Closing the loop after a safety investigation: telling customers, fixing the cause, and proving the fix worked

Closing the loop means completing the investigation, communicating the outcome to those affected, changing the cause, and verifying that the change worked, rather than filing the investigation as soon as a decision is made.

What does closing the loop actually mean?

Closing the loop after a safety investigation means finishing all the work an investigation implies, not only reaching a decision. It means telling affected customers what was found and what was done, in terms they can understand, without disclosing confidential details that do not help them. It means changing the cause, whether that is a design, a component, a supplier, a process or an instruction, so the same failure does not recur. And it means verifying that the change worked, through retesting, trial batches or monitoring of new production, rather than assuming a change that was ordered is a change that worked. An investigation filed before those steps are complete is not closed; it is abandoned with a decision attached.

How should investigation outcomes be communicated?

Investigation outcomes should be communicated to affected customers in plain language, stating what was found in general terms, what action was taken, and what the customer should do now, if anything. Customers who reported the original problem should receive a personal follow up where possible, thanking them and telling them the outcome, since their report started the investigation and their trust depends on hearing its conclusion. Wider owners, where a corrective action affects them, should receive the corrective action message through the appropriate channels, with the remedy and the contact route clearly stated.

How should the cause be changed, not only the symptom?

Changing the cause means addressing the underlying reason a failure occurred, not only replacing the failed part in affected units. If a failure was caused by a component change that was not retested, the cause change is a retest requirement for such changes, not only a replacement of the failed component. If a failure was caused by an instruction that users misunderstood, the cause change is a rewritten instruction tested with users, not only a warning added to a listing. If a failure was caused by a supplier process drift, the cause change is a tightened incoming check or a supplier process fix, not only a new batch from the same drifting process.

Illustration: an investigation into a leaking kettle found that the cause was not a faulty seal batch, but a seal design that failed when kettles were descaled with a common household method. The seller changed the seal design and the descaling instruction, rather than only replacing seals, and monitored new kettles for leaks after descaling. The story is illustrative, and the lesson is to ask why the failure occurred, and why it was not caught earlier, before deciding that replacing the failed part closes the investigation.

How is a fix verified, and for how long?

A fix should be verified by testing new production, by trial batches, or by monitoring new complaints for the same failure, depending on the fix type. A design fix should be verified by retesting the corrected product under the conditions that failed. A supplier fix should be verified by testing trial batches from the corrected process. An instruction fix should be verified by user testing the new instruction. Verification should continue for a period proportionate to the risk, with a review date to assess whether the fix held, rather than a single verification that is then forgotten. If verification shows the fix did not hold, reopen the investigation, rather than closing it on the basis of an intended fix that failed in practice.

Record verification results in the investigation file, linked to the original signal and decision, so a later reviewer can see not only what was decided, but whether it worked. A verification record that shows a fix held over several batches is strong evidence of loop closing; a verification record that is missing suggests the loop was closed on intention rather than on evidence.

When is an investigation truly closed?

An investigation is truly closed when customers have been told, the cause has been changed, the fix has been verified, and a closing note has been written that a future team can understand: what happened, what was found, what was done, what was verified, and what changed in design, supplier, testing or instructions. That closing note should be filed with the monitoring log and the product file, and the product should return to routine monitoring, with the original failure words watched for recurrence. Closing with that note, and with routine monitoring resuming, completes the loop; closing without it leaves a file that future teams cannot learn from.

A loop closing checklist for the next investigation

For the next investigation, use a loop closing checklist: customers told, cause changed, fix verified, internal teams informed, closing note written, routine monitoring resumed. Complete each item, with dates and names, before marking the investigation closed. That checklist, used consistently, turns loop closing from a vague intention into a completed routine, and it ensures that investigations lead to lasting improvements rather than to filed decisions that change nothing.

Sources and evidence on the record

  • Regulation (EU) 2023/988 (GPSR), EUR-Lex - the general product safety regulation, applicable from 13 December 2024.
  • European Commission product safety, European Commission - product safety policy and guidance.
  • International Organization for Standardization, ISO - international standards.

Evidence basis: General information drawn from official law and guidance listed below; worked examples are labelled illustrations, not measurements. Applies when: This guide helps when an investigation has reached a conclusion and the work of closing it properly remains.

Next in the file