GDPR Data Breach Response Plan: A Comprehensive Guide

Recently, data breaches have become an expected operational risk for any organization that processes personal data, rather than a hypothetical event as once perceived. In 2025 alone, European data protection authorities received an average of 443 GDPR breach notifications every single day, marking a 22 % increase year-on-year as organizations grapple with more frequent and sophisticated incidents. Over the same period, regulators imposed more than €1.2 billion in GDPR fines, underscoring the exceptionally high stakes of poor breach handling.

The GDPR mandates a swift, structured, and well-coordinated response to personal data breaches — precisely because breaches unfold under pressure. Once an incident is detected, organizations are expected to assess risk quickly, contain and remediate the impact, determine notification obligations, document decisions, and coordinate legal, technical, and communications functions, often in parallel and within tight timeframes. And compliance is not achieved through a single action, but through the organization’s ability to manage the entire response process coherently from start to finish.

In reality, meeting these expectations during a live incident is rarely straightforward. Breach responses typically begin with incomplete information, evolving facts, and intense time pressure, while multiple teams are required to act simultaneously. Without a predefined structure to guide decision-making and accountability, responses can quickly become fragmented, inconsistent, and difficult to defend. A GDPR data breach response plan exists to address this gap by providing a clear, repeatable framework for preparing, documenting, and coordinating an effective response when an incident occurs.

Table of Contents

What Counts As a GDPR Data Breach?

Under the GDPR, not every technical problem or security incident rises to the level of a reportable breach. The key distinction lies in how the incident affects personal data.

What qualifies as a personal data breach under GDPR?

The GDPR defines a personal data breach as:

“a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.”

This definition is broad by design. It’s not limited to malicious hacking as it also captures internal mistakes, human error, system failures, and process breakdowns that affect personal data confidentiality, integrity, or availability. For example:

A lost laptop containing unencrypted customer records.
An employee emailing payroll data to the wrong distribution list.
A ransomware attack that encrypts critical personal data, making it unavailable.

The GDPR itself breaks down breaches into these three key categories:

Confidentiality breaches — unauthorized or accidental disclosure or access.
Integrity breaches — unauthorized or accidental alteration of data.
Availability breaches — loss of access or destruction of data.

It’s important to note that the GDPR applies this definition regardless of whether the incident is intentional or accidental, meaning a well-meaning employee mistake can be just as reportable as a sophisticated cyberattack.

Does Encrypted or Pseudonymised Data Still Count as a GDPR Breach?

Yes, both encrypted data and pseudonymised data remain personal data under GDPR, and incidents involving them can still be considered personal data breaches. However, how encryption and pseudonymisation influence breach handling and notification obligations differs based on risk and context.

Encrypted Data and GDPR: What the Rules Really Say

Under GDPR, encrypting personal data does not remove its status as personal data — the data is still subject to GDPR even when encrypted. The act of encryption counts as processing and does not cure a breach by itself.

What encryption does affect is the risk assessment under Articles 33 and 34:

If encrypted personal data is lost or accessed, it can still be a personal data breach because the data remains personal data in encrypted form.
However, if the data were encrypted using strong protections and the encryption keys were not compromised, then the data would likely remain unintelligible to unauthorized parties. This greatly reduces the risk to individuals’ rights and freedoms.
In that case, while the incident might still qualify as a breach that should be documented and possibly reported to the supervisory authority, controllers may be exempt from notifying affected individuals if they can demonstrate that the risk is negligible because of the encryption measures.

Pseudonymised Data — Still Personal Data

Pseudonymisation means transforming personal data so that it cannot be attributed to a specific individual without additional information, typically stored separately. GDPR explicitly recognises pseudonymisation as a security measure.

However, pseudonymised data is still personal data because:

Additional information exists that could link the pseudonymised data back to an individual.
Therefore, if that pseudonymised data is accidentally disclosed, accessed without authorization, or otherwise compromised, it still satisfies GDPR’s definition of a personal data breach.

Unlike encryption, pseudonymisation doesn’t make the data unintelligible; it just makes direct identification harder. So while pseudonymisation can reduce the potential impact or aid risk assessment, it does not exclude the data from GDPR or automatically exempt breach notification. In fact, in most cases, notification to authorities is required.

What Doesn’t Count as a GDPR Personal Data Breach

a) Security Incidents That Don’t Affect Personal Data

If an incident doesn’t involve personal data at all, it isn’t a GDPR breach — even if it’s a serious IT issue. For example, a network anomaly or outage that does not impact personal data stored or processed by the organization would not qualify as a personal data breach because the GDPR definition requires that personal data is actually affected.

b) Incidents Involving Only Non-Personal Data

