A data breach can happen to any organisation, regardless of size or sector. What separates a manageable incident from a regulatory crisis is often not the breach itself but how the organisation responds in the hours that follow.
Under Article 33 of the GDPR, a controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. That 72-hour window is not a target — it is a ceiling. The clock starts ticking the moment anyone in your organisation has a reasonable degree of certainty that a security incident has led to the compromise of personal data.
This article walks through what that obligation means in practice, what steps to take when a breach is discovered, and how to prepare before one happens.
The GDPR defines a personal data breach broadly: any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. This covers far more than the stereotypical hacking scenario.
Common examples include an employee sending a spreadsheet containing personal data to the wrong recipient, a lost or stolen laptop containing unencrypted personal data, a ransomware attack that encrypts a database of customer records, an IT system misconfiguration that exposes personal data to the internet, a paper file left on a train, and a disgruntled former employee retaining access to systems after departure.
The key question is always: has personal data been compromised in terms of its confidentiality, integrity, or availability? If the answer is yes — even if the incident seems minor — you are dealing with a personal data breach under GDPR.
The clock begins when the controller becomes aware of the breach. This does not mean when senior management is informed or when the legal team is consulted. It means the moment any part of the organisation has reasonable certainty that a breach has occurred.
If your IT helpdesk receives a report that a database has been accessed by an unauthorised party, the organisation is aware — even if the IT helpdesk does not immediately escalate the matter. If a processor notifies you of a breach affecting your data, the clock starts when the notification reaches you, not when you finish investigating.
This is why internal escalation procedures matter so much. If there is no clear process for recognising and reporting potential breaches internally, the 72 hours may be half gone before the right people know about the incident.
The immediate priority is containment. Before worrying about notification obligations, take practical steps to limit the damage.
This might mean isolating a compromised system from the network, revoking access credentials that have been compromised, recovering or remotely wiping a lost device, correcting a misconfiguration that exposed data, or contacting the unintended recipient of misdirected personal data to request deletion.
Not every breach can be contained immediately, but every reasonable step to limit ongoing harm should be taken as soon as the breach is identified. Document everything you do — and everything you decide not to do, with reasons.
Not every breach requires notification to the supervisory authority. Article 33 requires notification unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. In practice, most breaches that involve personal data being exposed to unauthorised parties will meet this threshold.
The risk assessment should consider the nature of the personal data involved (special category data, financial data, and identification numbers carry higher risk), the volume and number of data subjects affected, the severity of the potential consequences (identity theft, financial loss, reputational damage, discrimination), whether the data was encrypted or otherwise protected, and whether the breach has been fully contained or whether data remains exposed.
If you conclude that there is no risk to data subjects — for example, an encrypted laptop is lost but the encryption is strong and the key was not compromised — you do not need to notify the supervisory authority. But you must still document the breach and your assessment in your internal breach register.
If the breach does pose a risk, you must notify the competent supervisory authority within 72 hours. In Belgium, this is the Data Protection Authority (Gegevensbeschermingsautoriteit / Autorité de protection des données).
The notification must include a description of the nature of the breach, including where possible the categories and approximate number of data subjects and data records concerned. It must describe the likely consequences of the breach. It must describe the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects. It must provide the name and contact details of the Data Protection Officer or other contact point.
The Belgian DPA provides an online notification form. If you cannot provide all the required information within 72 hours, the GDPR allows you to provide information in phases — but you must explain the reasons for the delay and provide additional information as soon as it becomes available.
Missing the 72-hour deadline is not automatically catastrophic, but it does require justification. Supervisory authorities take a dim view of organisations that miss the deadline because they did not have adequate incident response procedures in place.
If the breach is likely to result in a high risk to the rights and freedoms of data subjects, you must also notify the affected individuals directly. Article 34 of the GDPR requires this communication to be in clear and plain language and must describe the nature of the breach, the likely consequences, the measures taken to address it, and how data subjects can protect themselves.
The threshold for notifying data subjects is higher than for notifying the supervisory authority. A breach that poses a risk triggers DPA notification. A breach that poses a high risk triggers data subject notification as well.
There are limited exceptions: if you have applied appropriate technical measures that render the data unintelligible to anyone not authorised to access it (such as strong encryption), if you have taken subsequent measures that ensure the high risk is no longer likely to materialise, or if individual notification would involve disproportionate effort (in which case a public communication may be appropriate instead).
When in doubt, err on the side of transparency. Data subjects who learn about a breach from the supervisory authority or the press rather than from you will not look kindly on the omission.
Regardless of whether a breach requires notification, Article 33(5) requires you to document every personal data breach in an internal register. This must include the facts relating to the breach, its effects, and the remedial action taken.
The breach register serves two purposes. It demonstrates accountability to the supervisory authority by showing that you take breach management seriously and have a systematic approach to documenting and learning from incidents. It also creates an institutional record that helps you identify patterns — recurring causes of breaches, departments or systems that are particularly vulnerable, and whether your containment and response measures are effective.
A breach register entry should include the date and time the breach was discovered, how it was discovered, a description of the incident, the personal data and data subjects affected, the risk assessment and its conclusions, containment and remediation actions taken, whether and when the DPA was notified, whether and when data subjects were notified, and any follow-up actions or lessons learned.
Several patterns recur in organisations that handle breaches poorly.
Delayed internal escalation. The most damaging delays are often internal. If front-line staff do not recognise a breach or do not know how to report it, hours or days can pass before the incident response process begins. Training and clear reporting channels are essential.
Over-investigating before notifying. Some organisations spend the entire 72 hours investigating the breach in detail before notifying the DPA, only to miss the deadline. The GDPR explicitly allows phased notification — it is better to notify with incomplete information within 72 hours than to provide a complete report after the deadline.
Failing to document. Organisations that do not maintain a breach register or that document incidents inconsistently will struggle to demonstrate accountability, even if their substantive response was adequate.
Underestimating scope. An initial assessment that the breach is minor often proves wrong as investigation continues. It is better to treat a potential breach seriously from the outset and scale down if the risk proves low than to under-respond and discover the true scope later.
Forgetting the processor relationship. If the breach occurs at a processor, the processor must notify the controller without undue delay. The 72-hour clock for the controller starts when it receives the processor’s notification. Your data processing agreements should include clear breach notification obligations and timelines.
The organisations that handle breaches well are the ones that prepare before the incident happens. Effective preparation includes having a documented incident response plan that assigns roles, defines escalation paths, and sets out the steps to follow when a breach is detected. It includes training all staff to recognise potential breaches and know how to report them internally. It includes maintaining templates for DPA notifications and data subject communications so that these do not need to be drafted from scratch under time pressure. It includes testing your incident response plan periodically through tabletop exercises. And it includes ensuring that your data processing agreements contain appropriate breach notification clauses.
The 72-hour deadline is tight. Without preparation, it is almost impossible to assess a breach, make a risk determination, prepare a notification, and submit it to the DPA within three calendar days — especially if the breach is discovered on a Friday afternoon.
At Pitch, we help organisations prepare for and respond to data breaches across the full lifecycle: building incident response plans, drafting notification templates, conducting breach response training, and providing rapid-response support when a breach occurs.
When a breach is underway, we assist with the legal assessment of notification obligations, preparation and submission of DPA notifications, drafting data subject communications, managing the interaction with the supervisory authority, and post-incident review and remediation.
Our integrated practice across data protection, IT, and commercial law means we can also address the broader consequences of a breach — including contractual notification obligations, insurance claims, and reputational management.
Pitch is the law firm for innovators and creatives. If you need to prepare for data breaches or are dealing with an incident now, get in touch or schedule a meeting with our team.
%402x.svg){kind=small}
%402x.svg){kind=icon}
%402x.svg){kind=icon}
