Personal data breach response under GDPR: the 72-hour decision screen
A practical GDPR guide to classifying personal data breaches, applying the risk thresholds, meeting the 72-hour authority deadline, and recording the decision.
A security alert arrives at 09:10. An employee sent a customer file to the wrong recipient, a processor reports an intrusion, or a ransomware event has made records unavailable. The first meeting usually produces one question: "Do we have 72 hours?"
The better question has three parts: Did personal data suffer a breach? What risk does the breach create for people? Who must receive information, and by when? The answers determine whether the organisation records the event, notifies a supervisory authority, communicates with affected people, or does all three.
The incident becomes a GDPR breach
Article 4(12) defines a personal data breach as a security breach that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. The definition covers data that an organisation transmits, stores, or processes in another way. 1
The definition creates a boundary between a general security incident and a GDPR breach. Every personal data breach is a security incident. A security incident becomes a personal data breach when personal data has been destroyed, lost, altered, disclosed without authorisation, or accessed without authorisation. 2
The EDPB groups the possible effects into three information-security dimensions:
| Dimension | What happened | Workplace signal |
|---|---|---|
| Confidentiality | An unauthorised person accessed or received personal data. | A support export went to the wrong customer, or an attacker opened a customer database. 3 |
| Integrity | Someone altered personal data without authorisation. | A malicious actor changed account details, eligibility data, or a case record. 3 |
| Availability | People lost access to personal data, or the data was destroyed. | A ransomware event encrypted the only usable copy, or a security incident stopped access to critical records. 3 |
One event can affect all three dimensions. A network intrusion can expose records and make systems unavailable. An accidental deletion can create an availability breach even when nobody viewed the records.
A temporary loss of availability can also qualify. The EDPB treats personal data as unavailable when a security incident removes access for a period that may significantly affect people. Planned maintenance is different because the planned work does not breach security. 3
Two thresholds create three outcomes
The GDPR uses two risk thresholds. Article 33 sets the threshold for notifying the supervisory authority. Article 34 sets the higher threshold for communicating with affected people. The organisation must assess the actual incident against the likely impact on people’s rights and freedoms. 1
| Risk finding | Supervisory authority | Affected people | Practical result |
|---|---|---|---|
| The breach is unlikely to create a risk to people’s rights and freedoms. | No Article 33 notification is required. 1 | Article 34 communication is not triggered by this finding. | Record the breach, the facts, the effects, the remedial action, and the reason for the conclusion. 1 |
| The breach is likely to create a risk, but the assessment does not reach high risk. | Notify without undue delay and, where feasible, within 72 hours after awareness. | The Article 34 threshold has not been met. | Notify the authority, continue containment and investigation, and keep the reasoning that separates risk from high risk. |
| The breach is likely to create a high risk. | Notify under Article 33. | Communicate with affected people without undue delay. | Run authority notification and individual communication as parallel workstreams. |
The 72-hour rule belongs to the middle and high-risk branches. The rule sets a time limit for a required authority notification; it does not decide whether the event is a personal data breach or whether the risk is high.
Article 34(3) gives three limited routes that can remove the need for individual communication. Appropriate measures may have made the data unintelligible to unauthorised people, later measures may have removed the likelihood of high risk, or direct contact may require disproportionate effort. The last route requires an equally effective public communication or similar measure. The controller should keep evidence for whichever condition it relies on. 1
When the clock starts
The EDPB says a controller becomes aware when it has a reasonable degree of certainty that a security incident has compromised personal data. A short initial investigation can establish whether that condition exists. The initial investigation should start as soon as possible and should lead to a prompt decision about breach status. 3
A long investigation does not create a safe waiting period. Once the organisation has reasonable certainty that a breach occurred, the organisation must notify a reportable breach without undue delay and, where feasible, within 72 hours. The EDPB expects the controller to assess risk during that period, while containment, recovery, evidence collection, and notification proceed together. 3
The clock therefore starts from the organisation’s evidence of compromise, rather than from the moment an incident ticket receives a privacy label. A lost unencrypted USB drive gives the controller reasonable certainty of an availability breach when the loss is discovered, even if the controller cannot establish whether someone opened the files. A suspected network intrusion becomes a notification event after a short investigation confirms that personal data was compromised. 3
Processors have an earlier handoff duty. A processor must notify the controller without undue delay after becoming aware of a breach. The processor does not first decide whether the breach creates risk for individuals. The controller makes that assessment because the controller holds the wider context about the processing, the people affected, and the likely consequences. 3
A contract should turn that legal handoff into an early-alert procedure. The procedure should identify the emergency channel, the minimum first report, the responsible contacts, and the process for sending further facts. The contract can assign operational tasks or authorise a processor to submit a notification on the controller’s behalf. The controller keeps the legal responsibility for the decision and the notification. 3
The incident-response decision screen
A response owner can use the following sequence while the technical investigation continues.
- Contain the incident and preserve the facts. Assign a responsible person, protect the affected systems and records, and keep the evidence that shows what happened. The EDPB expects controllers to contain, manage, and recover the incident while they assess risk and decide on notifications. 3
- Confirm that personal data is involved. Identify the records, processing activity, data subjects, and processor or subprocessor connected to the event. A security event involving no personal data follows a different response path. A security event involving personal data moves into the Article 4(12) analysis.
- Classify what happened to the data. Record whether the event affected confidentiality, integrity, availability, or several dimensions. Record the affected systems and the time period. Classification gives the risk assessment a concrete object.
- Assess likelihood and severity. Ask what could happen to the affected people, how serious the consequences could be, and how likely those consequences are. Use the data type, the people involved, the ease of identification, the recipient or attacker, the duration, the number of people, and the controller’s context.
- Choose the notification branch. An unlikely risk supports a documented decision not to notify the authority. A likely risk requires authority notification. A likely high risk requires authority notification and communication with affected people. The record should state the evidence that placed the event on that branch.
- Send an initial notification when full scope is still developing. Article 33 allows information to be provided in phases when the controller cannot provide everything at once. The first notification can use approximate numbers and identify the missing information, the reason it is missing, and the plan for supplying it. 1
- Communicate with people when the high-risk threshold is met. Use clear language. Explain the nature of the breach, the likely consequences, the contact point, and the measures taken or proposed. Give practical advice that can reduce harm, such as resetting a compromised password or watching for phishing. 3
- Reassess and close the record. New forensic facts, a recovered device, a compromised encryption key, or a newly identified affected group can change the risk. Update the authority and affected people when the later facts require it. Keep the original decision, the new evidence, and the remedial action together.
The sequence prevents two common errors. A team can contain aggressively without losing the deadline. A privacy team can notify promptly without pretending that the first estimate is the final forensic account.
The risk questions that change the outcome
The EDPB recommends an objective assessment of both likelihood and severity. The following questions keep the assessment tied to the actual incident. 3
- What type of breach occurred? An unauthorised disclosure can expose information immediately. An integrity breach can cause an incorrect decision or a wrong payment. An availability breach can interrupt medical care, access to benefits, or another service that depends on the records.
- What data was involved? Consider the nature, sensitivity, combination, and volume of the data. A name and address may carry limited risk in one context. The same details can create severe danger when they reveal a protected family relationship. Health, identity, and financial data can create greater harm, especially when combined. 3
- How easily can someone identify the people? Ask whether the records identify people directly or can be matched with information already available to the recipient or attacker. Pseudonymisation can reduce the likelihood of identification. Pseudonymised data remains a risk-bearing dataset when the identity link or matching information remains available. 3
- Who received or can reach the data? A malicious attacker, an unknown recipient, and a trusted professional create different likelihoods of harm. A trusted recipient who confirms secure deletion may reduce the likely consequences. The accidental disclosure still belongs in the breach record. 3
- How severe and how permanent could the consequences be? Consider identity theft, fraud, financial loss, discrimination, physical harm, psychological distress, loss of confidentiality, and reputational damage. Consider how long the effect could last and whether people can take steps to reduce it.
- Who is exposed? Children and other vulnerable people can face greater harm from the same disclosure. The controller’s context also matters. A medical organisation may create more serious consequences from a breach than a newspaper mailing list. 3
- How many people and records are affected? A large population can increase the total impact. A single person can face severe harm when the data and context are highly sensitive. The number is one factor, not the decision by itself.
Two comparisons show why the details matter. A lost mobile device may create a low likelihood of confidentiality harm when strong encryption remains effective, the key stays protected, and another copy exists. A later key compromise or a prolonged loss of access changes that assessment. The EDPB also treats temporary loss of critical hospital data as a potential risk because unavailable records can affect treatment. 3
Encryption therefore supports a risk conclusion; encryption alone does not end the analysis. The controller must consider the quality and implementation of the encryption, the state of the key, available backups, restoration time, and the effects of unavailability. Pseudonymisation alone cannot make personal data unintelligible to an unauthorised person. 13
What to send and what to keep
An authority notification needs enough information for the supervisory authority to understand the event and the response. Article 33(3) sets the minimum fields. 1
| Field | Record for the authority |
|---|---|
| Nature | The breach type, affected systems, processing activity, and known attack or error path. |
| People and records | The categories and approximate numbers of affected people and personal-data records, where possible. |
| Contact point | The DPO’s name and contact details, or another contact point that can provide more information. |
| Consequences | The likely effects on the people involved. |
| Measures | Containment, recovery, remedial actions, and measures proposed to reduce adverse effects. |
An initial notification can contain approximate figures. A controller can add missing details in phases without undue further delay. The EDPB describes phased notification as a way to act promptly while a complex incident receives deeper forensic investigation. 3
An individual communication uses clear and plain language. The message should explain the breach, the likely consequences, the contact point, and the measures taken or proposed. Advice should match the harm: password resets for compromised credentials, fraud monitoring where financial misuse is plausible, or another concrete protective step. Direct communication is the normal route. When direct contact would require disproportionate effort, an equally effective public communication or similar measure is required. 13
The controller must document every personal data breach, whether or not Article 33 notification was required. The record must cover the facts, effects, and remedial action. The EDPB also recommends documenting the reasoning for non-notification, the reasons for any delay, and the evidence supporting an Article 34(3) decision. 13
A reviewer should be able to find these fields in one record:
- Incident: discovery channel, timeline, systems, causes, and the facts supporting breach status.
- Data and people: processing activity, data categories, affected groups, approximate counts, and processor involvement.
- Classification: confidentiality, integrity, availability, or a combination.
- Risk: likelihood, severity, identification ease, recipient or attacker, vulnerability, duration, and number affected.
- Decision: the chosen threshold, the evidence supporting it, and the owner who approved it.
- Notification: authority, time sent, reason for any delay, phased updates, and contact details.
- Communication: people contacted, message, channel, protective advice, and any Article 34(3) condition relied on.
- Remediation: containment, recovery, root-cause work, safeguards, re-evaluation triggers, and later updates.
The ICO’s operational guide expresses the same control in practical terms: organisations need breach detection, internal reporting, risk assessment, notification procedures, and a record of every breach, including events that do not require external notification. The ICO guidance is UK GDPR guidance; practitioners applying the EU GDPR should use the applicable EU supervisory authority and local law. 4
Shortcuts that fail
| Shortcut | Unresolved question | Repair |
|---|---|---|
| Treat "72 hours" as the whole test | Has a GDPR personal data breach occurred, and is the risk likely or high? | Classify the event, assess risk, then apply the timing rule. |
| Wait for exact numbers and a finished forensic report | Can the organisation notify while the scope is still developing? | Use approximate figures and phased information, then update without undue further delay. 3 |
| Treat encryption as an automatic exemption | Is the data unintelligible, is the key safe, and can people still access needed records? | Test the implementation, key security, backups, restoration time, and later changes in risk. |
| Let the processor decide that the event is low risk | Has the controller received an early alert and assessed the wider context? | Require prompt processor escalation; keep the risk and notification decision with the controller. 3 |
| Record only incidents reported to the authority | Could a reviewer reconstruct the organisation’s decision for a non-notified breach? | Record every breach, its effects, remedial action, and the reasoning for the outcome. 1 |
A defensible response has a short chain: classify the security event, identify the personal data, assess likelihood and severity, choose the applicable threshold, notify on time, communicate when high risk requires it, and preserve the reasoning. The final file should show what the organisation knew, when it knew it, what it did to reduce harm, and why each recipient was or was not contacted.
The practical test is one a reviewer can apply without reopening the whole investigation: can the record explain the breach, the affected people and data, the risk assessment, the notification timing, the protective measures, and the reason for every omitted notification? If the file answers those questions, the 72-hour rule has become part of a working control rather than a countdown repeated after the incident.
References
- 1Regulation (EU) 2016/679 (GDPR), Articles 4(12) and 32–34
eur-lex.europa.eu
- 2
- 3EDPB Guidelines 9/2022, version 2.0
edpb.europa.eu
- 4Personal data breaches: a guide | ICO
ico.org.uk
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.