When does the 72-hour breach clock start?

The clock starts when the controller becomes aware that a personal data breach has occurred, not when every cause, person or affected record is known. The EDPB describes awareness as having a reasonable degree of certainty that an incident compromised personal data. Record the time, supporting facts and decision-maker [1][2].

Does every personal data breach have to be reported?

No. Notification to the competent supervisory authority is required unless the breach is unlikely to result in a risk to people's rights and freedoms. The controller must still document the facts, effects and remedial action, including why notification was unnecessary. Incident size alone is not the test; likely consequences for people are [1][2][3].

Can we report before we know everything?

Yes. Article 33 allows information to be provided in phases without undue further delay where it cannot all be supplied at once. Provide the information available, identify what remains unknown and agree an update route with the authority. Waiting for a complete forensic report can make a notification late [1][2].

When must affected people be told about a breach?

People must be informed without undue delay when the breach is likely to result in a high risk to their rights and freedoms, subject to the Article 34 exceptions. The message must use clear language, describe the breach, give a contact point, explain likely consequences and state measures taken or proposed [1][2][3].

What should we record if a breach is not reported?

Record what happened, the data and people involved, containment, likely consequences, risk factors, safeguards, decision, decision-maker, timing and follow-up. The file should show why risk was unlikely, not merely that the incident was closed. Review the conclusion if scope, misuse or information about affected people later changes [1][2].

Does a processor report a breach directly to an authority?

A processor must notify its controller without undue delay after becoming aware of a personal data breach. The controller normally makes the Article 33 notification decision, while the contract should require fast evidence and assistance from the processor. The parties should not let uncertainty over roles consume the controller's 72-hour window [1][2].

Which supervisory authority receives a cross-border report?

For cross-border processing by a controller established in the EEA, the lead supervisory authority is normally the notification point. A controller with no EEA establishment cannot use the one-stop-shop merely through its representative and may need to notify every authority whose Member State has affected people. Map the route before an incident [2].

Is This a Reportable Data Breach Under EU GDPR? A Decision Guide

At 10:20 on Monday, a supplier says a shared link exposed customer documents outside the intended group. The security team can disable the link but cannot yet name every viewer. The question “is this a reportable data breach?” starts now, alongside containment; it does not wait for Friday's root-cause report ¹^,2.

Quick Answer. To decide if this is a reportable data breach, record awareness, contain the event and assess likely harm. Notify the competent supervisory authority without undue delay and, where feasible, within 72 hours unless risk is unlikely. Tell affected people separately if high risk is likely, and document every conclusion ¹^,2^,3.

Start two workstreams at awareness

The incident response should split immediately. One workstream contains and investigates: disable the link, preserve logs, reset credentials, recover a device or stop an incorrect mailing. The other establishes the legal decision: what happened, when the controller became aware, who is affected, possible consequences and whether notification thresholds are met.

Containment cannot wait for classification, and classification cannot wait for perfect forensics. Assign an incident owner, technical lead, risk decision-maker, communications lead and record keeper. In a small business one person may hold several roles, but each responsibility still needs a name and time.

First-hour field	Minimum useful entry
Detection	Who noticed what, through which system and when
Awareness	Earliest point of reasonable certainty that personal data was compromised
Containment	Action taken, owner, result and remaining exposure
Data	Categories, sensitivity, volume and protection applied
People	Number, vulnerability, relationship and location if known
Recipient or threat	Known recipient, likely access and evidence of misuse
Next decision	Time, owner and evidence needed

Do not begin by asking whether the event is embarrassing or whether the organisation caused it. A breach can result from error, loss, malicious action, system failure or a processor. The questions are whether the confidentiality, integrity or availability of personal data was compromised and what that could do to people ¹^,2.

The discoverer needs a route that works without authority to decide. A warehouse supervisor, support agent or supplier should be able to report one factual packet through a known urgent channel: what they saw, affected system or material, time, containment already attempted and a reachable contact. The incident owner preserves the original wording and makes the legal classification; the discoverer is not asked to decide reportability before escalating.