Data that does not qualify as personal data under GDPR, such as truly anonymised data or data about deceased individuals, is outside the scope of personal data breach rules.

Under GDPR, only information relating to an identified or identifiable natural person is protected. Data that is truly anonymised, such that no reasonable means exist to re-identify a person, is not personal data and therefore won’t trigger breach requirements.

In the UK context Post-Brexit, data relating exclusively to deceased persons is not considered personal data, and incidents affecting only such data are not subject to Articles 33 or 34. However, the UK Data Protection Act 2018 allows for limited, sector-specific rules concerning deceased persons’ data, such as in the context of coronial functions or fraud prevention

Also, ICO guidance notes indirect impacts, where processing deceased data might involve living relatives’ personal data, such as family contacts, triggering UK GDPR if risks to them arise.

Understanding the GDPR 72-Hour Breach Notification Rule

The GDPR imposes one of the most stringent breach reporting timelines in global data protection law. Article 33 of the Regulation requires organizations to notify the relevant supervisory authority “without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach.”

When does the 72-hour period start?

Under Article 33, the obligation to notify a personal data breach to the supervisory authority must be fulfilled within 72 hours of “becoming aware” of the breach — not when the breach actually occurred.

“…not later than 72 hours after having become aware of it…” (GDPR Article 33).

What does “becoming aware” of a breach mean?

Regulatory guidance from the European Data Protection Board (EDPB) and authorities clarifies that awareness doesn’t mean mere suspicion. The 72-hour clock starts when the organization has a reasonable degree of certainty that:

A security incident has occurred, and
It has led to personal data being compromised.

In practice, “becoming aware” could occur when any of the following happens:

The security team confirms that personal data was accessed or exposed.
A third party or processor notifies you with evidence that data has been compromised.
There is direct evidence of a breach affecting personal data (for example, system logs showing unauthorized access).

Importantly, identifying the breach and knowing its full scope are different — you don’t need full details to start the clock, just reasonable certainty that personal data has been compromised.

For organizations that outsource processing, it’s important to note that the 72-hour deadline applies to the controller, not the processor. This means the controller’s awareness — often triggered when it receives the processor’s notification of a breach — starts the countdown.

Also, the GDPR anticipates that organizations will need to investigate a potential breach before they can confirm it and therefore become “aware.” EDPB guidance makes clear that this initial assessment period does not count as part of the 72 hours — the timer only starts once the controller has a reasonable degree of certainty about a breach.

Can organisations notify regulators without full details?

Yes — and the regulation explicitly allows this.

Article 33 recognises that at 72 hours, you sometimes won’t have all the information. In those cases:

You must still notify within the 72-hour window with the information you do have.
Any remaining details can then be provided in phases as they become available, without undue further delay.

This phased approach is expressed in the GDPR text and reinforced in regulator guidance, especially for complex breaches, such as cybersecurity incidents requiring deep forensic investigation.

Your initial notification should still try to include as much as possible — for example, the nature of the breach, categories/number of affected data subjects, likely consequences, and mitigation measures.

What happens if the 72-hour deadline is missed?

If a controller doesn’t notify within 72 hours:

The notification can still be submitted late, but it must be accompanied by reasons for the delay in accordance with Article 33(1).
Regulators will scrutinise those reasons in enforcement actions and may consider non-compliance with the timeframe as part of their assessment.
Documentation explaining the delay becomes a critical part of demonstrating compliance — or the lack thereof — under GDPR.

A missed deadline doesn’t instantly mean a fine — but failure to justify the delay or repeated delays without adequate cause can be taken very seriously by data protection authorities.

What to Do in the First 24 Hours After a GDPR Data Breach

Responding effectively in the first 24 hours after discovering a data breach is crucial for compliance, mitigation, and demonstrating accountability under GDPR. What you do (and don’t do) early on can significantly influence the overall impact of the breach and your ability to meet regulatory obligations. So, what Are the Immediate Steps After Discovering a Data Breach?

1. Confirm and Trigger Your Response Process (Right Away)

As soon as there’s a reasonable indication of a breach, activate your breach response process.

If you have a formal incident response plan, follow it.
If you don’t, appoint a responsible lead (e.g., DPO or senior manager) and bring together essential internal responders such as IT/security and legal.

You must start documenting the moment the breach is identified — write down what happened, when it was discovered, who first noticed it, and what you know so far. Regulators expect contemporaneous records.

2. Contain the Breach to Stop Further Damage

Prevent the incident from spreading or more data from being exposed.

Immediate containment actions include:

Isolating affected systems — disconnect them from the network to stop attackers or ongoing leakage.
Revoking compromised credentials — reset passwords and disable any accounts that may have been misused.
Stopping unauthorized transfers of data — halt scripts, exports, or external connections that are moving information.
Protecting physical devices — if a laptop or device is lost or stolen, trigger remote-wipe or lock functions if available.

