Personal data breach notification
A personal data breach is a security incident leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of, or access to, personal data. The GDPR requires notifying the supervisory authority without undue delay and where feasible within 72 hours of becoming aware, unless the breach is unlikely to risk people's rights; high-risk breaches also require telling affected individuals. Analytics stores are in scope. This is educational, not legal advice.
What this means
Under GDPR Articles 33 and 34, a personal data breach is not just a hack — it includes loss, accidental deletion, corruption, or unauthorised disclosure of personal data. When a controller becomes aware of such a breach, it must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to individuals' rights and freedoms.
Notifying individuals and the analytics angle
Where a breach is likely to result in a high risk to individuals, the controller must also communicate it to the affected people without undue delay, in clear language. Processors must tell their controller without undue delay so the clock can run. Analytics datasets — event logs, identifiers, IP-derived data — are personal data when they identify people, so a compromise can be reportable. The strongest mitigation is structural: minimised, anonymised, short-retention analytics holds less to lose, lowering both probability and severity.
- 72-hour regulator notification once aware (where feasible)
- Notify individuals when risk is high
- Processors must alert their controller promptly
How it appears in analytics and logs
If analytics personal data is exposed, altered, or lost, it can be a notifiable breach; the 72-hour regulator clock starts when you become aware.
Diagnostic use case
Know the breach-notification clock and thresholds before an incident, since analytics data can be part of a reportable personal data breach.
What WebmasterID can help detect
WebmasterID minimises and anonymises analytics data, so a breach of its store exposes far less identifiable information and is less likely to meet the high-risk threshold.
Common mistakes
- Counting the 72 hours from incident start, not from awareness.
- Assuming only hacks count, ignoring loss or accidental disclosure.
- Forgetting processor duties to alert the controller.
Privacy and accuracy notes
This page is educational, not legal advice. Holding less personal data shrinks both the likelihood and the severity of a notifiable analytics breach.
Related pages
- Controller vs processor
The GDPR assigns different duties to a controller — who determines the purposes and means of processing — and a processor, who processes personal data on the controller's behalf. Whether your analytics vendor is a processor or a joint controller changes the contracts and liabilities involved. This page explains the distinction and how it applies to analytics.
- Data retention in analytics
Data retention is the policy for how long an analytics system stores collected data before automatic deletion. Many platforms expose configurable retention windows for user- and event-level records. Shorter windows reduce breach exposure and support data-minimisation principles, while aggregate reports can often outlive the raw data. This is an educational overview, not legal advice.
- Data minimisation in analytics
Data minimisation is the principle that personal data should be adequate, relevant, and limited to what is necessary for the purpose. In analytics it translates to: do not collect identifiers you will not use, prefer aggregates over per-person rows, and avoid storing precise values like full IPs. Minimising at collection beats trying to protect data you never needed. This is educational, not legal advice.
- Website observability
Operational visibility that supports incident response.
Sources and verification notes
- EUR-Lex — GDPR Articles 33–34 (breach notification)Primary text on breach notification. Educational, not legal advice.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.