Data Breach Response Plan Template for GDPR

Last updated: 10 October 2026

Quick answer: A data breach response plan is a documented procedure for detecting, containing, assessing, notifying and learning from personal data breaches. Under GDPR and UK GDPR it must let you notify the supervisory authority within 72 hours of awareness where required, tell affected people when risk is high, and record every breach.

When a breach happens, nobody has time to work out who decides, who calls the regulator or where the evidence goes. A data breach response plan settles those questions in advance, so the first hours are spent containing the incident rather than arguing about process.

This guide gives DPOs a practical data breach response plan template aligned with Articles 33 and 34 of the GDPR and the UK GDPR, a 72-hour timeline, a risk assessment matrix and a comparison of EU and UK reporting rules, including how NIS2 and DORA incident reporting fit alongside.

What is a data breach response plan?

It is the written procedure your organisation follows from the moment a possible personal data breach is spotted until lessons are learned. A good plan covers people, decisions, deadlines and records, not just technical steps.

The GDPR defines a personal data breach broadly: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That covers a stolen laptop, a misdirected email and a ransomware attack alike, which is why your plan must handle small incidents as well as major ones.

The GDPR does not use the phrase “response plan”, but three obligations make one essential:

• Article 33: notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to individuals. Processors must notify the controller without undue delay.
• Article 34: communicate the breach to affected individuals without undue delay when it is likely to result in a high risk to their rights and freedoms.
• Article 33(5): document every personal data breach, its effects and the remedial action taken, whether or not it was notified.

Article 32 adds the expectation of a process for regularly testing and evaluating the effectiveness of your security measures, and a tested response plan is part of that evidence.

Data breach response plan template

Use these eleven sections as the skeleton of your plan. Keep the plan short enough to use under pressure and move detailed checklists into appendices.

1. Purpose and scope. Which entities, systems, data and jurisdictions the plan covers, and how it relates to your wider security incident procedure.
2. Definitions. Personal data breach, security incident, near miss, “awareness”, and your risk levels.
3. Roles and contacts. Breach lead, DPO, IT or security lead, legal, communications, HR, executive decision-maker and their deputies, with out-of-hours contacts.
4. Detection and internal reporting. How staff and processors report a suspected breach, and a single reporting channel that is monitored at all times.
5. Containment and recovery. Immediate steps to stop the breach, preserve evidence, recover data and limit harm.
6. Risk assessment. How you rate likelihood and severity for the people affected (see the matrix below).
7. Notification decisions. Criteria and authority for notifying the supervisory authority, affected individuals and other regulators.
8. Communications. Templates for regulator notifications, individual notices, customer and media statements, and who approves them.
9. Documentation. The breach register fields and where evidence is kept.
10. Post-incident review. Root cause analysis, corrective actions and updates to risks, controls and this plan.
11. Testing and training. Exercise schedule, training for first responders and review date for the plan.

In practice: the most useful single page in the plan is the contact sheet with deputies. Breaches rarely happen when the DPO is at their desk.

The plan should sit with your other controlled documents and be versioned like them. A policy management module can track approvals, versions and staff acknowledgements for the plan and the security incident policy it links to.

What happens in the first 72 hours?

The 72-hour clock starts when the controller becomes aware of the breach, not when the investigation ends. The EDPB’s Guidelines 9/2022 on breach notification (version 2.0, adopted in 2023) treat a controller as aware when it has a reasonable degree of certainty that a security incident has compromised personal data.

The GDPR allows information to be provided in phases where it is not all available at once. The ICO’s breach guidance says the same for the UK: you can report in phases, as long as you do so without undue further delay, and you must give reasons if you report after 72 hours.

Common mistake: waiting for the forensic report before notifying. A late but complete notification is still late. Notify with what you know and follow up.

How do you assess the risk of a data breach?

Assess the likely consequences for the individuals affected, not the impact on your organisation. The result decides whether you notify the authority (any risk) and the individuals (high risk).

Consider the type and sensitivity of the data, how many people are affected, how easily they can be identified, how severe the consequences could be, whether the individuals are vulnerable (children, patients, employees in a dispute) and whether the data was protected, for example by strong encryption with the key uncompromised.

Article 34(3) lists three cases where you need not notify individuals even if risk is high: the data was made unintelligible (for example, by encryption), you have taken measures so the high risk is no longer likely to materialise, or individual notice would involve disproportionate effort, in which case a public communication is required instead.