Containment doesn’t mean full recovery — it means stop the bleeding first.

3. Preserve Evidence for Investigation (Simultaneously)

Why this matters: Evidence is vital for forensic analysis, GDPR compliance documentation, and, if necessary, legal defense. Do not destroy it.

To preserve evidence, you can take actions such as:

Securing system logs (firewalls, servers, intrusion detection, etc.).
Taking forensic images of affected systems — this ensures a snapshot is available before restoration.
Capturing timeline data — timestamps, alerts, and notes about discovery and containment steps.
Avoiding reckless restoration — do not reboot systems or overwrite logs before imaging them.

Why you preserve before restoring: Random Access Memory (RAM) and live system state contain critical clues about the breach — shutting down now can erase valuable evidence.

4. Conduct a Rapid Impact Assessment (Within First Few Hours)

You need to understand, even if only preliminarily:

What type of personal data was affected (e.g., contact details, financial information).
How many individuals might be impacted.
Whether the data was encrypted or accessible.
Whether personal data rights and freedoms may be at risk.

This assessment informs whether the breach is likely to result in risk — a key threshold for whether you must notify the supervisory authority and/or data subjects.

5. Notify Internal Stakeholders Immediately

Internal notification prevents confusion and speeds coordinated response:

IT/Security team — manage containment and investigation.
Legal/Compliance team — advise on GDPR obligations and risk.
Data Protection Officer (if you have one) — oversee GDPR reporting and documentation.
Senior leadership — for strategic decisions and communication support.

Getting everyone aligned early avoids duplicated work and ensures critical decisions (like interim containment measures) aren’t delayed.

6. Start Your Compliance Documentation Log

As you act, keep a detailed breach log as regulators will expect this:

Date/time of discovery
Who discovered it and how
Actions taken (containment, evidence preservation)
Initial assessment results
Decisions made and by whom

Even if you end up not reporting to authorities (because the risk is low), you must document your assessment and reasoning. This is often a decisive factor in regulatory review.

Avoid These Common Early Mistakes

In the heat of the moment, some actions can harm your case:

Do not delete logs or evidence — this can destroy the forensic trail.
Do not shut down systems before imaging — RAM and live state may be lost forever.
Do not communicate externally prematurely — uncoordinated statements can mislead and cause reputational harm.
Do not assume encryption always eliminates risk — encrypted data may still require regulatory and subject assessment.

How to Assess Risk to Individuals Under GDPR

Not every personal data breach automatically triggers notifications to individuals. Under the GDPR, risk assessment is core to determining whether you must notify the supervisory authority and affected data subjects. The key legal trigger is whether the breach is likely to result in a risk to the rights and freedoms of individuals, and for data subject notification, a high risk.

What Does “Risk to the Rights and Freedoms of Individuals” Mean?

As per the GDPR, risk to rights and freedoms isn’t limited to privacy in a narrow sense — it covers any physical, material, or non-material harm that a person could suffer because of a breach. This includes:

Loss of control over personal data
Identity theft or fraud
Financial loss
Damage to reputation
Discrimination
Loss of confidentiality (e.g., sensitive medical or professional information)
Social or economic disadvantage
Any limitation on a person’s ability to exercise their rights under GDPR

In other words, the focus is on concrete harm to individuals — not just an abstract security incident.

What Factors Determine Whether a Breach Is High Risk?

Regulators (and GDPR guidelines) emphasise that risk assessment must be objective and contextual — meaning you must consider both how likely harm is and how severe it would be if it occurred.

Here are the key factors to evaluate:

1. Nature of the Personal Data

The nature of the personal data involved is often the starting point for risk assessment. Data that reveals particularly sensitive aspects of an individual’s life, such as health information, genetic and biometric data, political opinions, religious beliefs, or sexual orientation, almost always elevates risk because misuse or exposure can lead to serious and lasting harm.

Also, certain categories of “ordinary” personal data can still present a high risk depending on how they may be exploited. Financial information, government-issued identification numbers, authentication credentials, location data, or employment records can enable identity theft, fraud, or account compromise. Where the data could realistically be used to cause financial loss, discrimination, reputational damage, or loss of confidentiality, the risk assessment must reflect that potential, regardless of whether the data falls into a special category.

2. Type of Breach

The type of breach plays a significant role, but regulators caution against relying on technical classifications alone. Confidentiality breaches – where personal data is accessed, disclosed, or exfiltrated by unauthorized parties — are often treated as more serious because they directly expose individuals to misuse of their data.

