Accidental Data Disclosure Response Playbook

Most personal data breaches are not attacks: someone shares a link too widely, attaches the wrong spreadsheet, uploads a file to the wrong place or pastes records into a tool they should not have used, and the data is now somewhere it was never meant to be. The ICO (since 30 September 2026 the Information Commission) describes accidental breaches as accidental disclosure to someone not authorised to see the information, caused by doing something you did not mean to do, skipping a step in a process, or acting without the training to do it correctly. The response is different from a cyber incident: there is usually no attacker to evict, but there is a clock, a risk assessment and a decision on whether to tell the regulator and the people affected. This playbook covers every common accidental channel (sharing links, uploads, mailing lists, published documents, AI tools and misplaced files), how to contain each one, what evidence to keep, and how to make a defensible notify or not decision. It is for privacy and data protection officers, security operations, IT administrators and the managers who receive the first "I think I sent this to the wrong place" message. Email-specific recall is covered in the Misdirected email and email recall guide; this page covers the wider response.

Key takeaways

Make reporting safe and fast. The first hour matters most, and staff only report quickly when they know they will be supported rather than blamed.
Contain by channel, not by habit. Revoking a link, deleting an upload, recalling a post and asking a recipient to delete are different actions with different evidence; pick the one that actually removes access.
The 72 hour clock starts at awareness. Under UK GDPR and EU GDPR Article 33, a notifiable breach goes to the regulator without undue delay and where feasible within 72 hours of the controller becoming aware of it.
Record every breach, reported or not. Article 33(5) requires the facts, effects and remedial action to be documented, so a decision not to notify must be written down with its reasoning.
Fix the process, not just the person. Repeated accidental disclosures point to defaults, tooling and missing checks, which are cheaper to change than behaviour.

How the incident shows up

Accidental disclosures are usually reported by a person, not raised by a detection rule. The sender notices, a recipient replies, a customer complains or a journalist calls. Some channels do leave a log trail you can alert on. Know the common channels and the signal each one gives.

Channel	Typical mistake	How it is usually noticed	Log or signal to check
Email	Wrong recipient, autocomplete, wrong attachment, recipients in To or Cc instead of Bcc	Sender realises, recipient replies	Message trace in the mail platform; see the misdirected email guide
Cloud file sharing	"Anyone with the link" or organisation-wide link on a sensitive file or folder; guest added by mistake	Recipient queries access, internal review, DLP alert	Microsoft Purview `AnonymousLinkCreated`, `AnonymousLinkUsed`, `SecureLinkCreated`; Google Drive log events with Visibility "Shared externally"
Published documents	Spreadsheet with hidden tabs, unredacted PDF, metadata, FOI or subject access response with third party data	Member of the public or press reports it	Web server and CMS logs, download counts, search engine index
Mailing lists and bulk mail	Personal data sent to a whole list, open distribution list, mail merge mismatch	Multiple replies, complaints	Mail platform delivery reports, list membership
Uploads to the wrong place	Customer file attached to the wrong case, ticket or portal account; file uploaded to a public repository	Wrong customer reports seeing it	Application audit trail, repository history
AI and online tools	Personal data pasted into an unapproved AI assistant, translation or formatting site	User self-reports, browser or proxy alert	Secure web gateway or CASB logs; see the Sensitive Data Pasted Into AI playbook
Physical and verbal	Post to the wrong address, papers left behind, details given on the phone to the wrong caller	Recipient returns it, complaint	Post room and call records

Two cases need extra care. A file shared with an "Anyone" link may have been copied and forwarded: Microsoft's own audit guidance says to assume any document with an anonymous link has been shared. And in Google Workspace, external viewers who were not explicitly shared on an item appear in Drive logs as anonymous, so the log tells you that access happened, not who it was.

Triage questions

Answer these in the first hour and write the answers in the incident record with the time you learned each one. They drive containment and the risk assessment.

What exactly was disclosed? File name, record count, data fields, and whether any special category data (health, ethnicity, religion, sexual orientation), criminal offence data, financial details, identity documents or children's data is included.
To whom, and how many? One known recipient inside a trusted organisation is a very different risk from an open link, a public web page or a list of thousands.
Is it still accessible right now? An open link, a live web page or an indexed document is an ongoing breach; a single delivered email is not, but the copy still exists.
Has anyone opened, downloaded or forwarded it? Check access logs before you change anything that would overwrite them.
Who is the controller? If you processed the data for a client, Article 33(2) requires you as processor to tell the controller without undue delay; the controller makes the regulator decision.
When did we become aware? Record the date and time a responsible person had a reasonable degree of certainty that personal data was affected. That is when the 72 hour window starts.
Is the recipient trustworthy and reachable? A professional recipient who confirms deletion in writing lowers the risk; an unknown or hostile one does not.
Is it accidental at all? If the "mistake" looks repeated, targeted or linked to a departing employee, switch to the Insider Data Theft Response Playbook.

