A personal data breach does not automatically have to be reported to the Information Commissioner's Office (ICO). Under the UK GDPR, the key question is whether the breach is likely to result in a risk to people's rights and freedoms. If that risk is likely, the organisation must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of the breach. If the breach is unlikely to create such a risk, notification is generally not required. Either way, the incident should still be investigated, assessed and documented.
Key Takeaways
Not every security incident is a reportable personal data breach.
A breach must generally be reported to the ICO if it is likely to result in a risk to individuals' rights and freedoms.
Where reporting is required, the ICO must be notified without undue delay and, where feasible, within 72 hours of the organisation becoming aware of the breach.
A higher threshold applies to notifying affected individuals: they generally need to be told where the breach is likely to result in a high risk to their rights and freedoms.
Organisations should document personal data breaches even where they decide that ICO notification is not required.
The first hours after discovering an incident should focus on containment, establishing the facts, assessing risk and preserving a clear decision record.
What counts as a personal data breach?
A personal data breach is a security breach involving personal data. It can arise from accidental or unlawful destruction, loss or alteration of personal data, or from unauthorised disclosure of or access to it.
It is therefore broader than a cyberattack.
Examples can include:
sending an email containing personal information to the wrong recipient;
losing a laptop, phone or storage device containing personal data;
an employee accessing records without authority;
accidentally publishing information that should have remained confidential;
a cyberattack that gives an attacker access to customer or employee information;
deleting personal data when it cannot readily be recovered; or
changing data in a way that affects its integrity or availability.
The existence of a breach and the obligation to report it are two separate questions. A business may have experienced a personal data breach but, following an appropriate risk assessment, conclude that it does not meet the threshold for reporting to the ICO.
When must a data breach be reported to the ICO?
A personal data breach should be reported to the ICO where it is likely to result in a risk to the rights and freedoms of individuals.
This requires a case-by-case assessment. The decision should focus primarily on the consequences for the people whose information has been affected, rather than simply on how embarrassing, inconvenient or commercially damaging the incident may be for the organisation.
The assessment should consider both:
how serious the potential consequences could be; and
how likely those consequences are to occur.
Possible consequences can include financial loss, identity fraud, discrimination, damage to reputation, loss of confidentiality, emotional distress or other material or non-material harm.
A breach involving relatively limited information may therefore still be reportable if the circumstances create a meaningful risk to a particular individual.
Does every data breach need to be reported?
No.
If, after assessing the incident, the organisation concludes that the personal data breach is unlikely to result in a risk to individuals' rights and freedoms, it generally does not need to notify the ICO under the UK GDPR breach-notification regime.
For example, risk may be considerably reduced where information was accidentally sent to a trusted recipient who immediately confirms that it has been deleted without being copied, shared or otherwise used.
That should not be treated as an automatic exemption. The organisation still needs to assess what information was involved, who received it, whether it may have been accessed and what harm could realistically result.
The important point is that the decision not to report should itself be reasoned and recorded.
How should we assess the risk?
There is no useful assessment based purely on the number of records involved. A breach affecting one person can sometimes be significantly more serious than one affecting hundreds.
Factors that may materially affect the risk include:
What type of personal data was involved?
The nature of the information often matters more than its volume.
Greater care may be required where a breach involves information such as:
health information;
financial information;
identification documents;
login credentials or security information;
information about children;
criminal offence information;
other special category personal data; or
information whose disclosure could expose an individual to physical, financial or reputational harm.
How many people were affected?
Scale is relevant, but it should not be considered in isolation.
A breach affecting a large database may increase the overall potential impact, while a breach affecting one particularly vulnerable individual could still present a serious risk.
Who received or accessed the information?
There can be a substantial difference between information mistakenly sent to a professional contact who immediately deletes it and information published online or accessed by an unknown malicious actor.
Consider whether the recipient can be identified, whether the information has been downloaded or copied and whether there is evidence that it has been misused.
Was the information protected?
Encryption or other effective security controls may substantially reduce the likelihood that compromised information can actually be accessed.
The organisation should establish what protections were in place rather than assuming that a lost or stolen device necessarily means the information stored on it has been exposed.
What could realistically happen to the affected individuals?
Move beyond describing the technical incident.
Ask whether the breach could realistically lead to fraud, impersonation, financial loss, discrimination, loss of confidentiality, distress, physical danger or another meaningful disadvantage.
That is much closer to the question the reporting regime is designed to address.
When does the 72-hour period start?
Where the breach is reportable, the organisation must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.
The 72-hour period does not necessarily begin when the incident itself first occurred. It is linked to when the organisation becomes aware of the personal data breach.
In practice, an organisation should not use uncertainty as a reason to leave an incident untouched while the clock runs.
As soon as a potential breach is identified, it should establish:
what happened;
when it happened;
when the organisation became aware of it;
what information was affected;
which individuals may be affected;
whether the breach is continuing; and
what immediate containment measures are available.
The ICO's current guidance emphasises reporting early and updating later where a full investigation cannot reasonably be completed within the initial reporting period.
What if we do not know everything within 72 hours?
An organisation does not need to complete an entire forensic investigation before making a required notification.
If a breach meets the reporting threshold but some information remains unavailable, the ICO allows organisations to provide further information in phases.
This matters commercially as well as legally. Waiting for perfect information can create a second problem: a late regulatory notification.
The sensible approach is to establish enough reliable information to assess the breach properly, report within the required timeframe where necessary and continue the investigation afterwards.
If notification is made after the relevant 72-hour period, the organisation may need to explain the reason for the delay.
What information does the ICO need?
A breach notification will normally need to explain the nature of the breach and provide sufficient information for the ICO to understand its likely consequences and the organisation's response.
Relevant information includes:
what happened;
when and how the organisation became aware of the breach;
the categories and approximate number of individuals affected, where possible;
the categories and approximate number of personal data records involved, where possible;
the likely consequences of the breach;
measures already taken or proposed to address the breach;
steps taken to mitigate possible adverse effects; and
an appropriate contact point for further information.
Accuracy matters. Where the facts are still developing, it is better to distinguish what is currently known from what remains under investigation than to present assumptions as confirmed facts.
Do we also need to tell the people affected?
Potentially, but a higher threshold applies.
Where the breach is likely to result in a high risk to the rights and freedoms of affected individuals, those people generally need to be informed directly and without undue delay.
The purpose is practical. Someone who knows that their password, financial details or sensitive information may have been compromised may be able to take immediate steps to protect themselves.
The communication should therefore be understandable and useful rather than merely defensive. Depending on the circumstances, it may need to explain what happened, the likely consequences, what the organisation is doing and what the individual can do to reduce the risk.
A breach can therefore fall into three broad categories:
unlikely to create a risk – generally no ICO notification and no notification to individuals;
likely to create a risk – notify the ICO, but notification to individuals may not necessarily be required; or
likely to create a high risk – notify the ICO and, subject to applicable exceptions, inform affected individuals without undue delay.
What should we do immediately after discovering a breach?
Regulatory reporting is only one part of the response.
The first operational priority should be to contain the incident and understand what has happened.
Depending on the circumstances, this may involve:
recalling or restricting access to information;
asking an unintended recipient to securely delete material;
disabling compromised accounts or credentials;
isolating affected systems;
preserving relevant logs and evidence;
contacting an IT or cybersecurity provider;
establishing which information and individuals are affected;
recording a timeline of events; and
commencing the risk assessment.
The business should also establish who has authority to make the reporting decision. A breach discovered late on Friday afternoon should not remain unassessed until Monday simply because the usual decision-maker is unavailable.
Effective breach management therefore depends on preparation before an incident occurs.
What if a supplier or technology provider suffers the breach?
The contractual and data-protection roles matter.
Where a service provider processes personal data on behalf of another organisation as a processor, the processor must notify the relevant controller without undue delay after becoming aware of a personal data breach.
The controller then needs to determine whether the breach must be reported to the ICO.
Businesses that rely on cloud platforms, payroll providers, outsourced IT services, CRM systems or other third parties should therefore check that their contracts and incident-response procedures support rapid escalation.
A contractual requirement for a supplier to notify the business only after completing its investigation could leave the controller with very little time to meet its own regulatory obligations.
Do we need to keep a record if we decide not to report?
Yes. Personal data breaches should be documented even where the organisation concludes that notification to the ICO is not required.
The record should explain enough to demonstrate how the organisation dealt with the incident. This can include:
the facts surrounding the breach;
its effects;
remedial action taken;
the risk assessment;
the reporting decision; and
why the organisation considered notification unnecessary, where applicable.
This is not administrative paperwork for its own sake.
If the decision is later questioned, the organisation should be able to show that it identified the incident, assessed the consequences and reached a reasoned decision based on the information available at the time.
Are there other reporting obligations?
Potentially.
Reporting a personal data breach to the ICO does not necessarily satisfy every obligation that may arise from the same incident.
Depending on the organisation and the nature of the breach, it may also need to consider notifications or communications involving:
another regulator;
an insurer;
the National Cyber Security Centre;
law enforcement or fraud-reporting bodies;
customers or contractual counterparties;
overseas data-protection authorities; or
other parties required under sector-specific rules or contractual arrangements.
Public electronic communications service providers can also be subject to specific breach-reporting requirements under the Privacy and Electronic Communications Regulations.
The Data (Use and Access) Act 2025 changed the relevant PECR breach-reporting timeframe so that the notification period is now aligned at 72 hours in the circumstances covered by those provisions.
Before You Proceed, Check…
Have we established whether personal data was actually involved?
When did we first become aware that a personal data breach had occurred?
Has the incident been contained?
What categories of personal data were affected?
How many individuals and records may be involved?
Was the information encrypted or otherwise protected?
Who received, accessed or may have accessed it?
Could the incident cause financial, physical, reputational or other harm?
Have we documented our risk assessment?
Does the breach meet the threshold for ICO notification?
Could the breach create a high risk requiring affected individuals to be informed?
Are any other regulators, insurers or contractual counterparties relevant?
Have we recorded the decision and the reasons supporting it?
Have we identified any corrective action needed to prevent recurrence?
Common Mistakes Businesses Make
Treating every incident as automatically reportable
Reporting should follow a proper risk assessment. The existence of a breach alone does not establish that the ICO notification threshold has been met.
Waiting until the investigation is complete
A complex investigation can take considerably longer than 72 hours. Where a breach is reportable, organisations should not wait for every fact to become known before dealing with the notification requirement.
Assessing risk to the company instead of the individual
Reputational damage to the business may matter commercially, but the UK GDPR reporting test focuses on risks to the rights and freedoms of the people affected.
Focusing only on the number of records
Ten thousand exposed names may present a different risk from one person's highly sensitive medical, financial or safety-related information. Volume matters, but context matters too.
Failing to document a decision not to report
A decision that notification was unnecessary should be capable of being explained later. A written breach record and risk assessment provide the evidence behind that decision.
Forgetting third-party incidents
A breach at a processor or technology supplier can still create reporting obligations for the controller. Supplier escalation procedures should therefore form part of the organisation's breach-response framework.
FAQs
Do we have exactly 72 hours to report every data breach?
No. Only breaches meeting the notification threshold must be reported under the UK GDPR regime. Where reporting is required, notification should be made without undue delay and, where feasible, within 72 hours of becoming aware of the breach. Organisations should not treat 72 hours as a target if an appropriate report can be made earlier.
Does sending an email to the wrong person have to be reported to the ICO?
Not automatically. The organisation should consider what information was disclosed, who received it, whether it was accessed or shared, whether it can be securely deleted and what consequences could result for the affected person. Some mistaken emails will be low risk; others may clearly require reporting.
Does a cyberattack always have to be reported?
No. A cyber incident and a reportable personal data breach are not necessarily the same thing. The organisation needs to establish whether personal data was affected and, if so, assess the likely risk to individuals. Separate cybersecurity, regulatory or contractual reporting obligations may also apply.
Do we have to notify customers if we report the breach to the ICO?
Not necessarily. The threshold for informing affected individuals is higher. Individuals generally need to be told where the personal data breach is likely to result in a high risk to their rights and freedoms.
What happens if we realise after 72 hours that the breach should have been reported?
Where a required notification is made late, the organisation should report without further unnecessary delay and explain the reasons for the delay. The circumstances behind both the breach and the delayed notification may be relevant to the ICO's response.
Should we report if we are unsure whether the threshold is met?
The organisation should carry out and document a prompt risk assessment rather than simply report every incident "just in case". The ICO provides a breach self-assessment tool and guidance that can help organisations assess whether notification is required.
Can a data processor report the breach directly instead of us?
A processor must notify its controller without undue delay when it becomes aware of a personal data breach. Responsibility for assessing whether a UK GDPR notification to the ICO is required generally sits with the controller, although practical reporting arrangements may depend on the circumstances and contractual structure.
When to Get Support
A breach can become difficult to manage when the facts are incomplete, sensitive information is involved, several parties or jurisdictions are affected, or the reporting threshold is unclear.
Sterling Legal Solutions can support businesses with the legal, compliance and commercial aspects of data-protection incidents, including assessing obligations, reviewing breach-response processes and coordinating practical next steps where appropriate.
Disclaimer
This article is provided for general information only and does not constitute legal, tax, financial, regulatory, investment or other professional advice. Specific advice should be obtained before relying on any particular course of action.
Sources
Information Commissioner's Office — Personal data breaches: a guide
Information Commissioner's Office — UK GDPR data breach reporting
Information Commissioner's Office — 72 hours: how to respond to a personal data breach
Information Commissioner's Office — Personal data breach self-assessment
Information Commissioner's Office — Personal data breach management: reporting processes
Information Commissioner's Office — Data (Use and Access) Act 2025: summary of changes
Data (Use and Access) Act 2025