Record the facts before asserting conclusions: what material was sent, to whom it actually went, through which channel and what delivery evidence exists. Take the containment steps you are authorized to take, stopping further sends and routing any recall or deletion request through the incident owner. The UK ICO's breach guidance directs an assessment of the information affected and the risk to people, with the incident and response recorded; reporting depends on that risk, not on the bare fact of a wrong recipient. Do not declare the incident legally reportable or harmless from a single fact. Keep the customer content itself in restricted systems and out of shared worksheets.
For: An authorized staff member or incident owner at a research-only merchant responding to a customer record that was sent to the wrong recipient.
Stop the error from repeating before documenting it. Halt any queued resend, make sure nobody forwards the message to explain the mistake, and check whether the same recipient is sitting in a saved reply, autocomplete entry or draft that could produce a second send. Containment comes first, but it should not destroy the evidence of what happened.
Route any recall or deletion request through the incident owner rather than improvising one from a personal mailbox. An unanswered deletion request is a request, not a result; record what was asked, when, and what confirmation, if any, came back.
Stop further sends to the wrong destination.
Do not circulate the record to show colleagues the problem.
Send recall or deletion requests only through the authorized owner.
Preserve the original message and its metadata in a restricted location.
Record the minimal facts
Capture the category of material disclosed, such as an order confirmation, an invoice, an attachment or a message thread, without copying its contents into the incident worksheet. Record the actual recipient as established by evidence, the channel and system used, the send time, the sender and how the error was discovered. Distinguish the discovery timeline from the send timeline; they are often hours or days apart.
Name the error type precisely, because each implies a different corrective fix: the right record sent to the wrong person, the wrong attachment added to the right thread, or an autocomplete selection that substituted a similar address. A vague note that an email went wrong leaves the process fix unassigned.
Separate evidence from assumption
A send record is not proof of delivery, delivery is not proof of reading, and a deletion request is not proof of deletion. Write down the strongest conclusion the evidence supports and, beside it, the gap that remains. If the recipient's identity or their handling of the record is unknown, say so rather than filling the gap with the reassuring version.
Resist two symmetrical temptations: declaring that nothing was exposed because you cannot confirm it was read, and declaring that everything was misused because you cannot confirm it was deleted. Both are assertions beyond the evidence, and the incident owner needs the honest middle recorded.
Route the assessment to the incident owner
The UK ICO's breach guidance directs organisations to assess the information affected and the risk to people, and to record the incident and the response. Reporting to the regulator depends on that risk assessment; a single wrong recipient is not automatically a reportable breach, and a quiet outcome is not automatically a safe one. That guidance is UK-specific, and notice duties, thresholds and timing in your own jurisdiction need qualified review. This page states no deadlines.
Staff contribute facts; the incident owner contributes the assessment and any notification decision. If your business has no named incident owner, the business owner assigns one now and uses the relevant provider or adviser guidance rather than leaving the assessment with whoever noticed the mistake.
Close with a corrective change
Every incident of this kind ends with a process fix tied to the error type: an address-verification step for outbound customer records, a review of saved replies and autocomplete habits, or an attachment checklist before sending. Record the fix, its owner and its date alongside the incident facts so the record closes the cause and not only the message.
For a Prism consultation about the website or communication workflow involved, describe the website, the research-only catalog and a non-sensitive summary of the incident type. Keep the customer record, its contents and any identity material out of the public form. Scope, responsibilities, fees and terms are agreed before work, and a consultation is not an incident-response service or a legal determination.
Exposure fact record
Complete one record per incident. Use categories and references, not customer content. Unknown delivery or recipient facts stay unknown until evidence exists. The final column is left for your dated record and owner.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Exposure fact record. The last column is for temporary notes.
Fact to establish
What to record and the decision it supports
Your record
Material disclosed
What to record and the decision it supportsCategory of record and field types involved, without copying content. Sizes what the recipient could have seen.
Actual recipient
What to record and the decision it supportsWho received it as established by evidence, not assumption. Determines containment and the later risk assessment.
Channel and send event
What to record and the decision it supportsSystem, message reference, time and sender. Anchors the incident to a verifiable record.
Delivery status
What to record and the decision it supportsSent, delivered, opened or unknown, per available evidence. Prevents a send record from being read as proof of reading.
Discovery
What to record and the decision it supportsHow and when the error was found and by whom. Separates the discovery timeline from the send timeline.
Containment taken
What to record and the decision it supportsRecall attempt, deletion request or access restriction, with authorizer and time. An unconfirmed request stays unconfirmed.
Assessment handoff
What to record and the decision it supportsIncident owner who will assess the information affected and the risk to people. Reporting decisions need that assessment, not the fact of error alone.
Corrective change
What to record and the decision it supportsThe process fix approved to prevent recurrence, with owner and date. Closes the cause, not just the single message.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
ICO breach guidance is UK-specific; whether and when to notify in your jurisdiction needs qualified review, and this page states no deadlines.
A wrong recipient is not automatically a reportable breach, and a confirmed deletion request is not proof the record is gone.
Keep customer record contents, identity documents and credentials out of the worksheet and the public consultation form.
This is an internal fact record, not legal advice or an incident-response service commitment.
ICO: Personal data breach reporting — checked 2026-10-01. The ICO directs organisations to assess the information affected and the risk to people and to record the incident and response; reporting depends on that risk assessment, and the guidance is UK-specific.
Prism contact — checked 2026-09-21. The inquiry asks for the website, products and question, excluding payment card details, passwords and customer records; follow-up is by email and the request is not an appointment, purchase or processing application.