Data Breach Response Procedure template

2. What counts as a personal data breach

• An email, letter, or attachment containing personal data sent to the wrong recipient.
• A lost or stolen laptop, phone, memory stick, or paper file.
• A phishing compromise, ransomware infection, or other unauthorised access to systems holding personal data.
• Staff accessing records they have no work reason to see.
• Accidental deletion or alteration of personal data with no backup.
• If in doubt, report it — the assessment below decides whether it matters, not the person who spotted it.

3. Roles and responsibilities

• Breach lead ([name/role], deputy [name/role]): runs the response, owns the breach log, and makes the ICO notification decision with [senior role].
• IT support ([name/provider]): contains technical incidents and preserves evidence.
• All staff: report suspected breaches immediately by [phone number/channel]. Honest mistakes reported promptly are never treated as misconduct; concealment is.

4. Immediate actions: report and contain

1. 1Report the suspected breach to the breach lead at once by [phone/channel] — including evenings and weekends. Do not wait for the next working day.
2. 2Record the time you became aware. The 72-hour clock for any ICO report runs from this point.
3. 3Contain the breach: recall the email, remote-wipe the device, disable compromised accounts and change passwords, isolate affected systems, or retrieve the papers — whichever applies.
4. 4Preserve evidence. Do not delete emails, logs, or files connected to the incident.
5. 5Ask any unintended recipient to delete the data and confirm in writing that they have.

5. Assess the risk

1. 1Establish the facts: what data, about whom, how many people, what caused it, and whether the data is still exposed.
2. 2Assess the likelihood and severity of harm to the individuals affected — fraud, financial loss, distress, discrimination, or physical risk.
3. 3Weight the assessment up where special category data, financial details, or children's data are involved.
4. 4Record the assessment and conclusion in the breach log, however minor the incident.

6. Decide whether to notify the ICO

The breach lead and [senior role] decide, based on the assessment, whether the breach is likely to result in a risk to individuals. If it is, report it to the ICO within 72 hours of becoming aware, using the ICO's online reporting route. You do not need every fact before reporting — the ICO accepts information in phases, so never let an incomplete picture run the clock down.

If the decision is not to report, record the reasons in the breach log. That record is what shows the decision was considered, not missed.

7. Telling the people affected

If the breach is likely to result in a high risk to the individuals affected, tell them without undue delay, in plain language: what happened, what data was involved, what we are doing, what they can do to protect themselves, and who to contact at {{org.name}}. Coordinate with [insurer/IT provider/other organisations involved] before communicating, but do not let coordination become delay.

8. Records, lessons, and review

Every breach and near miss goes in the breach log kept at [system/location]: dates and times, facts, assessment, decisions, notifications, and actions. Within [period, e.g. two weeks] of closing an incident, the breach lead runs a short lessons-learned review and feeds any fixes into training, systems, or this procedure.

This procedure is reviewed [frequency, e.g. annually] and after every reportable incident. Owner: [name/role]. Next review due: [date].