That said, integrity and availability breaches can also result in high risk where they have tangible consequences for individuals. For example, the unauthorized alteration of medical records or the loss of access to essential services due to ransomware may prevent individuals from exercising their rights or receiving critical care. Regulators, therefore, focus less on whether a breach is one of confidentiality, integrity, or availability, and more on the actual or foreseeable impact on individuals.

3. Volume and Sensitivity of Data

The scale of a breach influences risk because a higher volume of affected records increases the number of individuals potentially harmed. Large-scale incidents often attract heightened regulatory scrutiny due to their broader societal impact.

However, volume alone is not determinative. Regulators repeatedly emphasise that a breach affecting a small number of individuals may still be considered high risk if the data involved is particularly sensitive or easily exploitable. For instance, the exposure of a handful of detailed health records or financial credentials may pose greater harm than a much larger breach involving only names and generic contact details. Risk assessment must therefore consider volume alongside the sensitivity and misuse potential of the data.

4. Ease of Identification

Risk increases significantly where individuals can be identified from the compromised data, either directly through identifiers such as names or identification numbers, or indirectly through combinations of data points. Pseudonymised data remains personal data, and the risk remains high where re-identification is realistically possible using additional information, data matching, or contextual knowledge.

Conversely, where data has been effectively anonymised, and individuals cannot reasonably be identified, the likelihood of harm is reduced. Here, you assess not just theoretical identifiability, but whether identification is plausible in practice, taking into account who accessed the data and what other information they may have.

5. Severity of Potential Harm

When assessing risk, you need to focus on realistic and foreseeable consequences, rather than abstract or speculative concerns. The more serious, irreversible, or long-lasting the potential harm, the more likely the breach will be classified as high risk.

Potential harms include, but are not limited to, financial loss, identity theft, discrimination, reputational damage, emotional distress, loss of confidentiality, and physical harm in extreme cases. Where harm could persist over time or be difficult for individuals to mitigate, authorities are more likely to view the breach as posing a high risk to rights and freedoms.

6. Special Characteristics of Individuals

The characteristics of the affected individuals are a critical part of the risk assessment. Breaches involving vulnerable data subjects, such as children, elderly individuals, patients, employees in dependent relationships, or individuals in precarious social or economic situations, are inherently riskier.

These individuals may have a reduced ability to detect misuse, assert their rights, or take protective action. Regulators, therefore, give particular weight to vulnerability when assessing whether a breach is likely to result in high risk, even where the data involved might otherwise appear limited.

7. Special Characteristics of the Controller or Context

Finally, the broader processing context must be considered. Certain sectors, including healthcare, financial services, education, telecommunications, and public services, routinely process data where misuse can have especially severe consequences. A breach in these environments is more likely to result in high risk than an equivalent incident in a lower-risk context.

The controller’s role and responsibilities, the purpose of processing, and the expectations of individuals are also considered. Where individuals reasonably expect a high level of confidentiality, such as in medical, legal, or social care contexts, any breach is more likely to be viewed as serious, even if the technical details appear similar to breaches in other sectors.

High Risk Threshold vs. General Risk

Under Article 33, you notify the supervisory authority if a breach is likely to result in risk to rights and freedoms.
Under Article 34, you notify individuals themselves only if it is likely to result in high risk.

High risk means that harm is more probable, more severe, or both — such that individuals need to be informed so they can protect themselves (e.g., cancel cards, change accounts).

When and How to Notify Supervisory Authorities Under GDPR

Under Article 33 of the GDPR, controllers must notify the competent supervisory authority about a personal data breach without undue delay and — where feasible — within 72 hours of becoming aware of it. This obligation applies only when the breach is likely to result in a risk to the rights and freedoms of individuals.

Which Supervisory Authority Should Be Notified?

The GDPR requires that the breach be reported to the competent supervisory authority under Article 55. In practice, this means notifying the authority in the EU Member State where the controller (or its main establishment) is established.

For organisations operating in cross-border contexts, the lead supervisory authority may be one of the controller’s main establishments in the EU. This is coordinated under the one-stop-shop mechanism in Articles 56–60 of the GDPR, which helps determine which authority acts when processing spans several Member States.

In simple terms:

If your organisation has a single establishment in one Member State, notify that state’s authority.
If processing occurs across multiple Member States, you may need to notify the lead authority under the one-stop-shop rules.

What Information Must Be Included in a GDPR Breach Notification?

Article 33 sets out the minimum content that must be provided in a breach notification to the supervisory authority. If any element listed below is not available at the time of the initial notification, the GDPR allows you to send it in phases without undue further delay.

At a minimum, the notification must include:

