Data breach notification under GDPR: what you must do in the first 72 hours

GDPR Article 33 gives you 72 hours to notify your supervisory authority after discovering a personal data breach. Here's a practical timeline and decision framework for IT teams.

A personal data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. The definition is broader than most people realise - a lost unencrypted laptop, an email sent to the wrong recipient, or ransomware that encrypts but doesn't exfiltrate data can all be breaches.

Under GDPR Article 33, you must notify your supervisory authority (the ICO in the UK) 'without undue delay and, where feasible, not later than 72 hours' after becoming aware of a breach that is likely to result in a risk to individuals.

The 72-hour clock: when does it start?

The clock starts when you become 'aware' of the breach - not when it occurred. Awareness means you have reasonable certainty that a breach has happened, not just a suspicion. In practice, this means: once your IT team has confirmed that personal data has been affected, you're aware. Investigating for days before escalating to a decision-maker who then starts the clock is not a valid interpretation.

Supervisory authorities have been clear that organisations cannot deliberately delay internal awareness to extend their notification window. If an incident is escalated on day 1, the clock runs from day 1, even if the full investigation takes longer.

Do you need to notify?

Not every breach requires a notification to the supervisory authority. You must notify if the breach 'is likely to result in a risk to the rights and freedoms of natural persons'. You must notify affected individuals if the risk is 'high'. This is a risk assessment that you must make and document - even if you decide not to notify.

What must the notification include?

Article 33(3) specifies the minimum content for a supervisory authority notification:

• The nature of the breach, including categories and approximate number of data subjects affected
• Categories and approximate number of personal data records affected
• Name and contact details of the Data Protection Officer (or other point of contact)
• Likely consequences of the breach
• Measures taken or proposed to address the breach, including mitigation measures

You can notify in phases - provide initial information within 72 hours and follow up with additional details as your investigation progresses. The ICO's online reporting form allows you to indicate that the notification is partial and submit supplements. This is explicitly supported by Article 33(4).

What counts as a personal data breach

The definition is wider than most people assume, and narrower in one respect that catches organisations out. Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or unauthorised access to, personal data transmitted, stored or otherwise processed.

Three consequences follow from reading that carefully:

• It is not only about confidentiality. Losing data you cannot recover is a breach, and so is data being altered without authorisation. A failed backup discovered during a restore is a breach of availability, whatever else happened.
• It does not require an attacker. An email sent to the wrong recipient, a laptop left on a train, or a misconfigured share are all breaches, and collectively they are far more common than intrusions.
• It requires a breach of security. A disclosure you made deliberately and lawfully is not a breach even if you later regret it; that is a different problem with different obligations.

Ransomware is worth naming specifically, because it is often assessed only as availability. If the operator exfiltrated data before encrypting it, which is now the common pattern, you have a confidentiality breach as well, and the assessment has to cover both.

The part that decides everything: what data was involved

Every question in a breach response reduces to one thing. Article 33 asks you to describe the categories and approximate number of data subjects and records concerned. Article 34 makes notification to individuals turn on whether the breach is likely to result in a high risk to their rights and freedoms, which cannot be assessed without knowing what was in the data.

So the practical question in the first hours is not what happened to the machine. It is what was on it. An organisation that can answer that quickly is doing a risk assessment. One that cannot is guessing, and guessing tends to run in the direction of over-notification, because the safe answer under time pressure is to assume the worst.

That has a cost beyond the work. Notifying individuals unnecessarily erodes the signal for the time you genuinely need them to act, and it is difficult to walk back.

A practical 72-hour timeline

Hours 0-6: Contain and assess

• Isolate affected systems to prevent further data loss
• Identify what data has been affected (categories, rough volume)
• Establish whether the breach is ongoing
• Alert your internal incident response team, DPO (if applicable), and relevant management
• Begin your internal breach log

Hours 6-24: Investigate and risk-assess

• Determine the likely cause and scope of the breach
• Assess the risk level to affected individuals: low, medium, or high
• Determine whether regulatory notification is required
• Identify any processors who need to be notified
• Preserve evidence for your investigation

Hours 24-48: Draft and review notification

• Draft your supervisory authority notification using their online portal
• Legal or DPO review of the notification
• Prepare individual notification if required
• Document your risk assessment decision (notify / not notify) with reasoning

Hours 48-72: Submit to the supervisory authority

