TRW & Co · Data protection
Data Breach Reporting: The 72-Hour Rule and Incident Response
UK data breach reporting rules require controllers to notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in risk to individuals. High-risk breaches must also be communicated to those affected, and every breach must be recorded internally, whether reported or not.
Key pointThe 72 hours start when you are reasonably certain personal data has been compromised, not when the investigation ends; report in phases rather than wait for a complete picture.
At a glance
72-hour deadline
Notify the regulator without undue delay and, where feasible, within 72 hours of becoming aware of a reportable breach; late reports must explain the delay.
High-risk breaches
Where a breach is likely to result in a high risk to individuals, they must be told without undue delay in clear and plain language.
Record every breach
All personal data breaches, including those not reported, must be documented with their facts, effects and remedial action taken.
Penalty exposure
Notification failures carry fines of up to £8.7 million or 2% of turnover; underlying security failures up to £17.5 million or 4%.
PECR aligned
The Data (Use and Access) Act 2025 aligned PECR breach notifications by telecoms and internet providers with the 72-hour UK GDPR timetable.
Swipe or scroll →
The short answer: data breach reporting under the UK GDPR
UK data breach reporting rules require a controller to notify the regulator of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. If the breach is likely to result in a high risk, the affected individuals must also be told without undue delay. Every breach, whether reported or not, must be recorded internally.
The 72 hours run from awareness, not from the end of the investigation. You can report in phases as facts emerge, and a late report must explain the delay. The regulator, the Information Commission (still known as the ICO), judges organisations as much on the quality of their decision-making and documentation as on the breach itself.
The legal framework for data breach reporting
The core duties are in Article 33 (notifying the regulator) and Article 34 (communicating with individuals) of the UK GDPR. A "personal data breach" is wider than a cyber attack: it covers any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. An email sent to the wrong person, a lost laptop and a ransomware attack that encrypts data are all breaches, as is data becoming unavailable.
Processors must notify the controller without undue delay after becoming aware of a breach. Telecoms and internet service providers have a separate duty under the Privacy and Electronic Communications Regulations, which the Data (Use and Access) Act 2025 aligned with the 72-hour UK GDPR timetable.
Failures to notify fall within the standard maximum penalty under section 157 of the Data Protection Act 2018: £8.7 million or 2% of worldwide turnover, whichever is higher. The security failure behind the breach may also be an infringement of the security principle, which carries the higher maximum of £17.5 million or 4%.
Assessing risk: report, tell individuals, or record only
The decision turns on the likely consequences for people, not the size of the incident or the embarrassment to the organisation. Consider the type and sensitivity of the data, the volume, how easily individuals can be identified, the severity and permanence of possible harm, any vulnerability of those affected, and whether the data was protected (for example, encrypted with keys not compromised).
| Risk to individuals | Notify the regulator? | Tell individuals? | Examples |
|---|---|---|---|
| Unlikely to result in risk | No, but record internally | No | Encrypted device lost with keys secure; misdirected email recalled unopened to a trusted recipient |
| Risk | Yes, within 72 hours where feasible | Not required, but consider | Customer contact details exposed; short-term loss of access to records |
| High risk | Yes, within 72 hours where feasible | Yes, without undue delay | Financial, health or identity data stolen; data published online after ransomware |
Individuals need not be told where the data was rendered unintelligible (for example by encryption), where later measures mean the high risk is no longer likely, or where individual contact would involve disproportionate effort, in which case a public communication is required instead.
Common breach types and how they are usually assessed
Misdirected communications. Emails or letters sent to the wrong recipient are the most frequent breach type. The risk depends on the content and the recipient: a routine update sent to another business contact who confirms deletion is usually low risk, while medical or financial details sent to an unknown recipient may be high risk.
Lost or stolen devices. Where a device is fully encrypted and the keys are not compromised, the incident may not need reporting. Unencrypted laptops, phones or paper files are a different matter, and the absence of encryption will itself attract questions about security.
Cyber attacks and credential compromise. Phishing, compromised passwords and exploited software vulnerabilities often give attackers access to email accounts or systems for weeks before detection. The forensic question is what the attacker could see and what they actually took. Where logs are incomplete, you may have to assume the worst case for the data that was accessible, which can widen the group of individuals who need to be told.
Unauthorised access by staff. Employees browsing records out of curiosity, or taking client data when they leave, are breaches too. They can also raise employment and criminal issues, so coordinate with HR before confronting the individual. Our employment team can help with the internal process.
Incident response: the first 72 hours
- Contain and preserve. Stop the breach, isolate affected systems, change credentials and preserve logs and evidence. Avoid wiping systems before forensic images are taken.
- Convene the response team. Bring together IT, the data protection lead, legal, communications and senior management. Engage external forensic and legal advisers early, ideally through counsel to protect privilege where possible.
- Establish awareness and the clock. Record when the organisation became aware, meaning a reasonable degree of certainty that a security incident has compromised personal data. That starts the 72 hours.
- Assess the risk. Identify the data, the individuals and the likely consequences, and document the reasoning for the reporting decision.
- Notify the regulator if required. Submit a report describing the nature of the breach, the categories and approximate numbers of individuals and records, the contact point, the likely consequences and the measures taken. Send what you know and update later.
- Tell individuals if high risk. Use clear and plain language, explain what happened, the likely consequences and what they can do, such as changing passwords or watching for fraud.
- Consider other notifications. Sector regulators, the police, the National Cyber Security Centre, insurers, banks, customers under contract and overseas regulators may also need to be told.
- Record and review. Log the breach, the decisions and the remedial steps, then fix the root cause and update policies and training.
Check your contracts on day one. Many customer, outsourcing and processing agreements require notice of a breach within a short period, sometimes far shorter than 72 hours, and insurance policies often require prompt notification and consent before external advisers are appointed. Missing a contractual deadline can create liability even where the regulatory response is sound.
Ransomware decisions
Ransomware raises questions that go beyond data breach reporting. Encryption of personal data is a breach of availability even if no data is taken, and most modern attacks also involve data theft and threats to publish, which usually means a high-risk breach.
Whether to pay is a commercial and legal decision with no guarantee of outcome. Payment does not remove the duty to notify, does not ensure deletion of stolen data, and regulators do not treat payment as a mitigation in itself. Paying a person or entity subject to UK financial sanctions can be a criminal offence, so sanctions screening and the guidance of the Office of Financial Sanctions Implementation must be considered before any payment. The government has also announced plans to restrict ransom payments by public sector bodies and operators of critical national infrastructure and to require reporting of ransomware incidents; check the current status before relying on any position.
The National Cyber Security Centre provides incident guidance and should be contacted for significant incidents. Our cyber security solicitors and our guide to UK sanctions compliance cover the wider issues.
Paying a ransom does not end the breach: the duty to notify, the sanctions risk and the regulator's questions all remain.
Sector rules and parallel reporting duties
Data breach reporting to the ICO is rarely the only notification. Operators of essential services and certain digital service providers have incident reporting duties under the Network and Information Systems Regulations 2018. FCA-regulated firms are expected to notify the FCA of matters it would reasonably expect to know about, which includes significant operational and cyber incidents. Telecoms providers have the PECR duty. The Cyber Security and Resilience Bill proposes to widen and speed up incident reporting for regulated sectors and managed service providers; our guide to the Cyber Security and Resilience Bill tracks its progress.
Breaches involving EU residents may also require notification to EU supervisory authorities under the EU GDPR, and other countries, including in the Gulf and Asia, have their own breach reporting regimes. A cross-border incident should be mapped against each relevant regime early, because the deadlines and thresholds differ.
Illustrative scenario: a ransomware attack on a professional services firm
This scenario is illustrative only. On a Friday evening, a firm's IT provider discovers that servers have been encrypted and a ransom note claims client files have been copied. By Saturday morning, forensic investigators confirm that data was taken from a shared drive containing client identity documents and bank details.
The firm records Saturday morning as the point of awareness. It isolates systems, notifies its insurer, appoints forensic and legal advisers, and screens the threat actor against sanctions lists. With identity and financial data affected, it treats the breach as high risk. It files an initial report to the ICO within 72 hours, notes that the investigation is continuing, and sends an updated report once the affected data set is confirmed.
It writes to affected clients in plain language, explaining what to watch for, and notifies its professional regulator and the police. It declines to pay the ransom on advice. Afterwards, it documents the root cause, implements multi-factor authentication across remote access and updates its incident response plan.
Regulatory follow-up and enforcement
After a report, the regulator may close the matter with advice, ask detailed questions, issue a reprimand, or open an investigation leading to an enforcement notice or a fine. Since the 2025 Act, it can also compel interviews and require technical reports, which makes the quality of contemporaneous records more important. Expect questions on security measures before the breach, how quickly the breach was detected, the reasoning behind the reporting decisions and the remediation plan.
Affected individuals may bring compensation claims, sometimes as group claims. Keeping a clear, honest record of the response and being careful about privilege in forensic reports both matter in later litigation. Our group litigation team advises on data breach claims.
Preparing before a breach happens
Effective data breach reporting depends on decisions made long before an incident. The organisations that handle breaches best have a short, practical incident response plan, a named team with deputies, out-of-hours contact details, pre-agreed external forensic and legal support, and template notifications for the regulator and for individuals.
Preparation also means knowing your data. If you cannot quickly say which systems hold which categories of personal data and about whom, you cannot assess risk within 72 hours. Data maps, records of processing and retention schedules all shorten the assessment, and data that has been properly deleted cannot be breached. Supplier contracts should require prompt notice and cooperation, and cyber insurance terms should be read in advance so that notification conditions are not missed.
Finally, rehearse. A tabletop exercise that walks through a realistic scenario, such as ransomware on a Friday night, tests the plan, the contact list and the decision-making, and gives the board confidence that the organisation will meet its data breach reporting duties under pressure.
Common mistakes in data breach reporting
Waiting for certainty before starting the clock
Organisations often treat the 72 hours as starting only once the investigation confirms what happened. The regulator expects the clock to start once you have a reasonable degree of certainty that a security incident has compromised personal data. Investigating briefly to establish that is legitimate; using the investigation to postpone awareness is not. Report in phases if needed, and explain any delay.
Over-reporting or under-reporting
Some organisations report every incident to be safe, which wastes resources and invites scrutiny; others under-report to avoid attention. Both reflect weak risk assessment. A documented, consistent risk methodology, applied to every incident and recorded in the breach log, is the best protection against criticism either way.
Inaccurate first reports
Initial reports that understate the scope, or communications to individuals that later prove wrong, damage credibility with the regulator and customers. State what is known, what is not yet known and when you expect to update. Avoid early reassurance that data was not taken unless that is confirmed.
Ignoring processors and contracts
Many breaches occur at suppliers. Processor contracts should require immediate notice and cooperation, and controllers must chase information rather than wait. Equally, your own customer contracts may require earlier notice than the law. Map these obligations before an incident, not during one.
No post-incident remediation
The regulator will want to see that the root cause has been fixed. Organisations that suffer repeat breaches of the same kind, without evidence of learning, face a much greater risk of enforcement. Record lessons learned, track actions to completion and report progress to the board.
What to do next
- Adopt a written incident response plan with named decision-makers and out-of-hours contacts.
- Set a documented risk assessment method for data breach reporting decisions.
- Map contractual, insurance, sector and overseas notification duties.
- Keep a breach log for every incident, reported or not.
- Agree a ransomware decision framework, including sanctions screening.
- Run a tabletop exercise at least annually with legal, IT and communications.
Our data protection solicitors can prepare your plan or support a live incident, and our UK GDPR compliance checklist covers the wider framework. If you are dealing with a breach now, contact our London office or email info@trw.co.
Frequently asked questions
01When does the 72-hour clock start?
When the controller becomes aware of the breach, meaning it has a reasonable degree of certainty that a security incident has led to personal data being compromised. A short initial investigation to establish that is acceptable, but the clock does not wait for a full forensic report. If you cannot provide all the information within 72 hours, report what you know and provide the rest in phases, explaining any delay.
02Do all data breaches have to be reported to the ICO?
No. A breach must be reported unless it is unlikely to result in a risk to the rights and freedoms of individuals. Low-risk incidents, such as a lost device with strong encryption and secure keys, may not need reporting. However, every breach must be recorded internally with the facts, effects and remedial action, and your reasoning for not reporting should be documented in case the regulator later asks.
03When must we tell the people affected?
When the breach is likely to result in a high risk to their rights and freedoms, for example where financial, health or identity data has been stolen. You must tell them without undue delay, in clear and plain language, describing the breach, its likely consequences, the measures taken and a contact point. Exceptions apply where the data was unintelligible, the risk has been removed or individual notice would be disproportionate.
04Should we pay a ransomware demand?
There is no general legal prohibition on private organisations paying, but payment carries legal and practical risk. Paying a sanctioned person can be a criminal offence, payment does not guarantee data deletion or decryption, and it does not remove the duty to notify the regulator or individuals. The government has announced plans to restrict payments by the public sector and critical national infrastructure, so check the current position and take advice before deciding.
05What happens after we report a breach?
The regulator may close the case with advice, ask follow-up questions, issue a reprimand or open an investigation that can lead to an enforcement notice or fine. It may ask about security measures, detection, decision-making and remediation. Since the 2025 Act it can also compel interviews and require technical reports. Affected individuals may bring compensation claims, so keep accurate records and consider privilege in forensic work.
06Does a processor have to report breaches to the ICO?
Under the UK GDPR, a processor must notify the controller without undue delay after becoming aware of a breach; the controller then decides whether to report to the regulator and individuals. Processor contracts should set out the timing and information required. A processor that is also a controller of other data, or a telecoms provider under PECR, may have its own direct reporting duties.
Sources and official materials
- UK GDPR Article 33 — Notification of a breach to the regulator
- UK GDPR Article 34 — Communication of a high-risk breach to individuals
- Data Protection Act 2018, section 157 — Maximum penalty amounts
- Data (Use and Access) Act 2025 — PECR breach timing and regulator powers
- National Cyber Security Centre — Incident management and ransomware guidance
- Office of Financial Sanctions Implementation — Sanctions risk in ransom payments
- Information Commission (ICO) — Breach reporting guidance and online reporting
General information only, current as at 21 October 2026. It is not legal advice and does not create a solicitor–client relationship. It reflects the law of England and Wales unless stated otherwise; Scotland and Northern Ireland have separate legal systems, and the law changes frequently. Check current official sources and take advice on the facts of your matter.