Skip to main content
PRACTICE GUIDE · DATA PROTECTION

72 Hours: The Data Breach as a Process

When things go wrong, what counts is not how fast you react but how well the procedure was settled beforehand. We show where the usual path of a phone call and a notepad breaks down, and how the same process runs when it is structured.

How it works today when things go wrong

The sequence almost always begins in the same way. An employee from sales calls: she has sent a proposal folder containing customer data to the wrong distribution list. IT mentions in passing during the weekly meeting that a notebook was stolen from a car. Or a customer writes to the general mailbox saying she saw the addresses of two hundred other recipients in a mass mailing.

The data protection officer takes down the facts – on the phone, on a notepad, in an email to themselves. Then the clarification begins: what exactly happened, when, which categories of data, how many people, which system? The answers come back spread over two days, by email, in chat and in the corridor. In the end one row appears in "Incidents_2026.xlsx": date, short description, and in the column "notified" the entry "no". After that the file is touched once a year, when the report is due.

This is not negligence. It is the normal state of affairs in organizations that have not had a major incident so far. For two events a year this path holds. It holds exactly as long as nobody works out when the deadline actually started.

Because a clock is running alongside the clarification. Art. 33 GDPR requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours – from the moment the controller becomes aware of the breach. The controller is the organization, not the data protection department. The sales employee who notices the misdirected email is part of it. If she spends two days wondering whom to approach, the larger part of the deadline is used up before data protection hears the first word about it.

Then there is what the spreadsheet does not say. Which immediate measures were taken – was the distribution list blocked, the notebook wiped remotely, the password reset? Who decided that no notification would be made, and on what grounds? Was it checked whether the data subjects have to be informed under Art. 34 GDPR? These details exist as the recollection of individual participants, not as a document.

The moment it becomes obvious

This rarely becomes visible in day-to-day work. It becomes visible when a customer asks about incident management during a vendor review, when a supervisory authority picks up a notified case and wants to see how it was handled, or when the responsible person leaves the organization. The question is then not "Did you have any incidents?" but "When did you become aware, who decided what and when, and where is the justification?"

An incident list has no answer to that question. Not because it is badly maintained, but because structurally it knows nothing about points in time, decisions and responsibilities.

The analysis

Five gaps the informal reporting channel creates

They do not arise from a lack of care, but from the fact that the procedure is invented only once things have gone wrong – under time pressure and with incomplete information.

View inquiries and incidents in preeco

The deadline runs earlier than everyone assumes

The 72 hours begin with the awareness of the controller, not with the awareness of the data protection function. What an employee notices on Monday and passes on on Wednesday has already used up two thirds of the deadline. Without a recorded moment of awareness, it cannot even be evidenced later whether the notification was made in time.

Employees do not know where to report

There is no address, no form and no sentence in the onboarding that answers the question. So the staff ask their own manager first, then IT, and at some point the case lands with data protection. Each of these stops costs hours in which the deadline is already running.

The notification decision is not justified

The spreadsheet says "no" – but not why. Yet under Art. 33(5) GDPR all breaches have to be documented, including those not notified, together with their effects and the remedial action taken. Precisely this documentation is the evidence that an assessment took place at all.

Notifying data subjects is overlooked

Attention is directed at the supervisory authority. That in the case of a likely high risk the data subjects additionally have to be informed under Art. 34 GDPR falls through the cracks of the procedure. If it is noticed only weeks later, a manageable incident has turned into a second one.

Measures and analysis disappear

What was initiated immediately after the incident sits in an email thread, not in a document with responsible people and due dates. And because the incident list is opened only once a year, no pattern emerges: nobody sees that the same distribution list was affected three times.

The target process in six steps

Dependable incident management differs from the notepad not by more effort, but by a procedure that is settled before things go wrong. These six steps describe it – regardless of the tool you work with.

1. Create a reporting channel that everyone knows. A form in the intranet, linked from the onboarding and from training, reachable without a login. The threshold has to be lower than the deliberation about whether this is an incident at all. That assessment is not the task of the reporting person – their task is to get the case to the right place. Ten reports too many are better than one report too late.

2. Record the moment of awareness. As soon as a report arrives, a record with a timestamp is created. What is recorded is not only when data protection was informed, but also when the reporting person noticed the facts. The actual start of the deadline follows from these two details.

3. Record the facts in a structured way. Category, severity, affected categories of data, number of data subjects, cause, period. If the incident, the processing activity and the system in use are linked to each other, the categories of data and the recipients follow from the records instead of being collected all over again.

4. Assess the risk instead of estimating it. Likelihood of occurrence and severity of damage are judged separately and made visible in a risk matrix. This assessment is not an end in itself: it carries both follow-up decisions – the notification to the supervisory authority and the notification of the data subjects.

5. Document the notification decision, including the no. Every incident needs an unambiguous deadline status and a justification: notified in time, notified late with an explanation of the delay, or not subject to notification with the assessment that led to that conclusion. Templates are available for the notifications themselves – initial, follow-up and final notification to the supervisory authority, the notification of data subjects under Art. 34 GDPR, and the report to the controller by a processor.

