Independent UK governance, risk & complianceOur editorial standards ↗Practical guidance. Accountable decisions.

Compliance · Practical guide

Incident and personal data breach escalation

Prepare a clear response route, assess harm and record the reasons for reporting or not reporting a personal data breach.

Published 4 min readBy GRC.me.uk editorial desk · AI-assisted

Read with the right scope

UK GDPR personal data breaches and a suggested wider incident-management process. Other statutory, sector and contractual duties may apply.

Status: Law and ICO guidance, with operational suggestions

Your working outputA chronological incident record separating known facts, uncertainty, containment, notification decisions, recovery and remaining remedial work.
Open the matching template ↗Use the working tool ↗

Separate the incident from the notification decision

Not every operational incident is a personal data breach, and not every personal data breach must be notified to the regulator. Under UK GDPR Article 33, a controller must notify a personal data breach without undue delay and, where feasible, within 72 hours of awareness, unless it is unlikely to result in a risk to people's rights and freedoms. A late notification requires reasons for the delay.

If a breach is likely to result in high risk to people, the separate requirement to inform affected individuals without undue delay must be considered. Processors must inform the controller without undue delay. Keep records of personal data breaches, including those not notified, and document the reasoning. These rules do not create a universal 72-hour reporting deadline for every kind of incident.

Make escalation possible under pressure

Give staff a simple internal reporting route and a fallback when the usual owner is unavailable. Treat prompt escalation as a useful signal. A team should not wait for a complete investigation before involving the people who can assess notification duties and containment.

For the first response, record when the incident was detected, when the organisation became aware of a breach, what is known and what remains uncertain. Preserve relevant evidence, limit further exposure and involve competent technical, data protection and legal support where the situation calls for it. Avoid putting confidential incident details into an open project board.

Maintain a decision log

The following is a suggested response record. Keep separate reporting routes visible where sector rules, contracts or insurance arrangements add requirements.

  • Incident lead, controller/processor role and responsible decision-makers.
  • Personal data and people potentially affected, including particular vulnerability.
  • Possible harm, likelihood, severity and safeguards that change the assessment.
  • Containment actions, preservation steps and outstanding fact-finding.
  • Notification decisions, deadlines, submissions, updates and reasons.
  • Recovery criteria, lessons, corrective actions and evidence of retesting.

Rehearse the uncertain case

Test a scenario in which a supplier has only partial information and the main contact is absent. Can the team identify the controller, reach a decision-maker and locate the contract? Record where the exercise stalled, allocate improvements and repeat the failed step.

An incident marked closed should still have follow-up where the root cause remains. Distinguish service restoration from completion of remedial work. Use the outcome to update controls, supplier requirements and staff training.

Put the guide to work

Start with the evidence.

  • Detection and awareness timestamps, timezone, information source and uncertainty.
  • Identified decision-makers, organisational roles and relevant escalation routes.
  • Impact assessment and separate notification decisions with reasons and verified applicable deadlines.
  • Containment and recovery records, followed by root-cause actions and evidence of retesting.

Your first three steps

  1. Record what is known and escalate through the incident route without waiting for a complete investigation.
  2. Identify who can assess harm and applicable duties, preserving separate notification decisions and their reasons.
  3. Keep service restoration distinct from the remedial work needed to address the underlying weakness.

Common gaps to look for

  • The log merges detection, awareness and later confirmation into one time.
  • One generic notification deadline is assumed to cover every incident.
  • The incident closes when service returns, leaving the root cause unresolved.

Review when: Reassess as facts, affected people or containment effectiveness change; check notification decisions and outstanding remedial work separately.

Suggested working method. Apply the source requirements and scope explained in this guide.

Part of the compliance guidance hub. See how the GRC framework connects the disciplines.

Connect this to your review

Link the risk, control, obligation and next action in the review workspace. Record what is known, what needs checking and which decision follows. The workspace organises your records; it does not inspect or independently verify evidence.

Sources & verification

  1. UK GDPR Article 33 — notification of a personal data breach ↗Source checked 1 November 2026 · Primary source
  2. ICO — Personal data breaches: a guide ↗Source checked 1 November 2026 · Primary source
  3. ICO — Breach response and monitoring ↗Source checked 1 November 2026 · Primary source

The source list records when each reference was checked. AI-assisted research and drafting; no independent human legal review is claimed. Check for later changes and advice appropriate to your circumstances.