If security evidence goes to the wrong customer, act in this order: revoke access or recall the message, ask the recipient to delete and confirm, work out exactly what was exposed and whose it is, involve legal and privacy for any notification duty, record the incident, then fix the process that allowed it.
First hour: contain
- Stop further spread. Remove the link, revoke the guest account, or recall the message if your system allows.
- Contact the recipient. Call or write promptly, politely and plainly. Say the file was sent in error and ask them not to open, forward or keep it, and to confirm deletion in writing.
- Preserve facts. Save the sent message, the file, the time, the recipients and the access logs before anything changes.
- Tell your incident lead. Treat it as a security incident from the start, even if it turns out small.
Speed matters more than polish. A short honest note to the recipient beats a perfect one sent tomorrow.
Assess what was exposed
Work through the file with a reviewer, not from memory:
- Which customer's information is in it: names, environments, product versions, findings?
- Was any personal data included?
- Did it contain credentials, internal hostnames, or unpatched vulnerability detail?
- Did the recipient open or download it? Access logs help here. See log who opened your shared security evidence.
- Could the content be used to attack the affected customer?
Write down the answers. This is what you will rely on when you decide whom to tell.
Decide on notification
This step needs your legal and privacy teams. Whether you must notify the affected customer, the recipient's organisation, or a regulator depends on the content, the contracts and the laws that apply to you. Do not guess. If personal data is involved, timelines may be short, so involve them early.
Even where no duty exists, many teams tell the affected customer anyway. Customers generally prefer hearing it from you, with a clear account of what happened and what you did. See customer breach notice: what to include for structure.
Find the cause
Most mix ups come from a few patterns:
| Cause | Fix |
|---|---|
| Autocomplete picked the wrong address | Send through a tool with named access, not free form mail |
| Pack folders copied between customers | Build packs from a base library with a manifest |
| Shared mailbox or thread reused | New thread per customer, never reply all |
| Customer specific details in generic documents | Separate base documents from customer content |
For the build side, see customer specific packs from a base library. A second person checking the recipient list before sending anything amber or red also catches most slips.
Close the loop
Record the incident, the decision on notification, and the corrective action. Review it with the team without blame, then update the checklist. Add the event to your sharing register so the history is visible.
Safeguard's compliance and evidence automation helps you keep documents generic and current, which reduces the chance that customer specific detail ends up in the wrong place. You can try a free scan for a sample export.
Quick check
Should you tell the recipient or the affected customer first?
Contain first by contacting the recipient, while you assess. Then decide on notifying the affected customer with legal and privacy advice, usually without delay.
Is a misdirected SBOM a serious incident?
It depends on the content. A generic SBOM may be minor. One tied to a customer's environment or with unpatched findings is more serious. Assess before deciding.
Last reviewed: 19 October 2026.