Containment priorities

Work in this order. Stop new access first, then pull back copies, then reduce the harm that remains.

Stop ongoing exposure. Remove or change the sharing link, unpublish the page, take the file off the portal, remove the wrongly added guest or list member. Do this before anything else if the data is still reachable.
Preserve the access evidence as you contain. Export the audit records for the item (see Evidence to preserve) before deleting it, because some platforms tie log detail to the object.
Contact recipients. Ask each known recipient by phone and in writing not to open, forward or keep the data, to delete it including from deleted items and downloads, and to confirm deletion in writing. Keep the request short and factual.
Remove public copies. For a public web page, delete or password-protect the content first; Google's Removals tool can hide a page you control from results within about a day but only for about six months, so it is a stopgap, not the fix. Check other search engines and web archives.
Close the source. Correct the mailing list, mail merge, template, document or default sharing setting that caused the mistake so it cannot repeat while you investigate.
Protect the people affected. If the data enables fraud or harm (bank details, identity documents, addresses of people at risk), start mitigations now: flag accounts for extra verification, change exposed reference numbers or passwords, and consider safety steps for vulnerable individuals.

Channel	Containment action	What it does not fix
SharePoint or OneDrive link	Delete the sharing link or change it to Specific people; remove guests from the item; for a wide event, restrict the site's external sharing (Microsoft says guests typically lose access within an hour of the change)	Copies already downloaded or synced
Google Drive link	Change General access from "Anyone with the link" to Restricted; remove unexpected people and groups	Copies already downloaded; group members outside the organisation
Public web page or document	Delete or replace the file, purge CDN and cache, request search removal	Copies saved by visitors, scrapers or archives
Email or bulk mail	Recall where the platform supports it, then direct recipient contact	Messages already opened or forwarded
Upload to wrong account or repository	Remove the file, invalidate its URL, purge repository history if a secret or personal data was committed	Clones and forks already taken
AI tool	Delete the conversation and any uploaded files in the tool; ask the provider about deletion if it is an enterprise tenant	Data retained under the provider's terms

Eradication

For an accidental disclosure, eradication means removing every copy you can reach and every path that let the data out.

Find related exposures. If one sensitive file had an anonymous link, others in the same library probably do. Search the audit log for AnonymousLinkCreated on the same site or by the same user, or filter Drive log events for Visibility "Shared externally" across the folder, and review each result.
Check the whole artefact. For published spreadsheets and documents, check hidden sheets, hidden columns, pivot caches, comments, tracked changes and document metadata, not only the visible cells. Redaction that only blacks out text in a PDF layer can leave the text selectable.
Clean internal copies. Remove the data from shared mailboxes, ticket attachments, chat threads and sync folders where it was forwarded internally during the response.
Tighten the default that failed. In Microsoft 365, set the default link type to Specific people, require "Anyone" links to expire and restrict them to view-only, or remove "Anyone" from the sharing level for sites holding personal data. In Google Workspace, restrict link sharing defaults for the organisational unit concerned.
Add a control at the point of the mistake. Data loss prevention policy tips on external sharing, delayed send, external recipient warnings, bulk email through a proper mailing service instead of Bcc, and a second-person check before publishing FOI or subject access responses.

Recovery

Recovery is about restoring normal work safely and closing the loop with everyone involved.

Confirm containment: re-test the link or page from an unauthenticated session, and confirm the item no longer appears in search results.
Collect written deletion confirmations from every recipient and chase any that are missing. Record recipients who could not be reached.
Restore legitimate access that was cut during containment, using Specific people links or group-based access rather than broad links.
Support the staff member. Retraining is useful when the cause was a gap in knowledge; when the cause was a design flaw (an autocomplete, a default, a rushed process), fix the design and say so.
Monitor for misuse for a period proportionate to the data: fraud attempts against the affected accounts, complaints, or the data appearing online.
Run a short post-incident review within two weeks, and feed recurring causes into training, policy and tooling changes.

Evidence to preserve

Evidence supports both the risk assessment and any later regulator questions. Keep it with the breach record.

