What to do after a data or security incident
- Aug 29
- 3 min read
Updated: 5 days ago
Introduction
A laptop is stolen from a car, or a member of staff realises they sent a spreadsheet to the wrong recipient, or an email account has clearly been accessed by somebody else. The instinct is to work out how bad it is before telling anybody.
That instinct costs you the only part of the timeline you control. Data protection regimes in most jurisdictions impose short notification deadlines that begin when you become aware, not when you finish investigating, and the response in the first day determines the regulatory position, the insurance position and what customers think. All three are decided before you know the full extent of what happened.
1. What to do after a data or security incident begins with containment
Stop it continuing.
Change passwords, revoke access, disconnect an affected device, halt the process that is leaking. This comes before investigation and before notification, because everything else is worse if it is still happening.
2. Preserve the evidence
Do not clean up first.
Logs, the affected device, the emails, and a record of what was noticed and when. Wiping and reinstalling a machine destroys the information needed to establish what actually happened.
3. Establish what data was involved
The question every obligation turns on.
Whose data, what categories, how many people, and whether it included anything sensitive. The answer determines whether notification is required and to whom, so it is the first thing to work out. Until you know whose data was involved, you cannot know what you are required to do.
4. Know your notification deadlines before you need them
Short and non-negotiable.
Many regimes require notification to a regulator within a small number of days of becoming aware, and notification to affected individuals where the risk is high. Find out your jurisdiction's rules now rather than during an incident.
5. Tell your insurer immediately
A policy condition and a practical benefit.
Cyber policies typically include incident response specialists and frequently require notification before you engage anybody. Appointing your own consultant first can prejudice the cover you are relying on. Insurers generally require their own panel to be used from the outset.
6. Write down the timeline as you go
Contemporaneous notes.
What was discovered, when, by whom, what was done and when. Regulators ask for this, and reconstructing it afterwards is both difficult and less credible than a record kept at the time.
7. Tell affected people honestly if you must
Handled well, it is survivable.
What happened, what data was involved, what they should do, and what you are doing. Attempting to minimise it produces far more damage than the incident when the full position emerges later.
8. Do not let one person carry it alone
Incidents run for days.
Somebody dealing with the technical side, somebody handling communication, and somebody making decisions. In a small business that means bringing in outside help early rather than exhausting the owner.
9. Fix the cause, not just the symptom
The part that is always skipped.
Whatever allowed it — an account without multi-factor authentication, an unencrypted laptop, a process that emailed data unnecessarily. Regulators ask what changed, and the same incident recurring is treated very differently.
Rehearse it briefly before it happens. Half an hour asking who would notice, who they would tell, who would make the decisions and where the contact details are surfaces gaps that are trivial to fix in advance and impossible to fix at eight o'clock on a Friday evening.
Conclusion
Move quickly, because the notification clock starts when you become aware rather than when you understand.
Contain the incident before investigating, preserve evidence instead of cleaning up, establish precisely what data was involved, know your jurisdiction's notification deadlines in advance, tell your insurer before engaging anybody, keep a contemporaneous timeline, inform affected people honestly where required, share the load rather than leaving it to one person, fix the underlying cause, and rehearse the scenario briefly beforehand.
.png)



Comments