• Submit notification to supervisory authority - this is the deadline Article 33's 72 hours actually governs
• Brief key internal stakeholders
• Begin post-incident review

Notifying affected individuals - a separate clock (Article 34)

Article 34 individual notification is a distinct obligation from Article 33, with its own trigger and its own timing standard: it only applies where the breach is likely to result in a 'high risk' to individuals (a higher bar than Article 33's 'risk'), and the GDPR sets no fixed hour or day deadline for it - only 'without undue delay'. In practice this often happens alongside the 72-hour authority notification, which is why it's easy to read the two as sharing one clock, but they don't: a low-risk breach can require an Article 33 notification with no Article 34 notification at all, and a high-risk breach may reasonably need more investigation time before individuals are notified than the authority deadline allows. When individual notification is required, clearly explain what happened, what data was affected, what you're doing about it, and how individuals can protect themselves.

If you miss the 72-hour window

Notify anyway, and explain the delay. Late notification is treated less seriously than non-notification. Include the reasons for the delay in your notification - if the investigation genuinely required more than 72 hours before you had sufficient information to notify, document that reasoning carefully. 'We weren't sure if we needed to notify' is a weak explanation. 'The scope of the breach could not be confirmed until system logs were recovered from backup on day 4' is a credible one.

The breach register: your ongoing obligation

Article 33(5) requires you to maintain a record of all personal data breaches - including those you assessed as not requiring notification. This register should include: date discovered, nature of the breach, categories of data and data subjects affected, your risk assessment and notification decision, and any remediation steps taken. The ICO can request this register at any time, and it's often the first thing requested in an investigation.

Processors have a different duty, and no clock

Article 33(2) is short and often missed. Where a processor becomes aware of a personal data breach, it shall notify the controller without undue delay. No 72 hours, no threshold test, no risk assessment. The processor reports, and the controller decides.

Two practical consequences. If you are a processor, you do not get to assess whether the breach is worth mentioning; that judgement belongs to your client. And if you are a controller, your 72 hours begins when you become aware, which in a supplier breach means when they tell you, so their notification speed sits inside your deadline.

This is why Article 28(3)(f) requires the processor contract to oblige the processor to assist you with Articles 32 to 36. A contract saying the supplier will provide reasonable assistance gives you nothing to work with at hour six. One naming a contact, a channel and a timeframe does.

What awareness means, and why it is not the incident

The clock runs from awareness rather than from the event, and the two can be separated by months. Awareness is generally taken as the point at which you have a reasonable degree of certainty that a security incident has occurred that compromised personal data.

That gives you a short period of investigation to establish whether there is a breach at all, and it is not an invitation to defer the finding. Sitting on an alert to avoid starting the clock is the interpretation that goes badly, because the question a regulator asks afterwards is when you could reasonably have known rather than when you concluded.

Worth writing down at the time: when the alert arrived, who saw it, what was checked, and at what point certainty was reached. Reconstructing that timeline weeks later, from memory and ticket comments, is where breach responses become difficult to defend.

Where the endpoint case differs

A breach involving a laptop, a phone or a removable drive is the case where the what-was-on-it question is hardest, and it is also among the most common.

With a server or a database you have a schema. You know what fields exist, roughly how many rows, and which categories are involved, so the Article 33 description is largely a matter of counting. With an endpoint there is no schema. There is whatever the person saved, exported, downloaded or was sent over the working life of the machine, and nobody catalogued any of it.

Encryption changes the assessment but does not remove it. If the device was encrypted at rest, powered off, and the key was not compromised, the risk to individuals may be low enough that Article 34 notification is not required and the Article 33 assessment reflects that. Those conditions are ones you have to be able to evidence rather than assert, and the state the device was in at the time is a question of fact that gets harder to establish as days pass.

The determination is still yours to make and to record either way. Article 33(5) requires you to document the facts, effects and remedial action for every breach, including the ones you decide not to report.

Preventing breaches through data minimisation

The best breach notification is the one you never have to make. Data minimisation - holding only the personal data you actually need, for only as long as you need it - reduces the impact of any breach that does occur. If you don't hold unencrypted card numbers on endpoints, a lost laptop can't expose card data. Regular endpoint scanning to identify and remove personal data that has accumulated outside authorised systems is one of the most practical breach prevention measures available to IT teams.