A personal-data breach is a security incident affecting confidentiality, integrity or availability of personal data.
A breach can be accidental or deliberate: sending data to the wrong person, losing a device, exposing a database, altering records improperly or making data unavailable can all potentially qualify. Not every breach must be reported to the ICO or to individuals; the risk thresholds determine notification duties.
Where a breach is likely to result in a risk to people’s rights and freedoms, the controller generally must notify the ICO without undue delay and, where feasible, within 72 hours after becoming aware. High-risk breaches can also require communication to affected individuals.
Key points
- 72 hours runs from awareness, not necessarily from when the incident first occurred.
- Controllers should document breaches even when they decide notification is not required.
- Processor-to-controller notification duties are separate.
- For consumers, practical protective steps can be as important as regulatory complaint.
Confidentiality, integrity and availability
A confidentiality breach is unauthorised disclosure/access. Integrity involves unauthorised alteration. Availability covers accidental or unlawful loss/destruction or inability to access data. One incident can involve all three.
Risk assessment
The controller should consider the sensitivity and volume of data, ease of identification, potential fraud/financial harm, vulnerability of affected people and consequences. A leaked password hash is different from an email address accidentally sent to one trusted recipient, though both still require assessment.
What the affected person should do
Change compromised credentials, contact banks or relevant providers, preserve breach notices and monitor credit/identity activity where appropriate. Ask the controller what data was affected, when, who received it, what containment occurred and what support is offered.
In practice
- Do not wait for an ICO outcome before taking practical security steps.
- Keep evidence of financial loss, distress or identity-protection costs.
- If the controller says no breach occurred, ask it to explain the security incident classification.
What to do
A practical next-step plan
- Secure affected accounts/devices.
- Ask the controller for the breach facts.
- Record the impact.
- Complain if handling or notification appears inadequate.
- Report to ICO where appropriate.
Common traps
Things that often confuse the issue
- Not every breach leads to compensation.
- A controller does not have to notify every low-risk breach to every person.
- A cyberattack is not automatically proof the controller breached the security principle; adequacy of measures matters.
Evidence worth keeping
Compensation is not automatic just because a breach occurred.
A regulatory breach, a report to the ICO and a civil compensation claim are different questions. A person may pursue compensation where the legal test for material or non-material damage is met, but the existence of an incident does not create an automatic tariff. Preserve evidence of financial loss, identity misuse, correspondence and any genuine distress or consequences.
Useful complaint framing.
Ask the organisation to explain the incident, the data affected, its risk assessment, mitigation and the steps it will take to prevent recurrence. If its answer is inadequate, use the statutory data-protection complaint process and consider the ICO route.
Ask for facts that help you protect yourself now.
- What categories of your personal data were affected.
- When the organisation became aware and, if known, how long exposure lasted.
- Who may have received or accessed the information.
- Whether passwords, financial details, identity documents or special-category data were involved.
- What containment and mitigation steps have been taken.
- Whether the ICO and affected people were notified, and if not, the risk conclusion.
Change credentials, contact your bank, use fraud-prevention services or take other protective steps where the actual data exposed makes those measures proportionate.
Not every breach must be reported to the ICO or every affected person.
The organisation must assess risk. Where a breach is likely to result in a risk to people’s rights and freedoms, it must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. If the breach is likely to create a high risk for affected people, direct notification to them is generally required without undue delay. Organisations must keep internal records of breaches even where external reporting is not required.
A company saying “we did not report it to the ICO” therefore does not by itself prove there was no personal data breach. Ask for the risk assessment and outcome relevant to you.
A personal data breach is broader than hacking.
It can involve accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Examples include sending information to the wrong person, losing an unencrypted device, exposing records online, altering data incorrectly or losing access to important personal data. The consumer question is not merely “was the company hacked?” but what happened to confidentiality, integrity or availability of your information.
Official sources
Check the rules behind this guide
- ICO: what is a personal data breach?
- ICO: what to do if you are affected by a breach
- ICO: 72 hours: responding to a breach ↗
ConsumerWise explains these materials in plain English. Check the current official source where a deadline, rule about what the body can deal with or legal requirement may have changed.