Data Breach Reporting Under GDPR: 72-Hour Notification

A personal data breach is any security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The definition in Article 4(12) of the GDPR is broad on purpose. A hacker stealing a customer database, a developer sending an Excel file to the wrong client, ransomware encrypting your server, a stolen laptop with unencrypted records, an internal employee snooping on records they had no business reason to access. All of these are personal data breaches.

The 72-hour notification deadline in Article 33 GDPR is one of the most under-prepared obligations small businesses face. The clock starts the moment the controller becomes aware of the incident. Awareness is interpreted strictly: an unconfirmed report of "something looks wrong" is not awareness, but a confirmed sign that personal data was compromised is. The European Data Protection Board (EDPB) Guidelines 9/2022 on personal data breach notification under the GDPR set out the operational details.

This guide covers the decision flow under Articles 33 and 34, what the supervisory authority needs in the notification form, when the additional obligation to communicate to individuals is triggered, and the practical preparation that small organisations can do today so that the clock does not catch them flat-footed.

The two-tier obligation

GDPR sets two separate but related obligations for personal data breaches.

The third row is the one most often forgotten. Even when a breach does not need to be notified to the supervisory authority because the risk is unlikely, the controller must still document it internally with sufficient detail to allow the supervisory authority to verify compliance if asked.

What counts as a personal data breach

Three categories of compromise, from Article 4(12) GDPR:

• Confidentiality breach: unauthorised or accidental disclosure of, or access to, personal data. Wrong-recipient emails, hacks, unauthorised internal access, lost documents fall here.
• Integrity breach: unauthorised or accidental alteration of personal data. Ransomware that encrypts data fits here when it also disrupts integrity; so does any unauthorised modification.
• Availability breach: accidental or unlawful destruction or loss of access to personal data. Disk failures without backups, deleted records, ransomware blocking access fit here.

A single incident often triggers two or three categories simultaneously. A ransomware attack typically affects availability and integrity, and may affect confidentiality if exfiltration is suspected.

The 72-hour clock: when it starts

The clock starts at the moment of awareness, not at the moment the incident occurred. The EDPB Guidelines 9/2022 define awareness as the controller having a reasonable degree of certainty that a security incident has occurred and that it has led to personal data being compromised.

Practical implications:

• A short investigation period to confirm whether an incident actually involves personal data is allowed. Hours, not days.
• The 72 hours run continuously, including weekends and public holidays.
• If the incident is detected at 17:30 on Friday, the deadline is 17:30 on Monday, not the start of the next working week.
• Awareness can come from any source: an internal monitoring alert, an external researcher, a customer complaint, a processor reporting up to the controller.
• A processor must notify the controller without undue delay under Article 33(2); the 72-hour clock for the controller starts on the controller's awareness, which is when the processor's notification arrives.

If the 72 hours have already passed by the time you read this and you have not notified, the obligation is not extinguished. Article 33(1) requires that any delay beyond 72 hours be accompanied by reasons for the delay. The fine analysis at Article 83(2) considers the duration and gravity of the infringement; lateness without explanation is treated more severely than lateness with documented cause.

Risk assessment: do I need to notify?

The Article 33 threshold is any risk to the rights and freedoms of natural persons. The Article 34 threshold for direct communication to individuals is high risk. The EDPB Guidelines 01/2021 on examples regarding personal data breach notification provide worked examples for each combination of breach type and data type.

A rough rule of thumb for the two thresholds:

A confidentiality breach involving a single email address and first name accidentally sent to a colleague is unlikely to require either notification. A confidentiality breach involving 10,000 customer records with email + password hash + purchase history almost certainly requires both.

For pre-incident preparation, the GDPR compliance checklist covers the controls that reduce breach likelihood in the first place.

What goes in the notification

Article 33(3) GDPR specifies the minimum content of the notification to the supervisory authority:

1. Nature of the breach: confidentiality, integrity, or availability, and what happened.
2. Categories and approximate number of data subjects affected.
3. Categories and approximate number of records affected.
4. Contact point: name and contact details of the data protection officer or other point of contact.
5. Likely consequences of the breach for affected individuals.
6. Measures taken or proposed to address the breach and to mitigate its possible adverse effects.

The EDPB allows phased notification under Article 33(4): if all six elements are not available within 72 hours, file what is known with a clear indication that further information will follow. Do not delay the initial notification while waiting for forensic conclusions.

Most national supervisory authorities provide an online form for filing. Search "[your country] DPA data breach notification form" or consult the EDPB members list.

Communication to individuals: the high-risk threshold

