Not every privacy incident is a reportable data breach. But every reportable data breach usually begins as a privacy incident that someone notices, reports, investigates, and escalates.
That first response matters. The actions taken in the first few hours after discovery often determine whether the organisation contains the issue, meets its legal obligations, protects affected individuals, and satisfies the regulator that it acted responsibly. A confused or delayed response can turn a manageable incident into a regulatory, legal, and reputational problem.
Under UK General Data Protection Regulation, known as UK GDPR, organisations must assess whether a personal data breach is likely to result in a risk to people’s rights and freedoms. If it is, they must notify the Information Commissioner’s Office, known as the ICO, without undue delay and, where feasible, within 72 hours. If the breach is likely to result in a high risk to affected individuals, those individuals must also be told without undue delay.
This guide explains the privacy incident vs data breach distinction, the notification thresholds, and the practical response process from first discovery to regulatory closure.
What is the difference between a privacy incident and a personal data breach under GDPR?
The terms “privacy incident” and “data breach” are often used interchangeably, but they are not always the same thing. Understanding the difference helps teams respond proportionately.
Privacy incident: any event that may have compromised the confidentiality, integrity, or availability of personal data
A privacy incident is any event that may involve personal data being mishandled, exposed, lost, altered, accessed without authority, sent to the wrong person, retained incorrectly, or used outside approved purposes.
Examples include an email sent to the wrong recipient, a lost laptop, an employee accessing records without a business need, a ransomware attack, a system outage affecting personal data, a misconfigured cloud folder, or a supplier reporting suspicious access.
At the point of discovery, you may not yet know whether it meets the legal definition of a personal data breach. That is why you treat it as an incident first and investigate quickly.
Personal data breach: the legal definition under Article 4(12) UK GDPR
A personal data breach Article 4 definition is more specific. UK GDPR defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
This means a breach can involve confidentiality, integrity, or availability. It is not limited to cyberattacks or stolen databases. A paper file lost on a train, a payroll spreadsheet sent to the wrong employee, or a system error that corrupts customer records may all be personal data breaches.
The three breach types with examples: confidentiality breach, integrity breach, and availability breach
A confidentiality breach happens when personal data is disclosed to or accessed by someone who should not see it. For example, a customer list is emailed to the wrong external recipient.
An integrity breach happens when personal data is altered incorrectly or unlawfully. For example, a system fault changes patient records or account details.
An availability breach happens when personal data is lost, destroyed, or made unavailable. For example, ransomware prevents access to HR records needed to pay staff.
A single incident can involve more than one type. A ransomware attack may involve loss of availability and unauthorised access.
Why the distinction matters operationally — different situations require different responses
A privacy incident triggers investigation. A personal data breach triggers a legal assessment. A notifiable breach triggers reporting duties. A high-risk breach triggers communication to affected individuals.
The operational mistake is treating all incidents the same. Over-reporting can waste time and create confusion. Under-reporting can create regulatory risk. The response process should help teams move quickly from “something happened” to “what happened, who is affected, what is the risk, and what must we do?”
How do you assess whether a breach must be reported to the ICO?
The key question is not whether the incident is embarrassing or inconvenient. The key question is whether the personal data breach is likely to result in a risk to individuals’ rights and freedoms.
The notification threshold: “likely to result in a risk to the rights and freedoms of individuals”
The notifiable breach threshold GDPR sets a risk-based test. If the breach is unlikely to result in a risk to people, it does not need to be reported to the ICO. If risk is likely, it must be reported.
Risks can include identity theft, financial loss, discrimination, distress, reputational damage, loss of confidentiality, loss of control over personal data, physical harm, or other significant disadvantage.
The risk assessment: the factors that increase or reduce the severity of the breach
A breach risk assessment should consider the type of data, volume of data, number of individuals affected, sensitivity, whether the data is encrypted, who received or accessed it, whether it has been recovered, whether the recipients are trusted, and what harm could result.
For example, sending a newsletter to the wrong internal team may be low risk. Sending health data, bank details, or safeguarding information to an unknown external recipient is much more serious.
Special category data in a breach: why its presence escalates the notification analysis
Special category data includes more sensitive information such as health data, racial or ethnic origin, religious beliefs, trade union membership, biometric data used for identification, and similar categories.
The presence of special category data does not automatically mean every breach must be reported in every case, but it often increases the likelihood and severity of harm. It should therefore raise the urgency of the risk assessment and may make notification more likely.
The decision matrix: a practical framework for deciding whether to notify, monitor, or close
A practical decision matrix can classify incidents into three routes.
First, close and record: the breach is unlikely to result in risk, evidence supports that conclusion, and no notification is needed.
Second, monitor and mitigate: the risk is uncertain or low, containment is active, and further evidence is needed.
Third, notify: risk to individuals is likely, or high risk is likely, and reporting duties are triggered.
Whatever route is chosen, document the reasoning. ICO breach notification guidance expects organisations to keep records of breaches, including decisions not to report.
What does the 72-hour ICO notification requirement mean in practice?
The data breach notification ICO 72 hours requirement is one of the most time-sensitive obligations in UK GDPR.
When the 72-hour clock starts: the “becomes aware” threshold and its implications
The 72-hour clock starts when the organisation becomes aware of a personal data breach. This does not mean the moment the incident originally happened. It means when the organisation has a reasonable degree of certainty that a breach has occurred.
Teams should not wait until every detail is known before starting the response process. Investigation and notification planning should begin immediately.
What must be included in a notification to the ICO at the point of first reporting
A notification should include the nature of the breach, categories and approximate number of individuals affected, categories and approximate number of records affected, likely consequences, measures taken or proposed, and contact details for the Data Protection Officer or other contact point.
If some details are not yet known, explain what is known, what is still being investigated, and when updates will follow.
Notifying in phases: what to do when the full picture is not yet available within the 72-hour window
The GDPR breach response process allows practical phased reporting. If the full facts are not available within 72 hours, submit an initial report and provide further information as it becomes available.
This is usually better than delaying until the investigation is complete. The ICO expects openness and transparency where notification is required.
Late notifications: what to tell the ICO and what the consequences of lateness may be
If notification is late, explain why. The ICO will want to know when the organisation became aware, what actions were taken, why the delay occurred, and what has been done to prevent the same issue happening again.
Late reporting can itself become a compliance concern, especially if the delay suggests poor incident governance.
When must the organisation also notify the affected individuals?
Notifying the ICO and notifying individuals are separate duties with different thresholds.
The high-risk threshold for data subject notification under Article 34 UK GDPR
Affected individuals must be told when the personal data breach is likely to result in a high risk to their rights and freedoms. This is a higher threshold than reporting to the ICO.
A high risk breach data subjects scenario may include exposure of financial data, identity documents, passwords, health records, safeguarding information, or data that could lead to fraud, distress, discrimination, or physical harm.
What a notification to data subjects must contain — the mandatory content
A communication to affected individuals should be clear and plain. It should describe the nature of the breach, provide contact details, explain likely consequences, and explain the steps taken or proposed to address the breach.
It should also tell individuals what they can do to protect themselves, such as changing passwords, monitoring accounts, contacting banks, or watching for suspicious messages.
The three exemptions that remove the data subject notification obligation
There are situations where direct notification may not be required even if the breach initially appears high risk. For example, if appropriate technical measures such as strong encryption make the data unintelligible to unauthorised people, if later measures ensure the high risk is no longer likely to materialise, or if direct communication would involve disproportionate effort and a public communication is used instead.
These decisions should be documented carefully.
Channel, timing, and tone: practical guidance for communicating a breach to the individuals affected
Breach communication should be prompt, accurate, and calm. Avoid defensive language. Avoid hiding the issue in vague wording. Do not speculate beyond confirmed facts.
Use the channel most likely to reach affected individuals securely. Email may be suitable in many cases, but letters, phone calls, portal messages, or public notices may be needed depending on the context.
How should organisations build an effective privacy incident response process before an incident occurs?
A strong privacy incident management process must exist before the incident happens. It is too late to design it during the first 72 hours.
Detection and reporting: creating a culture in which staff report quickly and without fear of blame
Staff should know what to report, who to report it to, and how quickly. They should understand that early reporting is valued, even if the incident turns out not to be serious.
A blame culture delays reporting. A learning culture protects the organisation and the individuals affected.
Triage and initial containment: the immediate steps on first discovery
Initial response should focus on containment and fact gathering. Can access be removed? Can the email be recalled? Can a recipient delete the data? Can a system be isolated? Can passwords be reset? Can a vendor confirm what happened?
At the same time, the incident should be logged and escalated to privacy, security, legal, and relevant business owners.
Investigation and documentation: building the evidence the ICO will expect to review
Documentation should include what happened, when it was discovered, who discovered it, what personal data was involved, how many people were affected, what containment steps were taken, what risks were identified, whether the ICO was notified, whether individuals were told, and what lessons were learned.
A data breach response plan should include templates for incident logs, risk assessments, ICO notifications, data subject communications, and post-incident review.
Post-incident review: capturing the root cause, remediation steps, and lessons for the programme
Every incident should lead to improvement. Root causes might include weak access controls, poor training, rushed processes, vendor failure, misconfigured systems, or unclear ownership.
Post-incident actions may include policy updates, staff training, technical fixes, vendor review, stronger approval processes, or changes to retention and access controls.
FAQs
Does every data breach need to be reported to the ICO or only certain types?
Only certain breaches need to be reported. If a personal data breach is likely to result in a risk to individuals’ rights and freedoms, it must be reported to the ICO. If it is unlikely to result in risk, it does not need to be reported, but it should still be recorded internally.
What are the consequences of reporting a breach late or failing to report one at all?
Late or missed reporting can lead to regulatory scrutiny, criticism, enforcement action, reputational damage, and loss of trust. The ICO will consider not only the breach itself, but also how the organisation identified, assessed, documented, contained, and reported it.
How long should an organisation retain records of privacy incidents that were assessed but not reported to the ICO?
UK GDPR requires organisations to document personal data breaches, including facts, effects, and remedial action. There is no single universal retention period for every incident record. Organisations should set a documented retention period based on legal, regulatory, insurance, audit, and operational needs, and apply it consistently.
Conclusion
The difference between a well-handled breach and a poorly handled one is rarely the breach itself. It is the preparation that came before it.
Organisations with a documented incident response process, trained staff, clear escalation routes, risk assessment criteria, notification templates, and decision logs are much better placed to respond within 72 hours. They can contain the incident, protect individuals, satisfy regulators, and learn from what happened.
Organisations that improvise under pressure are more likely to miss deadlines, under-assess risk, communicate poorly, and lose control of the situation.
When a breach happens, you will not have time to build your response process from scratch. Our Privacy Incident Response And Breach Notification Basics course gives your team a framework that is ready when it matters most.
For related learning, explore Vendor Risk And Data Processing Agreements For Privacy, Handling Data Subject Access Requests DSAR End To End, and Cyber Incident Response & Data Breach Management.