6. Measures, lessons learned and analysis. Every immediate and follow-up measure gets a responsible person and a due date. The incident is not closed because the excitement is over, but when the measures have been implemented. What was learned is recorded with the case and feeds into the regular reporting.

Why preparation counts for more than the speed of reaction

The reflex when things go wrong is speed. In fact little can be accelerated in the first few hours: the facts have to be clarified, the risk judged and the decision taken – that takes as long as it takes. Only what was settled beforehand gets faster. If the staff know the reporting channel, the case reaches the right place in minutes instead of days. If templates and an assessment scheme are ready, the notification is drafted in an afternoon instead of over a weekend. If processing activities and systems are maintained, the question about categories of data and recipients is a query and not a research project. Anyone who creates these foundations only during the incident loses exactly the time the deadline does not allow.

Before and after in direct comparison

Criterion Before: phone call and incident list After: structured incident process
Reporting channel Everyone asks somebody else first One known form for all employees
Start of the deadline Unknown, because it is not recorded Timestamp from awareness, deadline runs visibly
Recording Free text from a phone call and an email thread Structured fields with category and severity
Risk assessment Gut feeling in the individual case Likelihood of occurrence and severity of damage in the risk matrix
Notification decision A column with "yes" or "no" Deadline status with a documented justification, including for non-notification
Notification of data subjects Easily overlooked in the procedure A check of its own under Art. 34 GDPR, with a template
Measures Scattered across an email thread Documented with the incident, with responsible people and due dates
Reporting and evidence A spreadsheet opened once a year Activity log and status report at the push of a button

In practice

What this looks like in preeco | data protection

The three building blocks that carry the procedure described above.

What the switch means in practice

The effort does not lie in the technology but in two decisions. The first: where do employees report, and how do they find out about it? A form is set up in an hour; everyone knowing about it grows out of onboarding, training and a mention at the staff meeting. The second: who decides on the notification, and who stands in for that person during vacation? An incident process that hangs on a single person is not a process for three weeks of the year.

Transferring existing incidents from the spreadsheet retroactively is usually not necessary. What makes sense is to run the last documented case through the new procedure once – as a rehearsal, not as a migration. That quickly shows which details have been missing so far.

Three mistakes that make the process ineffective

Making the reporting channel known only within data protection. If the staff do not know that it exists, nothing changes about the start of the deadline. The reporting channel belongs where employees look first when in doubt.

Delegating the assessment to the reporting person. Anyone who is expected to check first whether something is subject to notification will, in case of doubt, not report at all. The facts are reported; the assessment is made by the responsible function.

Closing the incident with the notification. The notification is an intermediate step. Measures, follow-up notification and analysis remain open – and that is exactly what the audit asks about.

How to tell that it is time

A notepad and a spreadsheet are not a mistake. They become a risk as soon as one of these points applies:

  • For none of your incidents can you evidence when awareness occurred.
  • Employees outside data protection cannot name the reporting channel.
  • There is no written justification for incidents that were not notified.
  • The check under Art. 34 GDPR is not a step of its own in your procedure.
  • Immediate measures exist only in emails, not with the incident.

If none of this applies, your procedure is sound. If two or more apply, chance decides once things go wrong.

FAQ

Frequently asked questions about data breaches

With the awareness of the controller – that is, of the organization, not of the data protection department. If an employee notices a personal data breach in the course of her work, that awareness is attributed to the controller. The notification has to be made without undue delay and, where feasible, within 72 hours; if it is made later, reasons for the delay have to accompany it. In practice that means the internal reporting channel decides how much of the deadline is left for the handling at all.

No. The obligation to notify does not apply where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. You do, however, have to make this assessment, justify it and record it – the assessment itself is not optional, only its outcome is open. A structured process therefore distinguishes cleanly between "not subject to notification" and "not assessed".

Under Art. 34 GDPR, when the breach is likely to result in a high risk to the rights and freedoms of the data subjects. The notification has to be made without undue delay and has to describe the nature of the breach in clear and plain language. Art. 34(3) GDPR provides for exceptions, for instance where the data were effectively encrypted or where subsequent measures have eliminated the high risk. Checking this question belongs in the procedure as a step of its own, otherwise it gets lost between clarifying the facts and notifying the authority.

Just as carefully as one that was notified. Art. 33(5) GDPR requires the documentation of all personal data breaches – including the facts, the effects and the remedial action taken. In the case of non-notification, the assessment that led to that decision has to be recorded in addition. This documentation serves the supervisory authority as evidence that the incident was recognized and judged.

All employees – and that is precisely the point. Since the deadline begins with awareness inside the organization, the internal report has to be as low-threshold as possible: a known address or a form on the website or in the intranet, without any prior check of whether the case really is subject to notification. The assessment under data protection law is then made by the responsible function, not by the reporting person.

Play your incident process through once

Bring a real case from your organization with you. In 30 minutes we will go through the reporting channel, the start of the deadline and the documentation together.