Where a processor discovered the event, Article 33 requires it to notify the controller without undue delay ¹^,2. Contract wording can define evidence and contacts, but it should never make a completed forensic report a precondition to the first alert. Controller and processor can investigate together while the controller protects its own notification window.

Fix the awareness time before debating the deadline

Article 33 requires notification without undue delay and, where feasible, no later than 72 hours after awareness, unless the breach is unlikely to result in a risk to rights and freedoms ¹^,2. The clock is therefore a duration from an evidence point, not three business days and not a deadline reconstructed later.

The EDPB considers a controller aware when it has a reasonable degree of certainty that a security incident has led to personal data being compromised ². A vague alert may justify investigation without establishing awareness. A confirmed public link containing customer files usually supplies stronger certainty even if the full download history is unknown.

Record the timestamp and facts supporting it. If a processor alerts the controller, capture the message and what it established. If uncertainty remains, set a short investigation checkpoint. A team should not define awareness as “when legal signed off” or “when the final affected-person count arrived”; internal routing cannot move the statutory trigger.

Late reporting can still be required. Article 33 expects reasons for delay where notification is not made within 72 hours ¹^,2. The honest record explains the cause and what happened meanwhile rather than backdating awareness or waiting until the investigation looks complete.

Assess risk to people, not impact on the organisation

The Article 33 threshold concerns risk to natural persons' rights and freedoms ¹^,2^,3. Commercial loss, reputation and contract consequences may require response, but they do not decide notification. The assessment examines plausible physical, material or non-material harm to affected people and how likely it is in the circumstances.

Relevant consequences include identity fraud, financial loss, discrimination, loss of confidentiality, social or professional harm, physical risk, distress and loss of control. The same email address can create different risk when it appears in an ordinary supplier list, a debt file, a protected-service record or a list that reveals a sensitive association.

Risk factor	Questions for the record
Data nature	Does it reveal finances, health, children, credentials, allegations or private communications?
Identifiability	Can the data identify a person alone or with accessible information?
Volume and duration	How many records, people and exposure hours are involved?
Recipient	Is the recipient known, trusted, hostile, public or unknown?
Protection	Was strong encryption effective and were keys separate?
Vulnerability	Could age, employment, health or another circumstance amplify impact?
Containment evidence	Was access prevented, or was deletion merely requested?
Misuse	Is there evidence of access, copying, disclosure, fraud or threats?

Scorecards can support consistency, but a total score should not hide a severe factor. One exposed safeguarding address may matter more than hundreds of generic business contacts. Write the causal sentence: “Because X data reached Y recipient under Z safeguards, the plausible consequence is A, with likelihood B.” That sentence exposes assumptions for review.

Decide notification using the unlikely-risk exception

Article 33 is often misstated as “report if high risk”. The supervisory-authority threshold is lower: notification is required unless the breach is unlikely to result in a risk to rights and freedoms ¹^,2. High risk belongs to the separate communication-to-individuals decision.

The equivalent UK Article 33 decision uses materially the same threshold, 72-hour timing and high-risk distinction. For ordinary GDPR breach reporting, the jurisdictional change is the competent authority and cross-border route, not the risk test. That is why the EU article replaces the authority instructions without inventing a second decision rule.

The record should therefore reach one of three operational outcomes:

Risk is unlikely: do not notify now; preserve the documented reasoning and review triggers.
Risk exists or cannot responsibly be excluded: notify without undue delay, within the feasible 72-hour period.
Material facts remain uncertain: contain, investigate against a short checkpoint and avoid treating uncertainty as evidence of safety.

Record and contain the breach, then apply the authority and individual-notification risk thresholds.

At awareness, the time is recorded while containment and investigation begin in parallel ¹^,2. The competent supervisory authority is notified without undue delay and, where feasible, within 72 hours unless risk to people is unlikely; uncertainty is not treated as evidence of safety. A likely high risk opens the separate communication to affected people, and every reporting or non-reporting conclusion is recorded and reviewed ³.

The notification must contain the categories of information listed in Article 33: nature of the breach, categories and approximate numbers of people and records where possible, data protection contact, likely consequences and measures taken or proposed ¹^,2. Where information is unavailable, provide what is known in phases without undue further delay.

