Reporting a GDPR Data Breach: When, How, and to Whom

Data breach - now what?

An employee sends an Excel list with customer data to the wrong recipient. A laptop with an unencrypted hard drive is stolen from a car. A hacker gains access to the personnel database during a ransomware attack. Three completely different scenarios, but all three have one thing in common: A breach of the protection of personal data has occurred - colloquially, a data breach.

The DSGVO (GDPR) regulates in Articles 33 and 34 very precisely what must be done in such a case. The requirements are clear, the deadlines short, and the consequences for violations are severe. Yet uncertainty prevails in many companies: Do I have to report this? To whom do I report it? And what happens if I do not?

This article answers these questions systematically and practically. It is aimed at ISBs, IT managers, and executive directors who must act quickly and correctly in an emergency.

What is a data breach under GDPR?

Article 4 No. 12 DSGVO (GDPR) defines a breach of the protection of personal data as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

That sounds legal, but at its core it is simple: Whenever personal data is affected in a way that was not intended, it constitutes a data breach. GDPR distinguishes three categories:

Confidentiality breach

Unauthorized persons gain access to personal data. This is the most common form and includes:

• Hacking attacks with data exfiltration
• Accidental sending of data to wrong recipients
• Open access due to faulty permissions
• Data carriers that fall into the wrong hands (USB sticks, laptops, paper files)
• Employees accessing data they are not authorized for

Integrity breach

Personal data is altered without authorization. Examples:

• Manipulation of customer data by an attacker
• Faulty data migration where records are swapped or altered
• Ransomware that encrypts data (data is thereby altered)

Availability breach

Access to personal data is lost, temporarily or permanently:

• Ransomware attack encrypting systems with personal data
• Server failure without a functioning backup
• Accidental deletion of a database
• Fire or water damage in the server room

An important point often overlooked: Even a temporary loss of availability can be a notifiable data breach. If a hospital can no longer access patient data due to a ransomware attack, that is a data breach even if the data is restored after three days. Because during those three days, patients could potentially not be treated adequately.

When is a data breach notifiable?

Not every data breach must be reported to the supervisory authority. Article 33 GDPR formulates the threshold as follows: A notification is required unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

This means in reverse: As a rule, a data breach is notifiable. Non-notification is the exception and must be justifiable.

When is there no risk?

The European Data Protection Board (EDPB) has described scenarios in its guidelines where typically no risk exists:

Encrypted data without key compromise. If a laptop is stolen whose hard drive was protected with strong encryption and the encryption key was not compromised, the risk to affected individuals is low. The data is physically in the wrong hands but practically inaccessible.

Immediate and complete damage limitation. If an email with personal data goes to the wrong recipient, that recipient demonstrably deletes the email, and you can be certain they did not read or copy the data, the risk can be assessed as low. In practice, however, this certainty is hard to achieve.

Already public data. If the affected data is already publicly accessible (such as business addresses listed on the website), the risk from disclosure is lower than with confidential data.

When does a risk exist?

In practice, the question is rarely whether a risk exists but rather how high it is. A risk exists particularly in cases of:

• Identity theft: When name, address, date of birth, and ID number are affected
• Financial harm: When bank details, credit card information, or salary data has been disclosed
• Discrimination: When data about health, religion, ethnicity, or political convictions is affected
• Reputational damage: When confidential communications or compromising information has been disclosed
• Physical danger: When location data or addresses of vulnerable persons are affected

Practical examples: Notifiable or not?

The last point surprises many: The CC/BCC error in a newsletter is a classic data breach that regularly results in fines. Email addresses are personal data, and their disclosure to third parties is a confidentiality breach.

The 72-hour deadline: What exactly does that mean?

Article 33(1) GDPR prescribes that the notification must be made without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach.

When does the deadline start?

The deadline begins not at the time of the incident but at the time you become aware of it. If an attack took place on Friday but is only discovered on Monday, the 72-hour deadline starts on Monday.

