GDPR Data Breach Response Template

Download the GDPR Data Breach Response Template

Reviewed: 11 August 2026. Adapt this template to your organisation, sector, systems, data categories and escalation structure. It supports—but does not replace—a case-specific risk assessment.

What Is a GDPR Data Breach?

Under the GDPR (Regulation EU 2016/679), a personal data breach is a security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. This includes external cyberattacks, but also internal errors: a misconfigured database, an email sent to the wrong recipient, or a lost device containing unencrypted data. The European Data Protection Board’s breach guidance provides further examples.

Not every security incident is a personal data breach, and not every personal data breach requires notification. If a breach is unlikely to result in a risk to individuals, document it internally. If it is likely to result in a risk, notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after the controller becomes aware. If it is likely to result in a high risk, also communicate it to affected individuals without undue delay.

What makes breach response genuinely difficult is not only the law, but the time pressure. Organisations can lose valuable time when roles, escalation paths and decision owners are unclear. This template provides a consistent starting structure.

What Does the GDPR Require When a Breach Occurs?

Articles 33 and 34 of the GDPR set out the obligations for breach management. In summary:

• Article 33: Notification to the supervisory authority is required when the breach is likely to result in a risk to the rights and freedoms of individuals. The controller must notify the competent authority without undue delay and, where feasible, no later than 72 hours after becoming aware. If complete information is not yet available, it may be provided in phases without further undue delay. Where the AEPD is competent, its electronic notification procedure should be used.
• Article 34: Communication to data subjects is required when the breach is likely to result in a high risk to individuals. It must be made without undue delay and in clear, plain language, describing the nature of the breach, its likely consequences, measures taken and contact details for the DPO or other contact point.
• Article 33(5): All personal data breaches must be documented, regardless of whether notification or communication is required. The record must include the facts, effects and remedial actions taken, together with the reasoning for the notification decision. This documentation may be requested or reviewed during an audit or supervisory investigation.

A processor must notify the controller without undue delay after becoming aware of a personal data breach. The controller remains responsible for assessing regulatory notification and communication requirements. A controller is generally considered aware when it has a reasonable degree of certainty that personal data has been compromised.

Breach notification decision table

Assessment	Required response
No personal data involved	Manage as a security incident; GDPR breach notification rules do not apply.
Personal data breach unlikely to result in risk	Document the breach and the reasoning internally.
Breach likely to result in risk	Notify the competent supervisory authority.
Breach likely to result in high risk	Notify the authority and communicate to affected individuals without undue delay.

Failure to notify where required, unjustified delay, or failure to document breaches properly can contribute to fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher, under Article 83(4) of the GDPR. The amount depends on the circumstances of the infringement. See our guide on GDPR maturity.

Who Should Use This Template?

This template is designed for controllers and processors whose activities fall within the GDPR’s territorial scope. That includes organisations established in the EU and, in defined circumstances, organisations outside the EU that offer goods or services to, or monitor the behaviour of, individuals in the EU. It is particularly useful for:

• Data Protection Officers (DPOs) who need a ready-to-deploy response structure that meets the requirements of Articles 33 and 34
• Legal and compliance teams at startups and scale-ups that have not yet formalised their breach response process
• IT and security managers who need a clear handoff protocol for what happens after an incident is detected
• HR, finance and operations teams who may be first to identify a breach (phishing email, lost device, accidental data disclosure) and need to know what to do next
• CEOs and founders at smaller companies with no dedicated DPO, who are responsible for breach response themselves

The template is practical by design: it asks the right questions in the right order, maps directly to the GDPR’s legal requirements and produces documentation that holds up under scrutiny from a supervisory authority.

How to Use the Template During an Incident

1. Detect and contain the incident while preserving relevant evidence.
2. Confirm whether personal data is involved and record when the controller became aware.
3. Identify affected data, individuals, systems, recipients and jurisdictions.
4. Assess the likelihood and severity of harm and record the decision.
5. Decide whether authority notification and communication to individuals are required.
6. Submit available information in phases where necessary and track follow-up actions.
7. Record remediation, lessons learned and the post-incident review.