Choose the destination before an incident. For processing confined to one Member State, the competent supervisory authority under Article 55 is normally the route. For cross-border processing by a controller established in the EEA, the lead supervisory authority is the usual interlocutor. A controller without an EEA establishment may have to notify each authority for affected people in its Member State because an EU representative alone does not create one-stop-shop access ².

Build a staged report from one controlled chronology

The reporting team should work from the same live chronology as technical response, not create a second narrative in email. Each entry carries the time, source, fact or assumption, owner and supporting evidence. Changes remain visible. That makes a phased update an accurate snapshot rather than a replacement story.

Separate confirmed facts from ranges and hypotheses. “The link was public from 08:10 to 10:22” may be confirmed; “between 40 and 60 customer files were reachable” may be the current range; “automated scraping occurred” may be an unresolved hypothesis. Each belongs in the record with a route to confirmation. Precision about uncertainty is better than an unsupported exact number.

The first notification can map directly to Article 33's required content ¹^,2:

Notification field	Working evidence
Nature of breach	Event type, system, exposure route and current status
People and records	Categories and approximate numbers with method used
Contact	Named data protection contact and monitored route
Likely consequences	Risk analysis tied to data, recipient and affected people
Measures	Containment completed, mitigation underway and prevention planned

Before submission, one person checks the report against the incident record and another confirms that technical actions described as complete have actually succeeded. Neither review should restart the legal analysis or consume the remaining clock in pursuit of polished prose. Preserve the submitted version, receipt and exact time.

Updates then close known gaps rather than retelling everything. If the affected count rises, say why. If logs prove no download, explain which logs and their coverage. If a measure fails, correct the earlier position clearly. The chronology should make every update reconstructable months later, including why the organisation acted on the information then available.

The EDPB adopted common template version 1.0 on 8 June 2026 for public consultation. The consultation ran from 10 June to 5 August 2026 and is now closed, but practical implementation across DPAs is still to be decided ⁵^,6. The template is therefore not a universal live filing route. Until the competent authority implements it, use that authority's current reporting route. A form can organise Article 33 information; it does not change the threshold, awareness point, clock, phased-information allowance or separate high-risk test.

The template distinguishes a new notification from a follow-up, marks information as complete or incomplete, and provides for withdrawal ⁶. One controlled chronology supports every state: the first reliable snapshot feeds the new notification, unresolved items remain visibly incomplete, verified additions become follow-ups, and any withdrawal retains its reason and evidence. Moving between those states updates the authority-facing record; it does not restart the awareness time, the 72-hour calculation or the legal risk analysis.

Make the individual-notification decision separately

Affected people must be told without undue delay when the breach is likely to result in a high risk to their rights and freedoms ¹^,2^,3. This is a different, higher threshold from supervisory-authority notification. A breach can therefore be reportable to the authority without requiring direct communication to every person.

The message must use clear and plain language. It describes the nature of the breach, gives the data protection contact, explains likely consequences and states measures taken or proposed ¹. Practical protective steps belong here: reset a password, contact a bank through a trusted channel, watch for a named fraud pattern or use a dedicated support route.

Communication should not transfer the organisation's anxiety to the recipient. Avoid speculation presented as fact, unexplained legal language and promises the response team cannot keep. Distinguish confirmed scope from continuing investigation and say when another update is expected.

Article 34 exceptions require their own analysis. Effective protection that renders data unintelligible, later measures that remove the high risk, or disproportionate effort may affect direct communication, with public or similarly effective communication relevant in the last case ¹^,2. Do not convert an exception into a convenience test.

Work four ordinary cases through the thresholds

Wrong-recipient email. A worker sends one customer's ordinary invoice to another established customer, notices within minutes, obtains credible deletion confirmation and sees no evidence of use. It is a breach. The risk assessment may conclude risk is unlikely depending on the content, recipient and evidence, but the event and non-notification decision still require a record ¹^,2^,4.

Change the attachment to a debt schedule containing bank details and allegations about several vulnerable people, and make the recipient unknown. The plausible consequences and uncertainty rise. Containment requests matter, but a request is not proof. Authority notification may be required, and the high-risk communication decision needs separate attention.

