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.
| Scenario | Supervisory authority notification | Individual notification |
|---|---|---|
| Encrypted laptop lost, decryption key not compromised | Unlikely required | Not required |
| Unencrypted USB drive with customer names and emails lost | Required | Likely required |
| Ransomware — data encrypted but not confirmed exfiltrated | Likely required | Case by case |
| Email sent to wrong recipient (single individual's data) | Low-risk — document, assess | May be required |
| Breach at a processor affecting your data | Required — you notify, not the processor | You assess and notify if required |
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).
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 and communicate
- Submit notification to supervisory authority
- Send individual notifications if required — clearly explain what happened, what data was affected, what you're doing about it, and how individuals can protect themselves
- Brief key internal stakeholders
- Begin post-incident review
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 defensible 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.
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.