Incidents: What To Do When Data Went In
Somebody pasted something they should not have. The first hours, the assessment, and the part most organisations get wrong.
Governance · Procedure
This will happen. How the first one is handled determines whether you hear about the second.
The recommendations in “Incidents: What To Do When Data Went In” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating the product overview can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.
For an independent benchmark, compare the local approach with OWASP GenAI Security Project; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.
The first response
Thank the person for reporting it.
This is not a courtesy — it is the single decision that determines your future visibility.
An organisation where the first reporter had a difficult conversation will not hear about anything again.
Establishing the facts
What was sent, specifically: which document, which fields, how much.
To which service, under which account type.
When.
Whether it was a one-off or a pattern.
Twenty minutes with the person, who usually knows exactly.
Containment, such as it is
Delete the conversation from the account, which most services support and which removes it from the user-visible history.
Request deletion from the provider where the terms allow it; enterprise agreements usually do and consumer tiers usually do not.
Rotate anything rotatable: credentials, keys, tokens.
Be honest that deletion requests do not guarantee removal from backups or from anything already processed.
Assessing the actual exposure
Who else can see it: for a consumer account, the provider's staff under their review terms, and anybody with access to that account.
Whether training use applies, which depends on tier and settings.
Whether the data was regulated or client-contracted, which determines whether anybody must be told.
This assessment is where the earlier work on terms pays off, because the answers are already in the inventory.
Notification
General orientation, not legal advice; thresholds and timescales differ by jurisdiction and contract.
Personal data may trigger a regulatory notification obligation with a short deadline.
Client-confidential material may trigger a contractual one.
Take advice quickly rather than deciding internally that it is below the threshold.
What usually turns out to be true
Smaller than feared: a paragraph rather than a document, internal rather than confidential.
And caused by selection rather than intent, which the paste note covers.
Say so when reporting it, because an accurately-sized incident report is what keeps the response proportionate.
Afterwards
Record it, with what caused it.
Fix the cause if there is one: a missing tool, an unclear rule, a redaction control that would have warned.
And tell the organisation, in aggregate, that it happened and what changed — which does more for compliance than any training module.
What to check
Is there a route to report this, and does anybody know it?
What happened to the last person who reported something?
Could you establish what a given tool's deletion terms are, today?
And has an incident ever changed a control here?
The point
Thank whoever reported the incident.
That single decision determines whether you hear about the next one.
Underlying all of this
Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.
The recurring pattern
The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.