Lost encrypted laptop. A current laptop is stolen, full-disk encryption is strong and active, credentials are revoked promptly, keys are controlled separately and logs show no suspicious access. The security incident and data breach analysis are recorded. Effective protection can reduce the likelihood of consequences, potentially supporting non-notification on the facts ²^,4.

Ransomware with restored backups. Availability was lost, so restoration does not mean no personal data breach occurred. Investigate whether data was also accessed or extracted, which services and people were affected, how long critical data was unavailable and what harm the outage could cause. A health or payroll outage can affect people without public disclosure ²^,4.

Public sharing link. Customer documents were reachable without authentication for two days. The organisation disables the link but lacks complete access logs. Public availability, data nature and missing evidence weigh heavily. “No complaint received” is not evidence that risk is unlikely; the decision uses exposure and plausible consequences.

Record non-reporting as carefully as reporting

Article 33 requires controllers to document personal data breaches, including facts, effects and remedial action, so the supervisory authority can verify compliance ¹^,2. The log includes reported and non-reported events. A spreadsheet cell saying “low risk” is not a decision record.

For a non-report decision, preserve the awareness point, data and people, circumstances, containment evidence, consequence analysis, likelihood, safeguards, conclusion, decision-maker and review trigger. Attach relevant logs, recipient confirmations or encryption evidence. Note which unknowns were resolved and which remain.

Review trigger	Required response
More people or records found	Recalculate scale and consequences
Sensitive fields discovered	Reassess harm and both notification thresholds
Recipient does not confirm deletion	Revisit likelihood and containment
Evidence of download or misuse	Escalate and consider notification without delay
Initial safeguard fails	Reopen the conclusion and preserve reasons for timing
Affected person reports harm	Add evidence and reassess high-risk communication

The log is therefore not a graveyard. A decision made at hour six can be correct on hour-six evidence and require a different action at hour twenty. Version the assessment rather than silently replacing it.

Know what happens after notifying the authority

Submitting a notification is not the end of incident response. Preserve the reference, information supplied, times, updates and supporting evidence. Continue containment, recovery, individual communication where required and measures that reduce recurrence.

The supervisory authority may seek more information about the incident, risk assessment, technical and organisational measures, previous events or response. The organisation should be able to produce a coherent chronology rather than recreate it across inboxes. Accuracy and candour matter more than a falsely finished narrative.

Keep the contact route staffed after submission. Questions can arrive while the incident team is still working, and an unmonitored mailbox creates avoidable delay. Assign a person who can coordinate legal, security, supplier and operational evidence without allowing several teams to send inconsistent answers.

The notification also creates commitments. If it says every exposed link was disabled, every affected account was reset or a review will finish on Tuesday, track those statements as response actions. An inaccurate promise can become more damaging than an honest provisional statement. Status belongs in the incident record until each commitment is evidenced or corrected.

Reporting does not itself prove poor security, and non-reporting does not prove good security. The defensible position is a proportionate decision supported by facts, followed by measures that address both immediate consequence and root cause. Keep the notification threshold, security assessment and accountability record distinct even though they share evidence ¹^,2^,3.

At closure, capture what the authority asked, what the organisation supplied, whether affected people were contacted, which safeguards changed and who verified them. Feed recurring causes into training and system design. A neat incident chronology that never changes the process is complete as paperwork and incomplete as response.

Schedule a later effectiveness check instead of closing on implementation. A new approval step may exist on paper while staff still export the wrong audience; a permission change may be bypassed by an administrator account; restored backups may conceal the same vulnerable configuration. Repeat the original failure path safely and record whether the preventive control now stops it.

Notification is not a substitute for fixing the system. Close the immediate route, then identify why the control allowed it: excessive permissions, ambiguous export, weak verification, missing deletion, rushed onboarding or a supplier configuration. Assign actions, owners and dates, and test whether they changed the actual workflow ²^,4.

The first practical move is to write the awareness timestamp at the top of a live incident record, assign one decision owner and schedule the next evidence checkpoint. Contain in parallel. Those three acts stop the two most dangerous drifts: treating the clock as negotiable and treating incomplete facts as permission to wait.

Last updated: 26 August 2026.