Evidence	Where it comes from	Why it matters
Copy of exactly what was disclosed	The original file, email or page, stored in a restricted location	Defines data categories and record counts for the risk assessment
Sharing and access audit records	Microsoft Purview Audit (Sharing and access request activities), Google Drive log events, CMS and web server logs	Shows whether the data was opened, by whom and when
Mail trace and delivery records	Mail platform message trace	Confirms recipients and delivery
Timeline of awareness and actions	Incident record with timestamps	Proves when the 72 hour window started and what was done
Recipient deletion confirmations	Emails or signed statements	A key factor in reducing assessed risk
Risk assessment and notification decision	Breach log, signed by the decision owner	Article 33(5) documentation; your defence if the decision is questioned

Export logs early. Audit log retention depends on platform and licence, and a breach found weeks later may already be at the edge of the retention window.

Notification triggers

The notify or not decision rests on risk to the people affected, not on whether the cause was malicious. The rules below are from UK GDPR as published on legislation.gov.uk; EU GDPR uses the same article numbers and tests with the relevant supervisory authority. For other jurisdictions see the Breach Notification Laws by Country Guide, and for the step by step filing process use the Data Breach Notification Checklist.

Test	Rule	Practical meaning
Is it a personal data breach?	The ICO describes a breach as leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data	An accidental disclosure to the wrong person is a breach, even if quickly recovered
Notify the regulator?	Article 33(1): without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals' rights and freedoms; late notice must give reasons for the delay	If you cannot say it is unlikely to cause risk, notify
Incomplete facts?	Article 33(4): information can be provided in phases without undue further delay	Do not wait for a complete picture to file
Processor role	Article 33(2): processor tells the controller without undue delay	Tell your client; they decide on regulator notice
Tell the individuals?	Article 34(1): where the breach is likely to result in a high risk, without undue delay, in clear and plain language	Tell people what happened, the likely consequences and what to do
Exceptions to telling individuals	Article 34(3): data protected, for example by encryption; later measures mean high risk is no longer likely; or disproportionate effort, in which case a public communication instead	Written deletion confirmation from a single trusted recipient can support the "no longer likely" argument; document it
Record keeping	Article 33(5): document all breaches, their effects and remedial action	Unreported breaches still go in the breach log

Factors that raise the risk: special category or criminal offence data, financial or identity data, vulnerable people, large numbers, a public or unknown audience, evidence that the data was opened or copied, and data that cannot be retrieved. Factors that lower it: a single known and trusted recipient, written deletion confirmed quickly, data that was encrypted or meaningless without other information, and no evidence of access. Other duties may apply alongside data protection law, such as contractual notice to clients, sector regulators and professional bodies. Where privilege matters for the investigation, see the Legal Privilege in Incident Response Guide.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Execute the response with third parties (recipients, processors)	RS.MA-01	IR-4 Incident Handling
Establish what happened and the root cause	RS.AN-03	IR-4
Notify regulators and individuals	RS.CO-02	IR-6 Incident Reporting
Control external sharing and public content	PR.DS-01	AC-21 Information Sharing, AC-22 Publicly Accessible Content
Feed lessons into process changes	ID.IM-03	IR-8 Incident Response Plan

Common failure patterns

Deleting before exporting. The file or link is removed in a panic and the access history needed to show nobody opened it is harder to recover.
Treating recall as containment. An email recall or link change does not touch copies already downloaded. Recipient contact and written deletion are still required.
Starting the clock late. Teams count 72 hours from when the privacy team heard, not from when the organisation became aware. Record the earliest credible time.
No record for non-notified breaches. The decision not to report is made verbally and never written down, which leaves nothing to show the regulator if a complaint arrives later.
Blaming the individual and moving on. The same default, template or mailing process causes the next breach. Fix the setting and add the check.
Visible cells only. A published spreadsheet is checked on screen and released with hidden sheets or source data intact.

Practitioner checklist

Publish one simple route for staff to report a mistake at any hour, and state that prompt reporting is expected and supported.
Keep a breach log that records awareness time, data categories, recipients, risk assessment, decision and decision owner for every incident.
Pre-write recipient deletion request templates by phone script and email.
Confirm audit logging is on for file sharing and know how to export Purview Audit or Drive log events within the first hour.
Set the default sharing link to Specific people or the most restrictive option, require "Anyone" links to expire, and review sites that still allow them.
Use a mailing service or mail merge, not Bcc, for bulk messages containing personal data.
Require a second-person check, including hidden content and metadata, before publishing any document derived from personal data.
Rehearse the notify or not decision with a tabletop exercise using two or three realistic accidental scenarios.

Accidental Data Disclosure Response Playbook: Contain and Assess Staff Mistakes That Expose Personal Data