Article 34 requires the controller to communicate the breach to affected individuals without undue delay when the breach is likely to result in a high risk to their rights and freedoms. Three carve-outs in Article 34(3) remove the obligation:

• The controller has implemented appropriate technical and organisational measures, such as strong encryption, that render the personal data unintelligible to any person who is not authorised.
• The controller has taken subsequent measures that ensure the high risk is no longer likely to materialise.
• It would involve disproportionate effort, in which case a public communication or similar measure that informs the data subjects in an equally effective manner is required.

The first carve-out is the one organisations often misread. Encryption at rest on a disk that the attacker has compromised in plaintext is not sufficient; encryption that the attacker did not break is. The second carve-out is rare in practice; few measures truly eliminate residual risk after the fact.

The communication must use clear and plain language, describe the nature of the breach, name a contact point, describe likely consequences, and describe measures taken or proposed.

Document everything: Article 33(5)

Article 33(5) requires the controller to document all personal data breaches, including those that do not need to be notified externally. The internal register must comprise the facts relating to the personal data breach, its effects and the remedial action taken.

Minimum fields for a breach register entry:

• Incident reference number
• Date and time of incident (estimated if unknown)
• Date and time of awareness
• Description of the incident
• Categories of personal data and approximate number of records
• Categories and approximate number of data subjects
• Risk assessment and decision: notify yes/no, communicate yes/no, with reasoning
• Date and time of notification to supervisory authority, if any
• Date and time of communication to data subjects, if any
• Remedial actions taken
• Lessons learned and process changes

A spreadsheet is sufficient for a small organisation. Larger ones use a GRC tool. The supervisory authority is entitled to request the register during an inspection.

Common mistakes during the 72 hours

These patterns recur in published decisions of national supervisory authorities.

Waiting until the investigation is complete. Forensic investigations routinely take weeks. The 72 hours do not pause. File the initial notification within 72 hours with what is known, and add updates as the picture clarifies.

Treating "we are not sure" as not yet aware. If there is a reasonable basis to believe personal data has been compromised, awareness has occurred. The threshold is reasonable degree of certainty, not absolute certainty.

Counting only working days. The 72 hours include weekends, evenings and public holidays. Build a process that can fire on a Friday night.

Treating processor-side incidents as not your problem. Under Article 28, the processor's breach is the controller's responsibility to notify. Your hosting provider, payment processor or email provider getting hacked starts your clock as soon as they tell you (or as soon as you should have known via public reporting).

Skipping individual notification when the risk is high. Some organisations notify the supervisory authority but rely on the supervisory authority's instructions before notifying individuals. Article 34 places the duty on the controller, not on the supervisory authority. The controller must decide.

Inadequate internal documentation. A controller that cannot show its breach register at a subsequent inspection faces a separate Article 33(5) infringement on top of any underlying breach.

Preparation: what to do before an incident

The 72-hour window is too short to design a process from scratch under pressure. Prepare in advance.

Inventory of personal data and systems

Maintain a current record of processing activities under Article 30. This is the foundation of any breach risk assessment. The GDPR website audit checklist covers the discovery side of this work.

Designated point of contact

Name the person who receives breach alerts and starts the timer. For a small business, this is typically the owner or CTO. The name and 24/7-reachable contact must be documented and known to all staff.

Detection capability

Logging on the web application, the database and the email server. Alerts on anomalies. The security checklist for small businesses covers the baseline controls.

Notification template

A draft template that can be populated and sent within the 72 hours. Include placeholders for the six Article 33(3) elements.

Communication template for individuals

A separate draft template for direct communication to affected data subjects, in clear and plain language.

Decision-maker reachable out of hours

The breach can come in at any time. Define who decides whether to notify and who decides to communicate to individuals, and ensure those people are reachable.

Supplier contact list

For processor-side incidents, you need to be able to reach the processor immediately. Maintain a contact list with after-hours phone numbers for hosting, payment, email and any other processor handling personal data.

Final checklist

• You can detect a breach within hours, not weeks
• A named point of contact starts the timer
• You can identify the categories and approximate numbers within 72 hours
• You have a draft notification template ready to populate
• You have a draft individual-communication template ready
• Your breach register is populated and accessible
• All processors have signed DPAs with breach notification clauses
• Decision-makers are reachable out of hours
• Logging is enabled on web application, database and email server
• You have run a tabletop exercise on a hypothetical breach in the past 12 months

---

This is technical analysis, not legal advice. For incidents involving cross-border processing, special category data, or active supervisory authority investigations, consult a lawyer who specialises in data protection.