Description of the breach: A clear description of the nature of the personal data breach, including — where possible — the categories and approximate number of affected data subjects and the categories and number of personal data records concerned.
Contact information: The name and contact details of your Data Protection Officer (DPO) or another contact point where the supervisory authority can request more information.
Likely consequences: A description of the likely consequences of the breach for the affected individuals. This is about the potential impact on data subjects’ rights and freedoms.
Measures taken or proposed: Details of the actions already taken and planned to address and mitigate the breach, including efforts to contain it and reduce its adverse effects.

If you cannot provide full details within 72 hours, you may send partial information initially and follow up as more becomes available, provided you do so without undue further delay.

Can Breach Notifications Be Updated After Submission?

Yes. The GDPR explicitly allows breach notifications to be submitted in phases. This means:

You can send the initial notification within the 72-hour deadline with what you do know at that time.
You can then send updates later as new information becomes available — for example, refined estimates of affected individuals, a clearer description of consequences, or additional mitigation measures.

Practical guidance states that if a form or portal requires a single submission, you can often submit an updated form or supplemental information with a clear reference to the original notification and, where provided, the authority’s reference number.

For example, the Irish Data Protection Commission advises including “Updated Breach Report” in the subject line and the original reference number when submitting supplemental information.

Should Organizations Notify Regulators if the Risk Is Low?

GDPR Article 33(1) sets the rule clearly:

“In the case of a personal data breach, the controller shall … notify … to the supervisory authority … unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.”

This wording creates a risk-based obligation, whereby notification is required only if the breach is likely to result in a risk to individuals’ rights and freedoms.

So the regulation itself directly builds in a threshold, stating that you do not automatically notify for every personal data breach. The controller must assess likelihood and risk, and only if there’s a risk to rights and freedoms is the breach reportable under Article 33.

However, Article 33 doesn’t stop with the exception — it goes on to say:

“The controller shall document any personal data breaches … That documentation shall enable the supervisory authority to verify compliance with this Article.”

This means that whether you notify or not, you must maintain a breach log that includes:

The facts of the breach
The effects of the breach
The remedial actions taken

Importantly, your documentation must also include your risk assessment and rationale, including why you concluded the breach was unlikely to result in risk to the rights and freedoms of individuals. This documentation is expected to be sufficiently detailed to allow the authorities to verify that your decision not to notify was justified.

When Must Data Subjects Be Notified of a GDPR Data Breach?

GDPR sets out two separate notification duties:

Notification to the supervisory authority (Article 33).
Notification to affected data subjects (Article 34)

When Is Notification to Affected Data Subjects Required?

Under GDPR Article 34(1), “when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.”

This means that not all breaches must be communicated to people whose data was affected — only those where a high risk exists. This threshold is higher than the threshold for notifying authorities (which is any risk, even a moderate one).

The purpose of this requirement is to enable individuals to take steps to protect themselves, such as changing passwords or monitoring accounts, if the breach could lead to significant adverse effects.

What Information Must Be Included in a Data Subject Notification?

Article 34(2) states that the communication to data subjects must be in clear and plain language and include at least the information and measures referred to in points (b), (c), and (d) of Article 33(3).

This means you must tell affected individuals:

A brief description of the nature of the breach, written in non-technical, understandable language so that people can grasp what happened.
Contact details of a contact point — typically the Data Protection Officer (DPO) or another responsible person — so individuals can obtain further information.
The likely consequences of the breach, meaning what risk it could pose to them, based on the controller’s risk assessment.
Measures taken or planned by the controller to address and mitigate the breach, including guidance on what individuals can do to protect themselves.

These requirements ensure that individuals are not only informed that a breach occurred but also understand its practical implications and how to respond.

Are There Exceptions to Notifying Data Subjects?

Yes — GDPR Article 34(3) explicitly sets out three limited exceptions where data subject notification is not required, even where a breach might otherwise trigger it:

Appropriate technical and organisational measures were in place and applied to the affected data — for example, strong encryption that renders the data unintelligible to unauthorised persons.
Subsequent measures taken immediately after the breach eliminate the high risk to data subjects so that it is no longer likely to materialise.
Disproportionate effort — where contacting each individual would involve a disproportionate effort (e.g., contact details are unknown or lost). In such cases, a public communication or similar measure that effectively informs affected people may be required instead.

These exceptions are not automatic. The controller must be able to demonstrate to the supervisory authority why an exception applies if they choose not to notify individuals.

How Quickly Must Individuals Be Informed of a Breach?

GDPR does not specify a numerical deadline like the 72-hour rule for supervisory authority notifications. For data subjects, the standard is:

“Without undue delay” — meaning as soon as reasonably possible once the controller has determined that the breach is likely to result in high risk and has gathered enough information to communicate accurately.