What must a breach notification include?

Article 33(3) sets the minimum content of a notification to the supervisory authority:

• the nature of the breach, including, where possible, the categories and approximate number of individuals and records concerned
• the name and contact details of the DPO or other contact point
• the likely consequences of the breach
• the measures taken or proposed to address the breach and mitigate its possible adverse effects

Notices to individuals must use clear and plain language and include at least the DPO contact, the likely consequences and the measures taken, plus practical advice such as changing passwords or watching for phishing.

Knowing what data sits where makes this much faster. An up-to-date record of processing activities tells you which systems hold which categories of data before you need the answer in an emergency.

If you want to try running the 72-hour workflow against your own processing records, you can start your 14-day free trial.

How do EU and UK breach reporting rules compare?

The core rules are almost identical, but authorities, fines and parallel regimes differ.

Under NIS2 Article 23, significant incidents go to the CSIRT or competent authority on a separate cascade. DORA financial entities must send an initial notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware, an intermediate report within 72 hours and a final report within a month. One incident can trigger all three, so your plan should say who files each report. Our NIS2 incident reporting guide covers that cascade in detail. Our guide to DORA compliance in 2026 covers the financial sector side.

Watch this space: the European Commission’s Digital Omnibus package, proposed on 19 November 2025, would extend the GDPR deadline to 96 hours, limit authority notification to high-risk breaches and create a single EU entry point for GDPR, NIS2 and DORA reports. It is still a proposal, so plan against the current 72-hour rule.

How should you test the data breach response plan?

Run at least one tabletop exercise a year using a realistic scenario, such as ransomware on a system holding special category data. Time each decision against the 72-hour clock and record what slowed you down.

• Test the out-of-hours reporting channel and contact sheet.
• Include a processor in one exercise to check they notify you promptly.
• Practise drafting the regulator notification with incomplete facts.
• Review the breach register quarterly for patterns, such as repeated misdirected emails.
• Update the plan after every real breach and every exercise.

A connected incident and data breach management workflow timestamps each step, so exercises and real incidents produce the evidence regulators ask for.

Key takeaways

• The plan must let you notify within 72 hours of awareness, communicate high-risk breaches to individuals and record every breach.
• Assess risk to individuals, not to the organisation, and document the reasoning for each decision.
• Report in phases rather than waiting for complete facts.
• Map NIS2, DORA and contractual reporting duties into the same plan.
• Test the plan annually and update it after every incident.

Frequently asked questions

Is a data breach response plan a legal requirement under GDPR?
The GDPR does not require a document with that name, but Articles 33 and 34 require you to notify within strict deadlines and Article 33(5) requires you to record every breach. Meeting those duties reliably is very hard without a documented plan, and regulators commonly expect to see one as evidence of accountability and appropriate security.

When does the 72-hour deadline start?
It starts when the controller becomes aware of the breach. The EDPB treats awareness as having a reasonable degree of certainty that a security incident has compromised personal data. A short initial investigation to establish that is acceptable, but it should begin promptly. Processors must tell the controller without undue delay so the controller’s clock is not wasted.

Do we need to report every personal data breach?
No. You must notify the supervisory authority unless the breach is unlikely to result in a risk to individuals’ rights and freedoms, and notify individuals only where the risk is high. However, every breach must be recorded internally, including the facts, effects and remedial action, along with the reasoning behind any decision not to notify.

What if we cannot get all the facts within 72 hours?
Notify anyway with the information you have. Both the GDPR and the UK GDPR allow information to be provided in phases without undue further delay. Explain in the first notification what you are still investigating and when you expect to update the authority. If you do notify late, you must give reasons for the delay.

Who should own the data breach response plan?
The DPO or privacy lead usually owns the notification and documentation parts, while the security team owns detection and containment. A named executive should hold decision authority for notifications. Whoever owns it, the plan must name deputies for every role so decisions can still be made quickly out of hours or during holidays.

Making your data breach response plan work under pressure

A data breach response plan is only as good as the first hour of its use. Keep it short, name the decision-makers and their deputies, practise against the 72-hour clock and record every decision. The same plan can then carry NIS2, DORA and contractual reporting duties without confusion.

Enactia’s AI-powered GRC platform includes incident and data breach management with 72-hour notification workflows linked to your processing records and risks. To discuss your breach readiness, contact us or book a demo or start your 14-day free trial.

This article is for general information and is not legal advice.