BRCGS Mock Recalls and Incident Management: Testing Your Recall Plan Properly

By Robert Low, Director, Lead Auditor & BRCGS Approved Trainer

Every certificated site has an incident management procedure with recall and withdrawal provisions, and every one of them tests it at least annually. The difference between sites is what that test actually tests. Too many mock recalls are a traceability exercise wearing a costume: pick a batch, trace it, file the result. A real test proves the plan works under pressure, because a real incident will not wait for you to find the procedure.

Design a Scenario, Not a Trace

Start from a plausible incident: a customer complaint suggesting contamination, a supplier notifying you of a non-conforming material already used, a test result that puts released product in doubt. Now run the procedure from that trigger. Who assesses severity and decides withdrawal or recall? Who is contactable, today, right now, and who deputises for the incident lead on holiday? The traceability element sits inside the test, identifying affected batches and where they went, and yes it should be timed and reconciled with mass balance as covered in my traceability test guide, but the trace is one component, not the test.

Test the Communications

The part that fails in real incidents is rarely the trace, it is the phone tree. Are the key contacts in your plan still in those jobs? Do you have out-of-hours numbers for your customers’ technical teams, your CB, your logistics providers? Draft the customer notification during the test, against the clock, because writing your first recall communication live during a genuine incident is a miserable experience I would not wish on anyone. And note the Issue 5 direction of travel: significant product safety or legality incidents notified to your certification body within 3 working days, with meaningful follow-up information inside 21 calendar days. Build that notification step into the test now, as my Issue 5 breakdown covers.

Record Timings, Then Improve Something

The test record should capture the timeline of key activities, trigger to decision, decision to batch identification, identification to draft notification, and the gaps it exposed. Then treat those gaps like any other finding: root cause, action, verification, the CAPAVA discipline. A mock recall that produces no improvement action either found a perfect system or was not looking. I know which is more common.

Vary the scenario year on year, include traded and outsourced product if you handle it, and occasionally run it unannounced internally, the difference is educational. I design and facilitate mock recall exercises remotely, awkward scenario included. Buttons below.