Regulators and guidelines interpret “without undue delay” as requiring prompt action, for example, after a short, reasonable investigation to understand the scope and impact. Unnecessary internal delays, like waiting for legal sign-off at the expense of meaningful threat response, are not acceptable.

If complete details are not yet available, controllers can (and should) send initial communication with the information they do have and follow up later with updates. This approach aligns with regulatory emphasis on timeliness balanced with accuracy.

Roles and Responsibilities in a GDPR Data Breach Response

Effective breach response isn’t just about technology — it’s about clear roles, shared responsibilities, and compliance with specific GDPR obligations. The following sections outline who is responsible for what, based on regulatory practice and the GDPR itself.

Who Is Responsible for Managing a GDPR Data Breach?

The data controller is the party legally responsible for managing a GDPR data breach.

Under Article 4(7) and Articles 33–34 GDPR, the controller determines:

Why personal data is processed, and
How that processing takes place

Because of this decision-making power, the controller bears ultimate accountability when a breach occurs.

The controller’s core breach responsibilities include:

Assessing whether a personal data breach has occurred
Determining the risk to individuals’ rights and freedoms
Deciding whether the breach must be:
- Reported to the supervisory authority (within 72 hours), and/or
- Communicated to affected data subjects
Ensuring accurate documentation of the breach and response actions
Coordinating remediation measures to limit harm and prevent recurrence

Even if another party caused the breach, regulators will look first to the controller.

Where two or more organizations act as joint controllers, responsibility for breach management is shared.

Joint controllers must:

Clearly allocate breach-response roles in their Article 26 arrangement
Ensure there is no gap in:
- Detection
- Notification
- Communication with regulators and data subjects

It’s important to note that data subjects and regulators are not bound by internal agreements. Any joint controller may still be held fully liable if obligations are not met.

What Is the Role of the Data Protection Officer During a Breach?

The Data Protection Officer (DPO) plays a central, advisory, and compliance-focused role in a GDPR breach response.

Under GDPR Articles 37–39 and regulatory guidance, the DPO’s primary breach-related responsibilities include:

Providing expert advice on GDPR obligations during a breach, for example, assessing whether notification thresholds have been met.
Monitoring compliance with GDPR before, during, and after the incident, including data protection principles and internal policies.
Advising on and reviewing breach documentation and risk assessments.
Serving as the contact point for supervisory authorities during communication about the breach, and often as a contact for affected individuals where appropriate.
Coordinating with internal stakeholders (IT, security, legal, executive leadership) to ensure that response actions are GDPR-aligned.

Regulators also expect the DPO to have independent access to management, sufficient resources, and involvement in all relevant decisions to ensure effective breach handling.

What Are the Responsibilities of Data Processors in a Breach?

Data processors, such as vendors, service providers, or cloud hosts, do not carry primary responsibility, but still have clear legal obligations during a breach.

Processors must:

Notify the controller without undue delay after becoming aware of a breach (Article 33(2))
Provide all relevant information needed for the controller’s risk assessment
Assist the controller with:
- Breach investigation
- Regulatory notifications
- Remedial and containment measures

Processors cannot decide whether a breach is reportable. That decision always rests with the controller.

However, processors can still face direct GDPR liability if the breach results from failing to meet their own security or contractual obligations.

How to Document a GDPR Data Breach for Regulatory Compliance

GDPR also requires organizations to document data breaches in a way that demonstrates accountability and compliance with the Regulation’s breach-handling obligations. Documentation is a foundational compliance obligation under GDPR, and regulators can demand access to breach records at any time to verify whether a controller met its legal duties.

What Breach Records Does GDPR Require Organizations to Keep?

Under Article 33(5) of the GDPR, organizations are required to maintain internal records of all personal data breaches, including those that do not require notification to a supervisory authority or to affected individuals. These records must be sufficiently detailed to allow regulators to verify compliance with the GDPR’s breach response obligations.

Article 33(5) states that:

“The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.”

In practice, regulators and guidance emphasize three core points:

First, documentation must cover every personal data breach the controller becomes aware of, regardless of whether it was notifiable.
Second, the purpose of breach records is not merely internal tracking, but to demonstrate compliance with Articles 33 and 34 if reviewed by a supervisory authority.
Third, controllers are expected to maintain an internal breach register as part of their broader accountability and record-keeping obligations.

At a minimum, breach records should capture the facts of the incident, the assessed effects on individuals, and the remedial actions taken. Regulators further encourage recording contextual details such as the cause of the breach, the scope and duration of the incident, the categories and volume of personal data affected, and the reasoning behind notification decisions, as this information helps demonstrate compliance in context.

How Detailed Should Breach Documentation Be?

