Article 33 of the GDPR gives a controller 72 hours to notify its supervisory authority of a personal data breach. The number is the part everyone remembers. The parts that decide whether you meet it get less attention: when the clock starts, what counts as a breach, who decides, and what the notice has to say.
Teams that miss the deadline rarely lose it in the last few hours. They lose it in the first day, debating whether an incident is "really a breach" while the clock is already running, or waiting on a processor that has not yet told them.
This article covers the definition, the trigger, the notice, communication to individuals, and the records you need whether or not you notify.
What counts as a personal data breach
Article 4(12) defines a personal data breach 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.
The EDPB's breach guidelines group breaches into three types:
Confidentiality breaches: unauthorized or accidental disclosure of, or access to, personal data.
Integrity breaches: unauthorized or accidental alteration of personal data.
Availability breaches: accidental or unauthorized loss of access to, or destruction of, personal data.
Availability is the type security teams overlook. Ransomware that encrypts a database of customer records is a personal data breach even if nothing is exfiltrated, because the data was made unavailable. The guidelines treat a temporary loss of availability as a breach too. Whether it must be notified depends on the risk it creates.
Not every security incident is a personal data breach. A blocked phishing email, or a compromised account with no access to personal data, belongs in your incident log. It is not a breach under Article 4(12).
When the clock starts
The 72 hours run from when the controller becomes "aware" of the breach. The EDPB's guidelines describe awareness as having a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.
That allows a short period of investigation to establish whether a breach has happened. It does not allow you to wait for a full forensic picture. In practice:
Detection is not awareness. An alert that might indicate a breach starts an investigation, not the clock. The investigation should start promptly and be brief.
Awareness is not certainty about scope. Once you are reasonably certain that personal data has been compromised, the clock runs, even if you do not yet know how many people are affected.
Record the moment. Write down when you became aware and what established it. If a supervisory authority later asks why you notified on the fourth day, the answer is in that entry.
The processor's role
Article 33(2) requires a processor to notify the controller "without undue delay" after becoming aware of a breach. The processor does not decide whether the breach is notifiable to an authority. That assessment belongs to the controller.
The EDPB's guidelines treat the controller as aware once the processor has informed it. So a processor's delay does not formally consume the controller's 72 hours. It does delay everything the controller must do, and the controller is the one answering to the authority.
For a SaaS provider, that means two things. Your incident response plan needs a customer notification step for breaches affecting customer data, with a named owner. And the notice period in your data processing agreements must be one your process can meet.
Deciding whether to notify the authority
Article 33(1) requires notification unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons". Note the direction of the test. Notification is the default, and you need a reason not to notify.
The factors the guidelines point to include:
the type of breach,
the nature, sensitivity, and volume of the personal data,
how easily individuals can be identified,
the severity of the consequences for them,
special characteristics of the individuals, such as children,
the number of individuals affected, and
whether the data was protected, for example by encryption with a key that was not compromised.
Say a laptop with full-disk encryption is stolen, and its key was not exposed. That may be unlikely to result in a risk. Say a spreadsheet of customers' names and home addresses is emailed to the wrong external recipient. That may well be notifiable, depending on what else it contains and who received it.
Where you notify after 72 hours, Article 33(1) requires the notification to be accompanied by the reasons for the delay.
What the notice must contain
Article 33(3) sets the minimum content:
The nature of the breach, including, where possible, the categories and approximate number of data subjects concerned, and the categories and approximate number of personal data records concerned.
The name and contact details of the data protection officer or another contact point.
The likely consequences of the breach.
The measures taken or proposed to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.
Article 33(4) allows you to provide the information in phases, without undue further delay, where it is not all available at once. Use it. An initial notice within 72 hours that states what you know and what you are still establishing is better than a complete notice on the sixth day.
Which authority to notify
If you have an establishment in the EU and the breach concerns cross-border processing, the one-stop-shop mechanism under Article 56 generally means notifying your lead supervisory authority.
Without an EU establishment, the position is different. The EDPB updated its breach guidelines in 2023 to say that appointing an EU representative under Article 27 does not give a controller a lead authority. A controller outside the EU may then need to notify the authority in each member state where affected individuals live. If you are a non-EU company with EU users, work out that list before you need it.
When to tell individuals
Article 34 requires the controller to communicate the breach to the affected individuals without undue delay where it is likely to result in a high risk to their rights and freedoms. The threshold is higher than for the authority: high risk, not risk.
The communication must describe the nature of the breach in clear and plain language and include at least the contact point, the likely consequences, and the measures taken or proposed (Article 34(2)). Practical advice on what individuals can do to protect themselves belongs in it too.
Article 34(3) removes the requirement in three cases:
the data was protected by measures, such as encryption, that render it unintelligible to anyone not authorized to access it,
you have since taken measures that ensure the high risk is no longer likely to materialize, or
individual communication would involve disproportionate effort, in which case a public communication or a similarly effective measure is required instead.
Under Article 34(4), the supervisory authority can also require you to communicate the breach to individuals if it considers the risk high.
Record every breach, including the ones you do not notify
Article 33(5) requires the controller to document any personal data breach, including the facts relating to it, its effects, and the remedial action taken. This covers every breach, not only the ones you notify. The record must enable the supervisory authority to verify compliance with Article 33.
For breaches you decide not to notify, record the reasoning. "Unlikely to result in a risk: the data was encrypted and the key was not exposed" is a defensible entry. A blank field is not.
The same incident can trigger other regimes with different clocks and thresholds. A breach of health data may also engage HIPAA breach notification, and a financial entity may have DORA incident reporting obligations. Build each decision into one incident process rather than running them in parallel.
The notification decision is a legal judgment made under time pressure. Agree in advance who makes it, and put counsel on your incident contact list so the call can be made inside the window.
How TrustLynce helps
TrustLynce's continuous monitoring routes control failures to named owners, so a potential incident reaches the people who decide whether it is a breach. Customer commitments records the breach notice periods you have agreed to in customer contracts, so your incident process knows which customers to notify and by when.