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. Awareness requires a reasonable degree of certainty, but an organisation should not postpone that point through avoidable investigation. Record the awareness time, evidence available and who made the assessment [1][2][3].

Does every personal data breach have to be reported to the ICO?

No. Notification to the ICO is required unless the breach is unlikely to result in a risk to people's rights and freedoms. The organisation must still document the facts, effects and remedial action, including why it concluded notification was unnecessary. “Small incident” is not the test; likely consequences and the people affected are [1][2][3].

Can we report before we know everything?

Yes. UK GDPR allows information to be provided in phases without undue further delay where it cannot all be supplied at once. Submit the information available, explain what remains unknown and set an update route. Waiting for a perfect root-cause report can create a late notification when an initial risk assessment already supported reporting [2][3].

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 statutory exceptions. The message should use clear language, describe the nature of the breach, give a contact point, explain likely consequences and state measures taken or proposed [1][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, time and follow-up. The file should show why risk was unlikely, not only that the incident was closed. Retain evidence supporting the conclusion and review it if scope, misuse or affected-person information later changes [1][2][3].

Does a processor report a breach directly to the ICO?

A processor must notify its controller without undue delay after becoming aware of a personal data breach. The controller normally carries the Article 33 supervisory-authority decision, while contracts may require the processor to provide defined evidence and assistance quickly. The parties should not let uncertainty over ownership consume the controller's 72-hour window [1][2].

Is sending an email to the wrong person always reportable?

It is a personal data breach where personal data is disclosed without authority, but reportability depends on risk. Consider the data, recipient, ability to retrieve or delete it, evidence of access, number and vulnerability of people, possible misuse and consequences. Record the reasoning even when prompt containment makes risk unlikely [1][3].

Is This a Reportable Data Breach in the UK? Decide Fast

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 reportable data breach UK question starts now, alongside containment; it does not wait for Friday's root-cause report ¹^,2.

Quick Answer. A reportable data breach in the UK is not unlikely to risk people's rights and freedoms. Record awareness time, contain the event, assess likely consequences and notify the ICO without undue delay and, where feasible, within 72 hours. Tell affected people separately if high risk is likely, and document every decision ¹^,2^,3.

For processing governed by the EU GDPR, use the EU personal-data-breach definition before applying the EU GDPR reportability decision.

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 organisation 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 breached
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 company caused it. A breach can result from error, loss, malicious action, system failure or a processor. The questions are whether personal data's confidentiality, integrity or availability was compromised and what that could do to people ¹^,3.

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 acknowledges it, preserves the original wording and makes the legal classification; the discoverer is not asked to decide whether it is reportable before escalation.

Where a processor discovered the event, its duty is to notify the controller without undue delay ¹^,2. Contract wording can define the 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 Article 33 window.

Fix the awareness time before debating the deadline

UK GDPR requires controller 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 ². The clock is therefore a duration from an evidence point, not three business days and not a deadline reconstructed later.

Awareness occurs when the controller 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 ². 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 company

The ICO threshold is framed around risk to natural persons' rights and freedoms ¹^,2^,3. Commercial loss, reputation and contract consequences may require response, but they do not decide Article 33. The assessment examines plausible 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 when combined 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 is 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 reveals assumptions for review.

Decide ICO notification on the unlikely-risk exception

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

The record should therefore reach one of three operational outcomes:

Risk is unlikely: do not notify the ICO 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 ICO and individual-notification risk thresholds.

At awareness, the time is recorded while containment and investigation begin in parallel ¹^,2^,3. The ICO 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 should contain the required categories of information: nature of the breach, categories and approximate numbers of people and records where possible, data protection contact, likely consequences and measures taken or proposed ². Where information is unavailable, provide what is known in phases without undue further delay.

A partial notification is not a defective final report. It is the statutory mechanism for an evolving incident. State which fields are provisional, what investigation is underway and when the next update will arrive. This preserves both speed and accuracy.

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 ICO 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 ²:

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.

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 ¹. This is a different, higher threshold from ICO notification. A file can therefore be reportable to the ICO without requiring direct communication to every person.

The message should 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.

Statutory 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 ¹. 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-report decision still require a record ¹^,3.

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. ICO 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.

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

UK GDPR requires controllers to document personal data breaches, including facts, effects and remedial action, so the ICO 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 an ICO report

Submitting a report 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 ICO 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 report 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 ¹^,3^,4.

At closure, capture what the ICO 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. The check repeats the original failure path safely and records whether the preventive control now stops it. If it does not, the incident remains an open improvement action even when notification correspondence has ended.

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.