Awareness here does not mean you already know all the details. It is sufficient that you know with reasonable certainty that a data breach has occurred. So the deadline does not start only when the forensic analysis is complete, but already when you have reasonable suspicion.

A concrete example: On Tuesday morning at 9:00 AM, your SIEM system reports a suspicious data outflow. At 10:30 AM, the initial analysis confirms that personal data is indeed affected. The 72-hour deadline starts at 10:30 AM and ends on Friday at 10:30 AM.

What if 72 hours are not enough?

GDPR provides that the notification can be supplemented even after 72 hours. Article 33(4) allows a phased notification when not all information is available simultaneously. You first report what you know and submit further details as they become available.

This is not a license to delay the notification. The initial notification must go out within 72 hours, even if incomplete. A late but complete notification is worse than a timely but incomplete one.

If you exceed the 72-hour deadline, you must justify it. Article 33(1) sentence 2 requires that a justification for the delay be included with a late notification. "We did not notice" is not an acceptable justification if you should have had adequate monitoring in place.

Weekends and holidays

The 72 hours run continuously; weekends and holidays are included. If you discover the data breach on Friday evening at 6:00 PM, the deadline ends on Monday evening at 6:00 PM. The supervisory authorities have online reporting forms accessible around the clock for exactly this situation.

This has practical consequences for your organization: There must be someone who is reachable even on weekends and has the authority to submit a notification. If your data protection officer is on vacation and nobody has been designated as a substitute, that is an organizational failure that the supervisory authority will view critically.

Content of the notification to the supervisory authority

Article 33(3) GDPR defines what information the notification must contain. Most supervisory authorities provide online forms that query these points. Still, you should know what is required so you can gather the information quickly in an emergency.

Mandatory elements of the notification

1. Description of the nature of the breach What happened? Confidentiality, integrity, or availability breach? When was the incident discovered? When did it presumably occur?

2. Categories and approximate number of affected individuals Which groups of persons are affected (customers, employees, applicants, patients)? How many persons are affected or potentially affected? An exact number is not required; a well-founded estimate suffices.

3. Categories and approximate number of affected data records Which data types are affected (name, address, email, health data, financial data)? How many records are affected?

4. Name and contact details of the data protection officer Or another contact point that can provide further information.

5. Description of the likely consequences What consequences does the data breach probably have for those affected? Risk of identity theft, financial harm, reputational damage?

6. Description of measures taken or proposed What has already been done to contain the data breach and minimize its impact? What further measures are planned?

How to report in practice

The notification is typically submitted via the online portal of the competent state supervisory authority. Which authority is competent depends on your company's registered office:

Most authorities have now standardized their reporting forms and offer step-by-step guidance through the required information. You do not need a legal opinion to submit a notification. Fill in the form, submit it, done. A quick, honest notification with gaps is better than a perfect notification after the deadline.

When must you inform the affected individuals?

Besides the notification to the supervisory authority (Article 33), there is a second obligation: informing the affected individuals under Article 34 GDPR. This obligation applies when the data breach is likely to result in a high risk to the rights and freedoms of natural persons.

High risk vs. risk

The threshold for notifying affected individuals is higher than for the notification to the supervisory authority:

A high risk typically exists in cases of:

• Disclosure of health data or data about criminal convictions
• Combination of data enabling identity theft (name + date of birth + ID number)
• Disclosure of financial data that can lead to immediate financial harm
• Data of particularly vulnerable persons (children, patients, asylum seekers)
• Large number of affected individuals combined with sensitive data

Exceptions to the notification obligation

Article 34(3) GDPR provides three exceptions where notification can be waived despite high risk:

Encryption or similar protective measures. If the data was protected by technical measures that make it inaccessible to unauthorized persons (such as strong encryption), notification is not required.

Subsequent measures that eliminate the high risk. If after the data breach you have taken measures that ensure the high risk to those affected no longer exists in all probability, notification can be waived. This is a high standard, however. "We changed the password" is not sufficient if the data has already been copied.

