Notifying the supervisory authority is required for personal data breaches that are likely to result in risk to rights and freedoms, and it must happen within 72 hours of awareness. Notifying impacted data subjects is required only when the risk is high and must be done without undue delay. The two notifications serve different audiences and thresholds.
What the two GDPR notifications are trying to achieve
The two notifications address different obligations and different audiences. One informs the supervisory authority so regulators can assess the breach, the handling timeline, and whether the organisation complied with GDPR breach duties. The other informs the affected people so they can take steps to protect themselves when the breach is severe enough to create high risk to their rights and freedoms.
The supervisory authority notice is an accountability mechanism, while the data subject notice is a harm-reduction mechanism. That difference matters because the authority threshold is lower than the data subject threshold, and the content, timing, and purpose of each notice are not interchangeable. GDPR breach response is therefore a decision about both legal reporting and practical exposure management.
The supervisory authority notice is tied to awareness and the organisation’s ability to document what happened, what data was involved, and what remedial steps are underway. The data subject notice is tied to the likely consequences for individuals, especially where loss of confidentiality could lead to fraud, discrimination, or other rights-impacting harm. In practice, a breach can trigger one notice, both notices, or neither, depending on the risk assessment.
How the threshold and timing differ in practice
For the supervisory authority, the key question is whether the breach is likely to result in risk to rights and freedoms. If yes, notification is required within 72 hours of becoming aware of the breach, unless the organisation can justify a later submission. That standard is deliberately broad because regulators need early visibility even when the full facts are still developing.
For impacted data subjects, the threshold is higher: the breach must be likely to result in high risk. The timing standard is also different, because the notice must be given without undue delay once the organisation concludes that the risk level crosses that line. This is meant to reduce harm, not to satisfy a reporting clock, so the message should be clear, practical, and actionable.
Those thresholds create an important decision rule. A breach can require notice to the supervisory authority even if the individuals do not yet need to be told, because the legal test for the regulator is lower. If later analysis shows the exposure is high, the individual notice becomes necessary as well. That is why breach triage, legal review, and incident containment need to move together.
What should be included in each notice
The two notices usually draw on the same underlying incident record, but they are written for different readers. The supervisory authority expects the nature of the breach, likely consequences, categories and approximate volume of data and people affected, and the measures taken or proposed to address the breach. The notice to individuals should explain what happened in plain language, what data may be exposed, what the person should do next, and how to get more information.
That distinction is not cosmetic. A regulator notice can be more technical and can admit uncertainty where investigation is still ongoing. A data subject notice must be understandable and should focus on meaningful personal impact, because the purpose is to let the person act, such as changing passwords, watching for fraud, or taking account-protection steps. The same incident may therefore require two different narratives built from one evidence base.
When the breach involves identity and account material, the practical consequences can be severe because exposure of credentials or verification data can enable follow-on misuse. For broader control context on this kind of reporting and governance, Identity Security Regulatory Map is a useful navigation point, and Identity Data Privacy and Consent Guide helps frame how personal data handling affects notification and retention decisions.
Risk and Threat Considerations
The main risk is under-notification or delayed notification after a breach that actually creates personal harm. Organisations often underestimate the difference between a reportable breach and a breach that must also be disclosed to individuals, especially when the incident is still evolving and the likely misuse has not yet been observed.
Failure mechanism: Teams treat the 72-hour regulator clock as the only deadline, delay risk assessment, or assume that internal containment eliminates the need for data subject notice. That can leave affected people uninformed even when the breach creates a real chance of identity theft, fraud, or other rights-related harm.
Impact: The organisation can compound the original incident with avoidable compliance exposure, regulatory scrutiny, and loss of trust. If notice is inaccurate, incomplete, or late, individuals lose time to take protective action and the breach can create larger downstream damage than the original compromise.
For the regulatory context, the EU General Data Protection Regulation (GDPR) is the core reference, and the breach-notification rules should be interpreted alongside the security and accountability obligations in the regulation itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 33 — Notification of a Personal Data Breach to the Supervisory Authority | Directly governs the 72-hour supervisory authority notice after a reportable breach. |
| Art. 34 — Communication of a Personal Data Breach to the Data Subject | Directly governs when affected people must be told after a high-risk breach. | |
| Art. 33(5) — Documentation of Personal Data Breaches | Requires records of breach facts, effects, and remedial action for accountability. | |
| Recommendation — Document breach facts quickly and notify the supervisory authority within 72 hours when the Article 33 threshold is met. Notify impacted data subjects without undue delay when the breach creates a high risk to their rights and freedoms. Keep breach records with facts, effects, and remedial steps so you can justify notification decisions. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Supports prepared incident handling and role clarity for breach notification decisions. |
| A.5.25 — Assessment and decision on information security events | Supports assessing whether an event becomes a reportable breach and what follow-on action is needed. | |
| Recommendation — Predefine breach decision paths and responsibilities so notification happens on time. Triage incidents promptly and decide whether they are reportable personal data breaches. | ||
Practitioner Guidance
What to prioritise: Separate the breach decision into two questions as soon as facts are credible enough to assess risk, first whether the supervisory authority notification threshold is met, and then whether the exposure is high enough to justify notice to individuals. Do not wait for perfect certainty before drafting, because notification windows are measured from awareness, not from full forensic closure.
What to verify: Confirm the data categories involved, whether the data was encrypted or otherwise protected, whether the exposed information could enable misuse, and whether the incident affects identifiable individuals in a way that changes the legal threshold. The strongest indicator that data subject notice may be needed is not the breach type alone, but the realistic harm path from exposure to misuse.
Practitioner takeaway: Treat authority notification as the compliance clock and data subject notification as the harm-reduction clock; the correct response is the one that satisfies both when the incident crosses both thresholds.
Related resources from NHI Mgmt Group
- What is the difference between a data controller and a data processor under GDPR?
- What is the difference between mapping personal data categories and documenting processing purposes under GDPR?
- What is the difference between a Data Protection Impact Assessment and a lighter assessment under UK GDPR reforms?
- What is the difference between privacy compliance and data intelligence under GDPR?