What to Do After a Data Breach: The First 72 Hours
A practical hour-by-hour guide for small organisations: contain the breach, preserve evidence, work out who is affected and meet any notification duties.
Most small organisations do not have an incident response team. They have a person who notices something wrong: a mailbox sending messages nobody wrote, a laptop left on a train, a spreadsheet emailed to the wrong client. What happens in the next three days decides how bad it gets. In short: contain first, preserve evidence, work out what data and whose, decide on notifications, then fix the cause. Keep a written log of every step from the first minute.
Hour 0 to 4: contain
- Stop the leak. Reset the compromised password, sign the account out of all sessions, revoke suspicious app access, disable a lost device remotely, recall or ask the recipient to delete a misdirected email.
- Do not wipe or rebuild yet. Isolating a machine from the network is fine; reformatting it destroys the evidence you will need.
- Start the incident log. Time, what was noticed, who noticed, what was done and by whom. One shared document, written as you go.
- Name one person in charge. Decisions by committee in the first hours lead to contradictions later.
Hour 4 to 24: understand
Now work out the scope. Which systems, which accounts, which records? Pull sign-in histories, sharing logs and access logs before they roll over. Many services keep them for a limited period only. Ask:
- What kind of data was involved: contact details, identity documents, financial, health, case files?
- How many people are affected, and who are they: clients, staff, research participants?
- Was data actually accessed or taken, or only exposed? Is there evidence either way?
- Is it still happening?
Write down what you know and what you do not know yet. "Unknown" is an honest and useful entry.
Hour 24 to 72: decide and notify
Many data-protection regimes require notifying a regulator within a short window after you become aware of a breach that poses a risk to people, and some require telling affected individuals directly when the risk is high. The deadlines and thresholds differ by jurisdiction and sector, so check yours now, not on day three. Contracts with clients may carry their own notice duties too. If you are unsure whether a breach is notifiable, record your reasoning either way: a documented decision not to notify is far better than no decision.
When you tell affected people, be plain: what happened, what data, what you have done, what they should do (change a password, watch for phishing), and who to contact. Do not speculate and do not minimise.
After 72 hours: fix the cause
Most small-firm breaches trace back to a handful of causes: a phished password, a reused password, no second factor, over-broad sharing, or a device without encryption. Fix the actual cause, not just the symptom. If it started with a phishing email, read how small firms actually get caught; if an account had no second factor, roll out two-factor to everyone.
Prepare before you need it
- Know where your sign-in and access logs live and how long they are kept.
- Keep a one-page contact list: who decides, your IT support, insurer, legal adviser, regulator.
- Know which of your records hold the most sensitive data, and who can reach them.
- Rehearse once: walk through a lost laptop scenario in thirty minutes.
A breach handled well is mostly a breach that was written down well. The log you keep is what you will show the regulator, the insurer and, eventually, yourself when you review what to change.
