Does every security incident need to be reported to the ICO?

No. Only breaches that pose a risk to individuals' rights and freedoms are notifiable. A denial-of-service attack that takes a marketing website offline without exposing personal data is not notifiable. Unauthorised access to a customer database, a misdirected email containing personal data, or a lost unencrypted laptop are typically notifiable. When in doubt, the ICO's own guidance is to notify.

What happens if we don't notify within 72 hours?

Late or missed notification is itself a compliance failure the ICO can act on, separate from the breach itself, and can contribute to a fine of up to £17.5 million or 4% of global annual turnover, whichever is greater. A partial notification made within 72 hours, followed by supplementary detail as your investigation continues, is treated far more favourably than a complete report filed late.

What must be included in the notification?

The ICO expects the date of the incident and the date you became aware of it, the nature and categories of personal data affected, the approximate number of individuals and records involved, the likely consequences and risks, the technical and organisational measures taken or proposed, and the reasons for any delay in notification.

Does a small business need a formal incident response plan?

Yes. UK GDPR's accountability principle applies regardless of organisation size, and the 72-hour clock starts the moment you become aware of a breach, not when you finish investigating it. A documented plan, even a simple one naming who does what, is what makes a 72-hour deadline achievable rather than aspirational.

Data Breach Notification: What to Do in the First 72 Hours

Key takeaways

UK GDPR Article 33 gives you 72 hours from becoming aware of a notifiable breach to report it to the ICO, not 72 hours from when the breach occurred
Not every incident is notifiable. The threshold is whether the breach poses a risk to individuals' rights and freedoms
A partial notification filed within 72 hours, with supplementary detail to follow, is treated far more favourably by the ICO than a complete report filed late
Following a structured six-phase response (preparation, identification, containment, eradication, recovery, post-incident review) keeps you within the deadline and produces the evidence the ICO expects
Maximum fines under UK GDPR reach £17.5 million or 4% of global annual turnover, whichever is greater, and late notification is itself a compliance failure separate from the underlying breach

Why the first hours define the outcome

Early containment limits how much data is exposed and how many systems are affected. A ransomware infection caught and isolated within an hour of detection typically affects a fraction of the systems that the same infection would reach after a full working day of undetected lateral movement. The same logic applies to unauthorised access: the sooner you revoke a compromised credential, the smaller the window in which it could have been used.

A documented, timestamped response also does something UK GDPR Article 33 explicitly asks for: it demonstrates that you had appropriate technical and organisational measures in place. The ICO's assessment of any breach weighs your posture and your response, not just the fact that a breach occurred.

72h

to notify the ICO from the moment you become aware of a notifiable breach

£17.5M

maximum fine, or 4% of global annual turnover, whichever is greater

grace period for organisations that were "still investigating"

What qualifies as a notifiable incident

UK GDPR Article 33 sets the threshold at risk to individuals' rights and freedoms, not at the existence of a security incident. A denial-of-service attack that knocks your public website offline for two hours, with no personal data exposed, is a security incident but is not notifiable. Unauthorised access to a customer database, a spreadsheet of applicant CVs emailed to the wrong recipient, or an unencrypted laptop containing employee records left on a train are all likely notifiable.

Assess risk against a small number of criteria: how sensitive is the data involved (financial details and health data carry more risk than a name and email address alone), how many individuals and records are affected, what could the data be used for if misused (identity theft and financial fraud represent higher risk than nuisance contact), and whether the exposure is reversible (a password can be reset; a leaked passport scan cannot be un-leaked).

Rule of thumb

When you are genuinely unsure whether a breach meets the notification threshold, the ICO's own guidance is to notify. A partial notification submitted within 72 hours, with a note that the investigation is ongoing and full details will follow, is treated far more favourably than a complete report filed after the deadline has passed.

The six phases of incident response

1. Preparation

Preparation happens before an incident, not during one. This means a documented response plan, a named team with defined roles, and playbooks for your most likely scenarios. Set clear escalation criteria for when the DPO, legal counsel, and executive leadership need to be brought in. See our incident response services for how we help organisations build this in advance.

2. Identification

Confirm the scope of what happened before you act on assumptions. Preserve logs and other evidence before you begin containment, since containment actions themselves (isolating a system, resetting credentials) can overwrite the evidence you need for both your ICO notification and any subsequent investigation.

3. Containment

Isolate affected systems to stop the incident spreading. Timestamp every action your team takes from this point. Containment is not the same as recovery: the goal here is to stop the bleeding, not to restore normal operations.

4. Eradication

Remove the root cause before you restore anything. Restoring a system to production before the vulnerability or malicious presence that caused the incident has been eliminated is one of the most common causes of reinfection.

5. Recovery

Restore from backups that have been verified clean, not simply the most recent backup available. Monitor restored systems closely for signs of reactivation before declaring the incident closed.

6. Post-incident review

Document what happened, what worked, and what did not. This record feeds directly into the accountability evidence UK GDPR expects you to maintain and should update your response plan and playbooks for next time.

Restoring a system before containing the incident is the most expensive mistake in incident response. It buys back a few hours of downtime and can cost weeks of reinfection and a much harder conversation with the ICO.

What to include in the notification to the ICO

Date and awareness

The date the incident occurred, and separately, the date you became aware of it. These are often different and both matter to the ICO's assessment.

Nature of the data

The categories of personal data affected: names and contact details, financial information, health data, or special category data each carry different risk weightings.

Scale

An estimate of the number of individuals and the number of records affected, even if this is a preliminary figure pending full investigation.

Likely consequences

The realistic risks to affected individuals: identity theft, financial loss, distress, or reputational harm, based on what the exposed data could be used for.

Measures taken

The technical and organisational steps already taken or proposed to address the breach and mitigate its effects.

Reasons for delay

If notification is made after 72 hours, an explanation of the reasons for the delay is required alongside the substantive report.

Where a breach is likely to result in a high risk to individuals, UK GDPR Article 34 requires you to notify those individuals directly, without undue delay, in addition to your notification to the ICO.

How to build your plan before you need it

1. Define your team and emergency contacts

Name specific individuals, not job titles alone, for incident lead, technical response, legal, and communications. Keep contact details current and accessible outside your primary systems, in case those systems are the ones affected.

2. Document your notification criteria

Write down the risk factors your organisation uses to decide whether a breach is notifiable, so the decision does not have to be made from scratch under pressure.

3. Build playbooks for your top scenarios

Ransomware, unauthorised database access, a lost or stolen device, and a third-party or supplier data leak cover the large majority of incidents most organisations face. A specific playbook for each removes decision-making friction when time is short.

4. Establish an evidence preservation process

Define what gets logged, how, and for how long, before an incident happens. Evidence preserved incorrectly during the heat of containment is evidence you cannot use in your ICO notification or any later investigation.

5. Test the plan annually

A tabletop exercise, walking a realistic scenario through your plan with the actual people who would respond, reveals gaps that a document review never will.

6. Review the plan after every real incident

Treat every actual incident, however minor, as a live test of the plan and update it based on what you learn.

Cyvra can help

We help organisations build incident response plans that hold up under pressure, run tabletop exercises, and provide retained incident response support so the 72-hour clock is never a surprise. Get in touch to discuss your current plan.

Disclaimer

This article provides general information and does not constitute legal advice. Whether a specific incident is notifiable depends on its facts and should be assessed with your Data Protection Officer or legal counsel.

Data breach notification: what to do in the first 72 hours