What to Do After a Data Breach: A Plan for the First 72 Hours

Data breaches rarely start the way films suggest. An employee says "I cannot get into my account" one morning. Or a customer calls about "a strange e-mail I thought came from you". Or accounting notices a payment instruction nobody sent.

What happens in that first half hour determines how big the incident becomes. This article sets out a response plan that replaces panic with order.

This article is for information only and is not legal advice. For the scope and format of notification duties, rely on your data protection authority's current guidance and consult your own legal adviser.

What counts as a data breach?

Limiting the idea to large attacks is a common mistake. In practice a breach also happens when:

• An e-mail account is compromised.
• A customer list is sent to the wrong person.
• An unencrypted laptop or drive is lost or stolen.
• A misconfiguration leaves a folder publicly accessible.
• An incident at one of your suppliers also covers your data.
• Ransomware encrypts your data.

The last two are the most frequently overlooked. Data not sitting with you does not remove your responsibility; we covered how to measure supplier-side risk in supplier management and spend analytics.

The first hour: stop the bleeding, preserve the record

Three jobs, and the order matters.

1. Cut off access. Change the password on the affected account and end its open sessions. Disconnect a suspect device from the network. Revoke the key, token or sharing link believed to be exposed.

2. Preserve the logs. The most common mistake here is wiping and rebuilding the system immediately. It feels like stopping the bleeding, but it also destroys any chance of understanding what happened — and leaves you with no answer to "which data was affected" when you notify. Stop logs from being overwritten, take screenshots.

3. Name an owner and start writing. One person owns the incident. From that moment every step gets recorded with a timestamp: when it was noticed, what was done, who was informed. That record serves both the internal review and the notification.

How the 72-hour rule works

Türkiye's data protection law requires a controller to notify the affected person and the Board as soon as possible when personal data is unlawfully obtained by others.

A 2019 decision of the Personal Data Protection Board applies that "as soon as possible" as a maximum of 72 hours, with notification made through the Board's data breach notification form.

Three points are worth underlining:

The clock starts when you learn of it — not when the incident occurred, but when you became aware. That is why recording the moment of discovery matters.

You do not have to know everything first. Notifying within the window does not require a completed investigation; you notify with what is known and complete it afterwards.

Affected individuals must be told too — not only the authority. The wording should be plain and actionable: what happened, which data types were affected, what the person should do, and how to reach you.

We gathered the general framework in our data privacy compliance guide for SMEs; for penalties and figures the authority's own site is the only reliable source.

Communication: silence is the most expensive option

The most common mistake in breach communication is waiting for certainty. When a customer hears about the incident from somewhere other than you, the trust lost outlasts the incident itself.

A notice that works contains four things: what happened in plain language, which data types were affected, what the person should do, and how to reach you. Not elaborate apologies and technical jargon.

Set up internal communication at the same time, so the team knows what to say. Five different answers to the first question reaching support turns one incident into two.

The source is usually an e-mail

Most of the breaches we see in the field start not with a sophisticated attack but with a compromised account. Which means the real protection sits there: multi-factor authentication, a password manager, and a team that recognises a suspicious message.

That makes the reflexes in phishing protection less a security topic than a continuity one. On the recovery side, the habits in data security and backup are decisive: in a ransomware case, the only thing that lets you walk away from the negotiating table is a backup you have actually tested.

Fit the plan on one page

An incident response plan does not need forty pages. This is enough:

• Who calls whom: names and phone numbers, reachable somewhere outside the system.
• Technical steps for the first hour: cutting access, preserving logs.
• Notification owner and deadline tracking: who watches the 72-hour window?
• Draft communications: for customers, suppliers and the team.
• A post-incident section: what gets fixed, by whom, by when.

This can live as a section of the document described in business continuity and disaster recovery. The shared rule is the same: a plan never rehearsed once a year with a tabletop scenario is not a plan.

The three most common mistakes

Trying to shrink the incident. "Probably nothing leaked" is both wrong and dangerous when said without looking at the logs. The wish to narrow the scope is understandable, but the call has to come from data.

Leaving it to one person. Whoever spots the incident usually ends up owning it, yet handling technical response, communication and record-keeping at once exceeds what one person can do. Split the roles from the start.

Losing track of the clock. In the technical rush, the 72-hour window is missed surprisingly often. The person watching it should not be on the technical team; a name that stays out of the hands-on work is safer.

After the incident: the most valuable part

The step most often skipped is the review once the crisis passes. Half an hour is enough: how did they get in, why did we notice late, which control would have prevented this?

Write the three items that come out with a date and an owner. The same incident happening twice does not double the cost of the first one — it ends the trust entirely.

If you would like us to draw up your incident response plan, review your logging and access arrangements, or get your notification process ready in advance, get in touch; you can also look through our services to see how we work.