Disproportionate effort. If individual notification would require disproportionate effort, a public announcement can be made instead. This applies to cases where millions of persons are affected and no current contact data is available.

Content of the notification

The notification must be formulated in clear and simple language. Legal jargon or obscuring formulations are out of place. Affected individuals must understand what happened and what they can do.

The notification must contain:

• Description of the data breach in understandable language
• Name and contact details of the data protection officer
• Description of the likely consequences
• Description of countermeasures taken
• Concrete recommendations for what those affected can do themselves (change passwords, monitor account movements, block identity documents)

Practical example: Notification letter

A realistic notification letter following a database breach with customer data could be structured as follows:

Subject: Important security information about your customer account

Content:

• What happened (on [date] we discovered unauthorized access to our customer database)
• Which data is affected (name, email address, order history; no payment data)
• What we have done (access blocked, vulnerability fixed, authority notified, forensic investigation initiated)
• What you should do (change password if used elsewhere, be alert to suspicious emails)
• Where to get more information (data protection officer's contact details, FAQ page)

The tone is honest and factual, neither embellishing nor panic-inducing. Affected individuals deserve transparency and concrete recommendations for action, not PR platitudes.

Documentation obligation: even without reporting

Article 33(5) GDPR contains an obligation that is often overlooked in practice: Every breach of personal data protection must be documented - regardless of whether it is notifiable or not.

This documentation must include the facts relating to the breach, its effects, and the remedial action taken. The supervisory authority must be able to verify from this documentation whether you have correctly complied with the reporting obligation.

What must be documented

For every incident, whether notifiable or not, you should record the following information:

The justification for the decision against notification is particularly important. If the supervisory authority subsequently reviews and you cannot present a documented risk assessment, it will assume you violated the reporting obligation. Clean documentation with traceable justification protects you, even if the assessment is later evaluated differently.

The data breach register

In practice, a central register of all data breaches has proven effective, similar to the register of processing activities. This register can be maintained as a simple table or as a structured database in your ISMS tool. ISMS Lite maintains this register automatically and links each data breach with the associated measures and notifications. What matters is that it is complete, current, and accessible to the supervisory authority.

Maintain this register from the start, not only when the supervisory authority comes knocking. The effort is minimal, the benefit in case of an inspection is enormous.

Consequences of violations

GDPR provides severe fines for violations of the reporting obligation. Article 83(4)(a) allows fines of up to EUR 10 million or 2% of worldwide annual turnover for violations of the notification obligations under Articles 33 and 34.

In practice, fines in Germany have so far been more moderate but by no means trivial:

Beyond direct fines, further consequences threaten:

Orders by the supervisory authority. The authority can order concrete measures, such as subsequent notification of affected individuals or improvements to technical protective measures.

Damages claims. Affected individuals can claim damages under Article 82 GDPR, including for non-material damages. Robust technical and organizational measures (TOMs) reduce both the likelihood and the consequences of a data breach. Case law on damages claims for data breaches has increasingly developed in favor of affected individuals in recent years.

Reputational damage. Data breaches become publicly known, whether through the notification to affected individuals, media coverage, or the publication practices of some supervisory authorities. The loss of trust among customers and partners can weigh more heavily than the fine.

The relationship with NIS2

If your company falls under NIS2, you have a dual reporting obligation for a security incident involving personal data:

The NIS2 reporting deadline for the initial notification is shorter (24 vs. 72 hours) but has a different focus: It concerns the operational disruption and IT security, not specifically data protection. The GDPR notification focuses on personal data and the risks to affected individuals.

In practice, this means: For a ransomware attack that both disrupts operations and affects personal data, you report to the BSI within 24 hours (NIS2) and to the data protection supervisory authority within 72 hours (GDPR). These are two separate notifications to two different authorities with different content.

Prepare for this scenario. If in an emergency you first have to look up which authority has which form and what deadlines apply, you lose valuable hours. Have the contact details, reporting portals, and access credentials ready before you need them.

Practical examples: Three scenarios in detail

Scenario 1: The lost USB stick

What happened: A field sales representative loses a USB stick with an Excel list of 340 customer contacts (name, company, email, phone number, quote amounts).

Risk assessment: The USB stick is not encrypted. The data includes business contact information and quote information. A finder could read the data and use it for phishing or competitive espionage. Risk to affected individuals: present, but no high risk (no particularly sensitive data categories, no bank details).

Result: Notification to the supervisory authority within 72 hours: yes. Notification of affected individuals: no, as there is no high risk. Documentation: complete, including justification for non-notification. Immediate measure: Introduce encryption requirement for all USB sticks.

Scenario 2: Ransomware with data exfiltration

What happened: Ransomware encrypts the company's servers, including the personnel database with data of 85 employees (name, address, social security number, salary, bank details, sick notes) and the customer database with 12,000 records. The attackers threaten publication and have posted 50 records on the darknet as proof.

Risk assessment: Confirmed exfiltration of highly sensitive data. Social security numbers and bank details enable identity theft and financial fraud. Employee health data (sick notes) are special categories under Article 9. High risk for all affected individuals.

Result: Notification to the supervisory authority: yes, immediately. Notification of affected individuals: yes, without delay, both employees and customers. Concrete recommendations: Monitor bank accounts, request a credit report, be suspicious of unusual contacts. If NIS2-relevant: additionally initial report to the BSI within 24 hours.

Scenario 3: The misdirected email

What happened: An employee in the HR department accidentally sends a salary overview of all 60 employees in a department to an external applicant instead of to executive management.

Risk assessment: Salary data is confidential personal data. The disclosure to a third party poses a risk, as the recipient knows the data and could potentially share it. The employee contacts the applicant immediately by phone. The applicant confirms having deleted the email without opening it. The risk is thereby reduced but not fully eliminated, as there is no technical certainty.

Result: Notification to the supervisory authority: yes, as a risk cannot be ruled out. The notification can note that the recipient confirmed deletion. Notification of affected individuals: Borderline case. The supervisory authority can help with the decision on whether notification of the 60 employees is required. Documentation: complete, including evidence of the phone contact and deletion confirmation.

How to prepare yourself

The best preparation for a data breach is a process that takes effect before panic sets in. Five concrete measures you can implement now:

First: Define a reporting process. Who decides whether a data breach is notifiable? Who submits the notification? Who is the backup? The incident response plan should answer these questions. Write down the process with names, phone numbers, and login credentials for the reporting portals.

Second: Set up structured incident documentation. In an emergency, you need a clear workflow, not a blank page. ISMS Lite provides a structured incident workflow where you enter the concrete facts, deadlines are tracked automatically, and BSI-compliant reports can be generated.

Third: Create a risk assessment matrix. Define in advance which data categories carry which risk level. Customer data with bank details: high risk. Business email addresses: lower risk. This matrix significantly accelerates the decision in an emergency.

Fourth: Prepare notification templates. Create draft texts for notifying affected individuals. You will need to adapt them in an emergency, but the basic structure will already be in place. Formulating an understandable, legally correct notification text from scratch under time pressure is an unnecessary burden.

Fifth: Practice the process. Run through a scenario in a tabletop exercise. Friday evening, data leak discovered, data protection officer on vacation. Does the process work? Does the backup person know what to do? Do they have access to the reporting portal? Such exercises cost two hours and save two days of chaos in an emergency.

Further reading

• Detecting, assessing, and reporting a security incident - the complete process
• Creating a register of processing activities (RoPA) under Art. 30 GDPR
• Documenting technical and organizational measures (TOMs)
• NIS2 reporting deadlines overview: 24h, 72h, 1 month - what is due when
• Creating an incident response plan: Template and practical example

The GDPR reporting obligation is not a bureaucratic monster. It is a structured process with clear rules that works smoothly with good preparation. The key is not the perfect notification but the quick, honest, and documented response.