The GDPR doesn’t prescribe a specific template, but both the law and regulatory guidance stress that documentation must be detailed enough to allow effective verification by a supervisory authority.

In practice, recommended documentation includes:

Facts and circumstances of the breach — what happened, when, and how.
Scope and impact, including the personal data affected and categories of individuals involved.
Consequences — both actual and potential impacts on data subjects, including risks identified.
Remedial actions taken — steps to contain the breach and mitigate effects.
Decisions made and rationale — especially if the breach was not reported to the authority or to data subjects.

EDPB guidance underlines that controllers should also record the reasoning behind their decisions, particularly when concluding that a breach does not require notification because it was unlikely to result in a risk to rights and freedoms.

So basically, the documentation should not just be a chronology of events — it should reflect the decision-making process under GDPR and show how risk thresholds were evaluated.

How Long Should GDPR Breach Records Be Retained?

The GDPR does not specify a fixed retention period for breach documentation. The law simply states that controllers must retain records sufficient to demonstrate compliance with Article 33.

Regulatory guidance, including breach notification guidelines issued by the former Article 29 Working Party and endorsed by the European Data Protection Board, clarifies further:

Where breach records themselves contain personal data, retention must comply with general data-processing principles (e.g., storage limitation and lawful basis for processing).
If records do not contain personal data, the GDPR’s storage limitation principles may not apply directly, but retention should still support accountability.
Many controllers choose a defined policy, like retaining for a set number of years, based on organizational risk, legal obligations, or potential litigation, because regulators can request these records during an investigation.

In most cases, organizations typically retain breach documentation at least until the statute of limitations for regulatory review or litigation has passed, and often longer (e.g., several years).

What Happens After a GDPR Data Breach? Remediation and Lessons Learned

After the immediate response to a personal data breach — containing the incident, notifying authorities/individuals if required, and documenting the event — regulators and best-practice frameworks expect organizations to transition to remediation, review, and improvement. This phase is part of the GDPR’s accountability and continuous compliance mandate. Below are the steps organizations should take after the emergency has passed;

1. Conduct a Structured Post-Incident Review

The first corrective step is a formal post-breach assessment, sometimes called a post-incident review or lessons-learned exercise.

This review should:

Reconstruct how and why the breach occurred
Identify technical, organizational, and human factors
Examine whether existing safeguards functioned as intended
Assess whether detection and escalation processes were timely

Under Articles 5(2) and 24 GDPR, this analysis supports the controller’s obligation to demonstrate accountability and appropriate organizational measures. The review should be evidence-based, using logs, audit trails, incident reports, and internal records—not assumptions or hypothetical risks.

2. Remediate the Root Causes (Not Just the Symptoms)

Corrective action must address the underlying causes of the breach, not merely the exposed system or dataset.

Depending on the findings, remediation may include:

Closing configuration gaps or misconfigurations
Strengthening access controls or privilege management
Fixing flawed data flows or insecure integrations
Replacing or hardening legacy systems
Improving vendor or sub-processor controls

From a GDPR perspective, this aligns with Article 32, which requires security measures to be appropriate in light of the risks revealed by real incidents. Regulators expect remediation to be risk-driven and proportionate, not cosmetic.

3. Update Technical and Organisational Measures (TOMs)

After a breach, existing Technical and Organisational Measures should be reassessed and updated where necessary.

This may involve:

Revising encryption, pseudonymisation, or backup strategies
Enhancing monitoring, logging, and alerting capabilities
Adjusting access policies, authentication mechanisms, or segregation of duties
Strengthening internal approval or change-management controls

Note that while GDPR does not require “maximum security,” it does require that controls evolve when weaknesses are exposed. Failing to adjust TOMs after a known breach can itself become a compliance issue.

4. Review and Improve Policies, Procedures, and Playbooks

A breach often reveals gaps in process, not just technology.

Organizations should review:

Incident response plans and escalation paths
Internal breach detection and reporting procedures
Roles and responsibilities during incidents
Decision-making workflows for notifications and communications

Policies should be:

Updated to reflect what actually works in practice
Aligned with real response timelines and resource constraints
Clearly communicated to relevant teams

This supports compliance with Articles 24 and 33, which assume that controllers have operationally effective procedures, not just written ones.

5. Strengthen Training and Awareness Where Needed

If human error, misjudgment, or lack of awareness contributed to the breach, corrective action should include targeted training.

This may involve:

Refresher training on data handling and security practices
Role-specific guidance for IT, HR, legal, or customer-facing staff
Scenario-based breach response exercises
Reinforcement of internal reporting obligations

Under GDPR, training is a recognized organizational safeguard, particularly where people are a meaningful risk factor.

