Data breach response process flowchart (GDPR 72-hour clock)
A swimlane flowchart for personal data breach response: containment, the risk-to-individuals test, the 72-hour regulator notification and the breach register.
How it works
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.
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.
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.
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.
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.
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.