Data breach response process flowchart (GDPR 72-hour clock)

What the data breach response process flowchart (gdpr 72-hour clock) process is

A personal data breach is any security failure that leads to personal data being destroyed, lost, altered, disclosed or accessed without authorisation, whether by accident or on purpose. Most of them are not cyber attacks. They are an email sent to the wrong recipient, a spreadsheet with the hidden tab left in, a laptop left on a train, a file share opened to everyone, a backup that turns out to be unrecoverable. The process below is triggered by a suspicion rather than a confirmed finding, because the regulatory clock starts when the organisation becomes aware that a breach may have occurred, not when it finishes investigating.

This is deliberately not a security incident response process. Detection, forensics, evidence preservation, eradication and getting systems verified clean sit in that process and are owned by the security team; here they appear as a single containment step and a remediation handoff back to Security. If the breach is a cyber attack, run both: the technical response restores and secures the estate, while this chart runs alongside it on its own deadline and answers a different question, which is who has to be told, by when, and what you write down if the answer is nobody. It is also not IT incident management, which is finished when service is restored, and not the subject access request process, which handles individuals asking for their own data rather than the organisation losing it.

Two decisions carry the legal weight and are routinely confused with each other. Notifying the supervisory authority is the default under UK and EU GDPR: it is required unless the breach is unlikely to result in a risk to people's rights and freedoms. Notifying the affected individuals is a separate and higher test, required only where the breach is likely to result in a high risk to them. A breach can easily be notifiable to the regulator without ever being communicated to the people involved. The third thing teams miss is that both branches converge: every breach goes in the internal register, including the ones you decide not to report, together with the reasoning behind that decision.

What this flowchart covers

In this template

• Five role lanes with an owner for every step (Detector / reporter, Security, Data protection officer, Legal, Communications) across five phase columns: report, assessment and containment, notification decision, notification, and record and review.
• The report phase: 'Possible data breach identified' and 'Report through the breach channel' in the reporter lane, then Security logs the report and starts the timeline, which fixes the awareness timestamp the 72-hour clock runs from.
• Initial assessment and containment in the Security lane, followed by a 'Personal data involved?' decision owned by the DPO, whose no branch closes the case as a security incident only rather than pulling it through the whole regulatory track.
• 'Assess severity and risk to individuals' in the DPO lane, then Legal confirming which notification duties actually apply, before the 'Notifiable to the supervisory authority?' decision.
• The notifiable branch runs 'Draft notification with legal review' and 'Notify supervisory authority within 72 hours'; the not-notifiable branch runs 'Document the reasons for not notifying' instead, so the decision is evidenced either way.
• A separate 'High risk to individuals?' decision sending Communications to draft and send a notice to affected individuals, then a breach register entry that both branches reach, remediation by Security, a post-breach review and closure.

When to use this template

• You are writing or refreshing a personal data breach procedure and need one page showing who assesses, who decides and who notifies.
• You want the notifiability decision settled in advance, so that at 5pm on a Friday nobody is arguing about whether the clock has started.
• You are running a breach exercise and want to test the 72-hour path end to end, including the drafting and sign-off steps that consume most of it.
• You are training staff on what to report and where, since the first step in almost every real breach is an ordinary employee noticing something.
• You have been asked by an auditor or a customer to show a documented breach procedure (the diagram evidences the procedure, it does not by itself demonstrate compliance).

How it works

1. Name the roles and the reporting channel

   Replace the five lanes with the roles you really have. Smaller organisations often have no DPO and merge that lane into Legal or a privacy lead; some add an external breach counsel or a cyber insurer lane. Then put the actual reporting route into the 'Report through the breach channel' step: one inbox, one form, one phone number, and a rule that people report on suspicion instead of investigating first.

2. Fix your regulators and your deadlines

   Edit the 'Confirm applicable notification duties' step to name the authority or authorities that apply to you, your lead authority if you operate across borders, and any sector or non-EU regimes you fall under. Those regimes run different clocks, so write each one down rather than assuming 72 hours covers everything. Add contractual customer notice periods too, which are frequently shorter than the statutory ones.

3. Write down your risk criteria

   Attach your own criteria to 'Assess severity and risk to individuals': type and sensitivity of the data, number of individuals and records, how easily people can be identified, whether the data was encrypted or otherwise unusable, whether any of the individuals are vulnerable, and the severity and likelihood of the harm. Criteria written in advance are what make the two decisions defensible afterwards.

4. Assign the two decisions and the sign-off

   State on the chart who owns 'Notifiable to the supervisory authority?' and 'High risk to individuals?', who is authorised to approve the submission to the regulator, and who can approve the wording sent to individuals. Add a deputy for each, because breaches do not wait for annual leave.

5. Set internal deadlines inside the 72 hours

   Work backwards from the deadline and put target times on the intermediate steps: when the DPO must have the assessment, when the draft has to reach Legal, when sign-off closes. The statutory deadline is the outer limit, not the plan, and the drafting and approval steps are where the hours actually go.

6. Point the register step at your real register, then version the chart

   Link 'Record the breach in the register' to the log you actually keep and list the fields it must capture: the facts of the breach, its effects, the remedial action taken, and the reasoning for each notification decision including the negative ones. Then circulate the chart to the DPO, Legal, Security and Communications for approval and keep the approved version, so the procedure you exercise is the one you publish.

Frequently asked questions

When does the 72-hour breach notification clock start?

Under UK and EU GDPR a controller must notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware that a personal data breach has occurred. Awareness means having a reasonable degree of certainty that a security incident has led to personal data being compromised, so a short period of initial verification is accepted, but you cannot delay the clock by extending an investigation. The 72 hours are calendar hours, not working hours: weekends and public holidays are inside the window. That is why this chart puts 'Log report and start the timeline' at the front and records who reported what, and when.

What is the difference between notifying the regulator and notifying the individuals?

They are separate tests with different thresholds, which is why the chart draws them as two decisions rather than one. The supervisory authority must be notified unless the breach is unlikely to result in a risk to the rights and freedoms of individuals, so notification is effectively the default. The affected individuals must be told only where the breach is likely to result in a high risk to them, and there are recognised exceptions, for example where the data was encrypted and remains unintelligible, or where you have since taken measures that mean the high risk is no longer likely to materialise. A breach can therefore be reported to the regulator and never communicated to the people involved.

Do we still have to record a breach we decided not to report?

Yes. The GDPR requires controllers to document every personal data breach, including the facts, its effects and the remedial action taken, regardless of whether it was notified. In practice the record of a breach you chose not to report is the more important one, because it is the only evidence that the decision was reasoned rather than convenient. That is why the 'Not notifiable' branch in this chart runs through 'Document the reasons for not notifying' and both branches converge on the register.

How is this different from a security incident response process?

A security incident response process is about the attacker and the estate: detect, triage, preserve evidence, contain, eradicate, verify systems are clean, restore service. This process is about the people whose data was affected and the obligations that follow, and it is triggered by any personal data breach, including ones with no attacker at all such as a misdirected email or an unrecoverable backup. The two overlap at containment and at the notification branch, and for a cyber incident you would run them in parallel with the security team owning the technical track and the DPO owning this one.

What if we are a processor rather than a controller?

A processor does not notify the supervisory authority or the individuals. It must notify the controller without undue delay after becoming aware of a personal data breach, and the controller then runs the assessment and both notification decisions. If that is your position, cut the chart down at the 'Notifiable to the supervisory authority?' decision, replace it with your notification to the controller, and check your contracts, because processing agreements commonly set a fixed internal deadline that is considerably shorter than the controller's 72 hours.