6. Reassess Third Parties and Contracts

Where processors, cloud providers, or other third parties were involved, the post-breach phase should include a vendor reassessment.

This can include:

Reviewing whether contractual breach obligations were met
Evaluating the adequacy of processor security measures
Updating Article 28 agreements or SLAs
Reconsidering sub-processor approvals or oversight mechanisms

If a vendor materially failed to meet GDPR expectations, corrective action may extend to changing providers or limiting processing scope.

7. Update Risk Assessments and DPIAs

A real breach provides new empirical risk information.

Organizations should:

Update internal risk registers
Revisit relevant Data Protection Impact Assessments (DPIAs)
Adjust likelihood and severity assessments based on the incident

Where a breach reveals high residual risk, GDPR may require additional safeguards or—even in some cases—consultation with a supervisory authority for future processing.

8. Close the Accountability Loop Through Documentation

Finally, all corrective actions must be documented.

This includes:

Findings from the post-incident review
Decisions taken and justifications
Remediation steps and timelines
Policy, technical, or contractual changes made

This documentation is essential to:

Demonstrate compliance during audits or investigations
Respond to follow-up regulator inquiries
Show that the organization learned from the breach

Under GDPR, what you fix matters—but so does your ability to prove that you fixed it.

Crafting an Effective GDPR Data Breach Response Plan

At this point, the legal and procedural requirements of a GDPR data breach response are already clear. What remains is a practical question regulators often examine after the fact: was the organization structurally prepared to respond, or did it improvise under pressure?

A GDPR breach response plan is not about restating the law. It is about demonstrating accountability — the ability to translate legal obligations into a coordinated, timely, and defensible response when a real incident occurs.

What a GDPR Breach Response Plan Is Meant to Achieve

Regulators do not expect a breach response plan to prevent all incidents. Instead, they view it as evidence that the organization can:

recognise a breach promptly,
make informed risk decisions quickly,
involve the right people without delay,
and document actions in a structured way.

In enforcement actions, the absence of a plan — or the presence of one that was clearly unusable in practice — is often treated as a sign of poor organizational measures under Articles 24 and 32, even where the breach itself was not intentional.

How Detailed a Breach Response Plan Needs to Be

GDPR does not prescribe a specific format or level of detail. What matters is functional clarity, not volume.

An effective plan typically:

defines who is empowered to declare a breach and start the response clock,
establishes escalation paths so decisions are not stalled,
links operational actions (containment, investigation, documentation) to compliance obligations (risk assessment, notification thresholds),
and ensures evidence preservation and record-keeping happen by default, not as an afterthought.

Plans that merely list GDPR articles or high-level principles, without showing how decisions are actually made during an incident, provide little regulatory value.

Testing and Maintaining the Plan in Practice

From a regulatory perspective, an untested plan carries limited weight. Authorities frequently assess whether a plan was known, accessible, and usable at the time of the breach.

Regular testing — through tabletop exercises or simulated incidents — serves two purposes:

it exposes gaps in role clarity, timing, or communication before a real breach occurs, and
it demonstrates that the organization treats breach readiness as an ongoing governance issue rather than a static compliance document.

Failure to test often explains why controllers miss deadlines, notify inconsistently, or struggle to justify early risk decisions.

Why Templates Alone Are Not Enough

Templates can be a helpful starting point, but regulators are clear that accountability cannot be outsourced. A plan must reflect:

the organization’s actual systems and data flows,
its internal decision-making structure,
and the realistic availability of staff during an incident.

In enforcement cases, generic plans that were never adapted to the organisation’s environment are often treated as if no plan existed at all.

How Smaller Organizations Can Approach Breach Readiness

GDPR does not apply different legal standards based on company size, but regulators do consider proportionality. Smaller businesses are not expected to have complex response teams or extensive documentation frameworks.

What they are expected to have is:

a clear breach decision owner,
a basic but reliable process for containment, assessment, and documentation,
and the ability to demonstrate that they understood and applied GDPR requirements in context.

In reality, a concise, well-understood response process often performs better than an elaborate plan no one knows how to use.

Conclusion

A GDPR data breach response is not judged by how well an organization explains the law after the fact, but by how quickly, coherently, and defensibly it acts when something goes wrong. European regulators mostly focus on awareness, decision-making, documentation, and proportionality, rather than perfection.

Organizations that understand what constitutes a breach, assess risk objectively, meet notification obligations, and maintain clear records are far better positioned to limit harm to individuals and scrutiny from authorities. And practically speaking, GDPR compliance during a breach is less about rigid checklists and more about demonstrating accountability through informed, timely action.

A well-executed response will not undo a breach — but it can decisively shape its legal, regulatory, and reputational outcome.