The risk assessment should consider data sensitivity and volume, ease of identifying individuals, possible physical, financial or non-material consequences, vulnerable people, existing safeguards such as encryption, and whether unauthorised access remains possible.

Controller and Processor Responsibilities During a Breach

The response path depends on whether the organisation is acting as a controller or a processor for the affected processing. The distinction should be recorded in the incident file rather than assumed from the commercial relationship.

When the organisation is the controller

The controller decides whether the breach is likely to create a risk to individuals, whether notification to the competent supervisory authority is required, and whether the threshold for communication to affected people is met. It also owns the Article 33(5) breach record. Technical investigation may be delegated, but the accountability decision remains with the controller.

When the organisation is the processor

A processor must notify the controller without undue delay after becoming aware of a personal data breach. The GDPR does not give processors a separate 72-hour period. Contracts should therefore define rapid escalation, the information to provide, cooperation with forensics and communications, and how updates will be delivered when facts are incomplete. A processor serving several controllers may need coordinated but separate notices because each controller makes its own legal assessment.

When several jurisdictions or establishments are involved

Do not assume that every EU breach goes only to the authority where headquarters are located. The one-stop-shop mechanism, the location of the main establishment, the affected processing and whether there is cross-border processing all matter. The incident log should record the jurisdictions involved, the reasoning used to identify the competent authority, and any local-sector notification duties that run alongside the GDPR.

How to Assess Risk to Individuals

A sound assessment combines likelihood and severity; it is not a score based only on the number of records. The team should document the facts known at the time, uncertainty, safeguards already in place and the consequences that could realistically follow. The EDPB Guidelines 9/2022 the EDPB practical examples and the AEPD guide on personal data breaches provide a useful regulatory basis.

• Data and context: categories, volume, accuracy, age, confidentiality and whether apparently harmless fields become sensitive when combined.
• People affected: number of individuals, their location and whether children, employees, patients or other vulnerable groups are involved.
• Accessibility: whether data was merely unavailable, sent to a trusted unintended recipient, exfiltrated, published or likely accessible to an attacker.
• Possible consequences: identity theft, fraud, discrimination, physical danger, loss of confidentiality, reputational harm, service denial or loss of control over personal data.
• Safeguards: effective encryption, key separation, pseudonymisation, rapid deletion, access revocation or reliable confirmation that an unintended recipient did not retain the data.

Record both the decision and the evidence behind it. A conclusion such as “low risk” is not sufficient on its own. The file should show who made the assessment, when it was reviewed, which assumptions were used and what new facts would trigger reassessment.

What an Audit-Ready Breach Record Should Contain

Record field	What to capture	Why it matters
Incident identity	Unique reference, detection time, awareness time and reporting source	Establishes the timeline and the start of decision-making
Processing roles	Controller, processor, joint-controller and affected customers	Determines notification and cooperation responsibilities
Facts and scope	Systems, data categories, individuals, jurisdictions and suspected cause	Supports risk and authority assessments
Containment and evidence	Actions taken, log sources, forensic images and chain of custody	Shows control and preserves reliable investigation material
Risk decision	Likelihood, severity, safeguards, conclusion, owner and approval time	Explains why notification or non-notification was defensible
Notifications	Authority, individuals, processors, controllers and sector bodies	Creates proof of content and timing
Follow-up	Corrective actions, owners, deadlines, testing and closure approval	Demonstrates that lessons were implemented

Phased Notification and Communication to Individuals

Incomplete information is not a reason to wait beyond the point at which notification is required. Article 33 allows information to be provided in phases without further undue delay. The first submission should clearly separate confirmed facts from estimates, explain what remains under investigation and commit to an update path. Later submissions should preserve the original timeline and explain material changes.

Where the breach is likely to result in a high risk, communication to affected individuals must be made without undue delay in clear and plain language. It should explain what happened, the likely consequences, what the organisation has done and what the individual can do—for example, resetting credentials, monitoring accounts or contacting a dedicated support channel. The AEPD’s guidance on communicating breaches explains the available routes and the limited circumstances in which individual communication may not be required.

7 Common GDPR Breach-Response Mistakes

