Food traceabilityRecall exercises
Recall contact registers: verify ownership and scope before an incident
A contact register needs current responsibilities and a clear connection to the site’s approved response procedure. A list of phone numbers is incomplete if nobody knows which role should initiate contact or how changes are reviewed.

At a glance
A contact register needs current responsibilities and a clear connection to the site’s approved response procedure. A list of phone numbers is incomplete if nobody knows which role should initiate contact or how changes are reviewed.
Define the decision behind the record
Keep only the information required and protect access. Distinguish operational contacts, supplier contacts and other roles defined by the procedure. Do not infer legal notification requirements or contact order from a generic downloaded worksheet.
Define each contact’s role, coverage and maintenance owner
Identify which business or site relationship the contact supports and the role it serves. Record the relevant channels, authorised alternatives and the person responsible for keeping the entry current. A general business address may be reachable without being the appropriate contact for the intended incident communication.
Use the business’s approved method to verify information without initiating a false incident. Record the verification source and date and keep unresolved coverage questions visible. If one contact covers several sites, identify that scope explicitly rather than assuming the relationship extends to the whole organisation.
Review the register when relevant roles or business relationships change and as defined in the site procedure. Test retrieval for one actual supplier and one receiving business within an exercise. The user should find the relevant role and backup route without relying on private notes or an unverified name copied from an old email.
Worked example
During a scheduled review, a manager finds that a named contact has changed role. The register is updated with an identifiable review date, and the team checks the associated escalation responsibilities rather than merely replacing one number.
Build a usable record
Use the fields below to capture the facts needed for this particular decision. Keep the actual observation separate from any later correction or approval.
- Contact role and organisation
- Relevant site or product scope
- Current communication details
- Register owner and review date
- Approved escalation reference
Example record and review decision
Fictional record example: CONTACT-01: business, site, role, channel, owner and verification date; BACKUP-01: authorised alternative contact.
Establish who maintains the entry and what scope the contact covers. Use an approved verification method without initiating a real incident.
A reachable general inbox may not be the responsible incident contact for the specific site or business relationship.
Test the review, not just the form
Use an authorised contact-verification exercise where appropriate. Record what was actually confirmed. A successful delivery receipt or an unanswered test should not be presented as proof that the response arrangement works in every situation.
A few useful answers
Should contact lists be available to everyone?
Give access to the people who need it and protect personal information according to the organisation’s requirements.
Does a reachable inbox prove the contact is suitable?
It confirms only part of the question. The record should also explain role, business or site scope and the basis for using that channel, with a responsible maintenance owner.
Sources and further reading
MarkdownExplore starter templates
Start with a useful checklist
English



