Data Breach: The 72-Hour GDPR Notification

A lost USB stick, a hacked account, a stolen laptop, an email sent to the wrong recipient: the moment personal data is exposed, GDPR starts a countdown. You have 72 hours to notify the supervisory authority of the breach. That short window is often the most stressful part of the incident, especially when no procedure was prepared and you discover the requirements under pressure.

The right approach is not to hope nothing happens, but to prepare two things in advance: the ability to document a breach quickly, and technical measures that reduce the risk at the source. These two aspects reinforce each other. The better your endpoints are protected, the less a leak exposes genuinely usable data, and the easier it is to justify your decisions to the authority.

What the 72-hour notification requires

The notification is not a simple declaration: it must contain precise information that you need to gather quickly. Preparing these elements in advance saves decisive time.

• The nature of the breach and the categories of data involved.
• The approximate number of people and records affected.
• The likely consequences for the data subjects.
• The measures taken or planned to limit the effects of the breach.
• The contact details of the DPO or point of contact for the authority.

When does the countdown start?

The 72-hour window runs from the moment you become aware of the breach, not from when it occurred. This distinction is essential: it makes fast detection and a clear internal escalation chain indispensable. If an employee spots an incident but does not know whom to report it to, you lose precious hours before the analysis even begins.

Not every breach must be notified. If it is unlikely to result in a risk to people's rights and freedoms, it does not have to be reported to the authority — but you must be able to justify that decision and log the analysis in your internal breach register. That register is itself an obligation: it must exist even for incidents you do not notify.

Reduce the risk at the source, on the endpoints

This is where endpoint security changes the equation. Encrypted data and a controllable device sharply reduce the risk to the individuals concerned — to the point, in some cases, of removing the need to notify or significantly lowering the severity of the incident.

• Encryption (BitLocker, FileVault): data stolen but completely unreadable.
• Remote wipe via Intune: neutralize a lost or stolen device.
• MFA and Conditional Access: limit the reach of a stolen credential.
• Access logging: establish precisely how much was actually exposed.

Beyond notifying the authority, GDPR may also require you to inform the data subjects directly when the breach is likely to result in a high risk to them. Here again, endpoint controls tip the balance: if the stolen data was encrypted and therefore unreadable, that high risk can be ruled out, sparing you an alarming communication to your clients or employees. Preparing these measures upfront reduces your legal exposure, your workload during a crisis, and the impact on your reputation all at once. It is far cheaper to invest in encryption and remote wipe today than to manage the fallout of an exposed, unprotected dataset tomorrow.

What to do on the day of the incident

When a breach is detected, acting in the right order avoids rushed mistakes and secures your file. This sequence keeps you in control of the 72-hour clock.

1. 1Contain the breach: revoke access, isolate or wipe the affected device.
2. 2Qualify the incident: which data, how many people, what level of risk.
3. 3Check the technical measures in place, especially encryption, and keep the evidence.
4. 4Decide whether notifying the authority and informing individuals are required.
5. 5Log everything in your breach register, and notify within 72 hours if needed.

A concrete example

An SMB loses a laptop containing its employees' HR files. Legitimate panic: sensitive personal data is potentially exposed, and the 72-hour countdown begins. But the machine was encrypted with BitLocker, enrolled in Intune, and a remote wipe was triggered as soon as the loss was reported.

The DPO documents the timeline, attaches proof that encryption was active at the time of the loss, and concludes that the risk to individuals is strongly reduced. The breach is logged in the internal register, but the analysis shows that notification to the authority is not required and no alarming communication to employees is needed. Without encryption, the same incident would have forced a notification and probably the individual information of every affected employee.

Common mistakes to avoid

Handling a data breach usually derails on organizational problems more than technical ones. Here are the most costly traps.

• Discovering GDPR requirements on the day of the incident, with no procedure or register ready.
• Being unable to prove encryption was active, for lack of a dated report.
• Misjudging when the clock starts, and believing you have more time than you do.
• Neglecting the breach register for non-notified incidents, which is nonetheless mandatory.
• Over-notifying out of caution without analysis, which needlessly increases your obligations and alarms people.

How AuPoint reduces your risk

AuPoint is a SaaS that makes Intune security and compliance easy, with no PowerShell. The platform deploys these controls — encryption, remote wipe, MFA, Conditional Access — across your entire fleet in a few clicks, with an impact preview before applying and one-click rollback. Above all, it maps each measure to GDPR requirements and produces a dated, exportable report. The day an incident hits, you prove your diligence instead of starting from scratch, and you quickly document your risk analysis.

Frequently asked questions

Is a stolen encrypted device a breach to notify?

The theft is still a breach to analyze, but encryption sharply reduces the risk to individuals. If the data was unreadable and the key not compromised, notification to the authority is often not required. You must, however, log the incident and your analysis in the internal register.

What happens if I miss the 72 hours?

A late notification is still possible, but must come with a justification for the delay. The key is not to conceal the incident: a well-justified late notification is better than none. Anticipating the procedure remains the best way to meet the deadline.

Do I always have to inform the data subjects?

Only when the breach is likely to result in a high risk to them. If measures such as encryption make the data unusable, that high risk can be ruled out, sparing you from informing individuals directly while still meeting your obligations.

Connect your Microsoft tenant to AuPoint and reduce your breach risk in minutes, with an impact preview and guaranteed rollback, no PowerShell. Start free at aupoint.io.