1. Starting the clock only after the investigation is complete. Awareness can arise once the controller has a reasonable degree of certainty that a breach occurred; full forensic certainty is not required.
2. Treating every security alert as a notifiable breach. First confirm whether personal data was affected, then assess the risk threshold. All confirmed personal data breaches still require internal documentation.
3. Using record count as the only risk measure. A small breach involving health, financial or authentication data can create greater risk than a larger incident involving low-impact information.
4. Waiting for every fact before notifying. Where notification is required, available information can be submitted in phases. Delay should not become the default investigation strategy.
5. Sending a generic communication to individuals. The message should explain the likely consequences and practical protective actions in language the affected audience can understand.
6. Losing the decision trail. Chat messages and undocumented calls do not create an audit-ready record. Keep versions, timestamps, approvers, notification receipts and the basis for each decision.
7. Closing the incident after notification. Corrective actions should be assigned, tested and formally closed. The breach register should link to the post-incident review and evidence that the same weakness was addressed.

Why Having a Breach Response Template Matters

When a breach occurs, every minute counts. The 72-hour period is measured from when the controller becomes aware of a notifiable breach, not when the investigation is complete. If notification is late, the controller must explain the delay. Clear roles and records reduce the risk of delayed notifications, incomplete documentation and inconsistent assessments.

Supervisory authorities may assess both the notification decision and how the incident was managed. A documented response with clear risk reasoning, containment evidence and a timeline helps demonstrate accountable handling.

Having a template in place before an incident occurs means you are not making decisions about legal obligations, risk thresholds and communication protocols under time pressure. It means the people involved know their roles. And it means that whatever happens, you can demonstrate to regulators that you took your GDPR responsibilities seriously.

How PrivaLex Can Help

This template gives you a strong starting point, but an effective plan must reflect your processing activities, systems, data categories, vendors, jurisdictions and decision-makers. PrivaLex helps organisations convert the document into an operational response model that legal, security, communications and management teams can use under pressure.

What PrivaLex recommends in the first hours: contain the incident, preserve evidence, record the awareness time, confirm controller and processor roles, appoint a decision owner and begin the documented risk assessment immediately.

1. Breach Playbook and Escalation Design

We tailor roles, contact trees, severity criteria and decision gates to the organisation. The playbook defines who can declare a personal data breach, who records awareness, when the DPO is involved, how processors and customers are contacted, and which decisions require executive approval. It also connects the privacy workflow to the existing cybersecurity incident-response process so the teams do not run competing timelines.

2. Risk Assessment and Decision Support

We create practical criteria for likelihood, severity, vulnerability and safeguards, with examples relevant to the organisation’s data. During an incident, we can help test assumptions, distinguish confirmed facts from uncertainty, and document why the authority-notification and individual-communication thresholds are or are not met. The objective is a consistent and reviewable decision—not an unexplained score.

3. Authority and Cross-Border Analysis

We help identify the competent supervisory authority and any parallel sector, contractual or cyber-reporting obligations. For cross-border processing, this includes documenting the main-establishment analysis and coordinating information across affected group entities. Where the AEPD notification route applies, the response pack is aligned with the information the authority requests.

4. Phased Notifications and Communications

We prepare authority notifications that clearly identify facts, estimates, mitigation and information still under investigation, then maintain a controlled update log. If individuals must be informed, we help create plain-language communications, protective actions, FAQs and support-channel instructions. Messages are coordinated with security and communications teams without minimising the incident or disclosing unnecessary sensitive detail.

5. Breach Register and Evidence Pack

We structure the Article 33(5) record so the timeline, risk reasoning, decisions, notification receipts, affected processing, containment measures and corrective actions can be traced. This supports internal assurance and future supervisory questions. It also connects incident evidence with the broader records reviewed during a GDPR audit.

6. Testing, Training and External DPO Oversight

Tabletop exercises expose unclear ownership before a real breach. We test realistic scenarios, including processor notifications, wrong-recipient emails, ransomware and cross-border incidents, then assign improvements and verify closure. PrivaLex can also provide ongoing External DPO support, act as a privacy escalation point and help teams maintain audit-ready training evidence.

The aim is not a longer policy. It is a response process that produces timely decisions, useful communications and evidence that accurately reflects what the organisation did.

Frequently Asked Questions (FAQs)