Almost every UK organisation has an incident response plan for the technology. Far fewer have one for the privacy side of the same incident — who decides whether it has to be reported, what the regulator has to be told, what affected people have to be told, and where the record of it lives afterwards. That last part is not optional: Article 33(5) of the UK GDPR requires you to document every personal data breach, whether or not it was reportable, together with its effects and what you did about it. Most organisations we assess cannot produce that record.
This template is the privacy half of your response. Adapt it, put a name against every role, and keep it beside your technical runbook.
Before you adopt it
The clock starts when you find out, not when you finish deciding.
The UK GDPR gives you a number: 72 hours from becoming aware, under Article 33. A number sounds easier than an open-ended test and is usually harder, because the clock runs through weekends and bank holidays, and it starts when somebody in your organisation first knows — not when the investigation finishes and not when it reaches the board. Miss it and you may still report, but you must tell the ICO why you were late. A template does not buy you that time. Naming the decision-maker in advance does.
This document is a starting point for your own legal and privacy advice. It is not legal advice, and adopting it does not make you compliant.
Privacy breach response policy
[ORGANISATION] · approved by [ROLE] · [DATE] · review annually
1. Purpose and scope
This policy sets out how [ORGANISATION] responds when personal information under our control is lost, accessed, used or disclosed without authorisation. It applies to every employee, contractor and director, to every system we run and every system a supplier runs on our behalf, and to information in any form — digital, paper or spoken.
It sits alongside our technical incident response procedure. Where the two overlap, the technical procedure governs containment and recovery; this policy governs assessment, notification and record keeping.
2. What counts as a breach
Under the UK GDPR a personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It covers availability as well as confidentiality — losing access to data you still hold is a breach.
Two separate duties follow from it. Article 33 decides whether the ICO must be told. Article 34 decides whether the people affected must be told. They are different tests with different thresholds, and running them as one decision is the most common mistake we see.
In practice, all of the following are reportable to [PRIVACY LEAD] immediately, whether or not anything was ultimately exposed:
- An email, letter or file sent to the wrong recipient
- A lost or stolen laptop, phone, USB drive or paper file
- A folder, mailbox, drive or database shared more widely than intended
- A password, token or account known or suspected to be compromised
- Personal information pasted into a public AI tool or any unapproved service
- A ransomware or intrusion event touching any system that holds personal information
- A supplier telling us they have had an incident affecting our data
Staff are not asked to judge severity. They are asked to report, quickly, and without fear of blame. Reporting an incident that turns out to be nothing is always the right call.
3. Who does what
- Anyone who becomes aware of an incident reports it to [PRIVACY LEAD] at [EMAIL] or [PHONE] without delay, and does not attempt to investigate or conceal it.
- [PRIVACY LEAD] owns this policy, records the incident in the register, coordinates the assessment, and drafts every notification.
- [ROLE — technical owner] contains the incident, preserves evidence and logs, and reports what was accessed and by whom.
- [ROLE — accountable executive] makes the final decision on whether the incident is notifiable and signs off every external communication. This decision is not delegated to the technical team.
- [ROLE — board or owner] is informed of every notifiable incident within [24 hours] of that determination, and receives a summary of all incidents at each [quarterly] meeting.
Deputies are named for each role above, because incidents do not wait for people to come back from leave.
4. The first hour
- Contain. Stop the exposure — recall the message, revoke the share, disable the account, isolate the device.
- Preserve. Do not delete anything. Do not wipe the device. Logs, headers and copies of the message are the evidence we will be asked for.
- Record. [PRIVACY LEAD] opens a register entry immediately, even before anyone knows how serious it is.
- Do not notify anyone externally yet. No email to customers, no post, no statement to a journalist, until section 6 and section 7 have been worked through and [ROLE — accountable executive] has approved the wording.
5. Assessing the risk
Two tests apply, and an incident can trigger one without the other.
Article 33 — a risk to rights and freedoms. We weigh the sensitivity of the data, the volume, how easily individuals could be identified from it, and the likelihood and severity of harm. Harm includes financial loss, identity theft or fraud, damage to reputation, discrimination, loss of confidentiality of data under professional secrecy, and any other significant economic or social disadvantage. Unless the breach is unlikely to result in a risk to people’s rights and freedoms, the ICO is told.
Article 34 — a high risk to rights and freedoms. A deliberately higher bar. Where it is met we tell the people affected as well, unless one of the three exemptions in Article 34(3) applies: the data was encrypted or otherwise unintelligible, later measures mean the high risk is no longer likely, or direct contact would take disproportionate effort and a public announcement will do instead. We record which exemption we relied on and why.
The assessment is written down at the time, with the reasoning, whichever way it goes. A decision not to notify is the one most likely to be examined later, so it is the one that most needs a record.
6. Reporting to the regulator
Where the Article 33 test is met, [ROLE — accountable executive] reports to the Information Commissioner’s Office without undue delay and no later than 72 hours after we became aware. The report describes the nature of the breach, including the categories and approximate number of people and of records concerned; the name and contact details of our data protection contact; the likely consequences; and the measures taken or proposed, including any to mitigate the effects. If we cannot supply all of that inside 72 hours we report what we have, say so, and supply the rest in phases rather than waiting.
Where the Article 34 test is met, we tell the people affected without undue delay, in clear and plain language, describing the likely consequences and what we are doing about it.
Where we handle the data as a processor for another organisation, we tell that controller without undue delay, as Article 33(2) requires — the decision whether to report to the ICO is theirs. Where another body could help reduce the harm — a bank, the police or Action Fraud — we consider telling them too. Our contractual obligations to notify a customer, insurer or regulator in a set number of hours are listed in [APPENDIX A] and are usually tighter than the law.
7. Notifying the people affected
Where the Article 34 test is met, the people affected are told without undue delay, directly, in clear and plain language they can act on. A public communication is used instead only where Article 34(3)(c) applies — contacting people individually would involve disproportionate effort — and it must inform them in an equally effective way.
Each notification states what happened and when, what information about them was involved, what we have done to reduce the risk, what they can do to protect themselves, and how to reach a named person at [ORGANISATION] for more.
Notifications are drafted before they are needed. A template written under pressure reads like one.
8. The register
[PRIVACY LEAD] maintains a single register of every incident — not only the ones that were notifiable. The ICO can ask to see it, and the register is the evidence that a decision not to notify was actually a decision.
Each entry records: a description of the personal information involved (or why that is not known); the circumstances; the date or period the incident occurred; the date or period we became aware of it; the number of people affected; the reasoning behind our risk assessment; if notifiable, the dates the regulator and the individuals were notified and whether a public notice was given; and the effects of the breach, and the remedial action taken to contain it, mitigate its effects and prevent a recurrence.
How long we keep it. The UK GDPR sets no fixed period, which is not the same as no period: it must be long enough for the ICO to verify our compliance. We keep every entry for six years from the date of the entry — five in Scotland — matching the ordinary limitation period, so the record still exists if a claim or a complaint arrives late. Nothing in the register is deleted early to tidy it up.
9. Suppliers
Every contract under which a supplier handles personal information on our behalf requires them to notify [PRIVACY LEAD] of any incident affecting our data within [24 hours] of becoming aware of it, and to give us the information we need to make our own assessment. An incident at a supplier is our incident: the obligation to report and notify stays with us.
10. Learning and testing
Every incident is closed with a short written note of what allowed it to happen and what has changed as a result. [ORGANISATION] runs a walkthrough of this policy at least once a year, using a realistic scenario, with the people actually named in section 3 in the room. The date of the last walkthrough is [DATE].
This policy is reviewed annually and after any notifiable incident.
Practical tip
Chief Privacy Officer
Before you write a privacy policy, write down what personal information you actually hold. Most organisations find the policy was describing a slightly different company.
UK privacy governance · the people who do the work
Send us your version. We will read it properly.
Adapt this to your organisation and we will review what you have written against the UK GDPR, the Data Protection Act 2018 and our control set, and tell you plainly where it would not hold up. No charge, no obligation, and we will not add you to anything.