Category: Security & Breach Notification
Delayed Notification With Reasons
Simply put
The evidence provided does not support a reliable privacy or GDPR definition of this term. The available sources relate only to technical delays in dispatching push notifications, emails, and SMS messages on consumer devices and platforms, and do not address data protection notification obligations.
Formal definition
No authoritative definition can be produced from the supplied evidence. In a GDPR context, a term of this kind might be expected to relate to notification obligations where a controller communicates late and provides justification for the delay, but none of the provided sources (which concern messaging-platform troubleshooting and device-level push delivery timing) substantiate such a meaning. A properly sourced definition would need to be verified against the current official text of the Regulation and relevant supervisory authority guidance, and the reader should not treat this entry as a settled legal definition.
Why it matters
This entry cannot responsibly assert why "Delayed Notification With Reasons" matters as a data protection concept, because the evidence supplied does not support a privacy or GDPR meaning for the term. The available sources address only technical delays in dispatching push notifications, emails, and SMS messages on consumer devices and platforms, for example, messaging-protocol power optimization, unstable device connectivity, and channel-dependent dispatch timing. None of these sources concern breach notification obligations, controller duties, or supervisory authority requirements.
Because the term sits in a Data Breach Notification category, readers may expect it to relate to a controller notifying late and providing justification for the delay. Under GDPR that general idea is plausible, but the provided evidence does not substantiate it, and this entry should not be relied upon as a settled legal definition. Presenting one on this basis would risk fabricating the term's meaning and misleading a compliance program.
To establish why this term matters in a genuine privacy context, a properly sourced entry would need to be verified against the current official text of the Regulation and relevant supervisory authority guidance. Until such source material is available, the reader should treat the legal meaning of this term as unverified and consult the applicable official texts directly.
Who it's relevant to
Data protection officers and compliance leads
Those responsible for breach notification programs should be aware that this glossary entry is not backed by relevant legal source material and should not be cited as authority. Any operational reliance on notification timing or grounds for delay should be based on the current official Regulation text and applicable supervisory authority guidance rather than on this entry.
Privacy lawyers and advisers
Legal advisers evaluating whether and how a late notification with stated reasons may be permissible should treat the term here as unverified, given the absence of supporting privacy or GDPR sources. The correct position should be confirmed against the primary legal texts and relevant guidance, noting that member state implementations and regulator interpretations can vary.
Glossary editors and researchers
This entry flags a sourcing gap: the evidence packet contains only consumer technology troubleshooting material about push, email, and SMS delivery latency, none of which addresses data protection law. A defensible definition cannot be produced until relevant, authoritative privacy sources are supplied and verified.
Inside Delayed Notification With Reasons
Trigger for personal data breach notification
The obligation to notify the supervisory authority arises where a personal data breach is likely to result in a risk to the rights and freedoms of natural persons. The concept of delayed notification concerns the timing of that notification rather than whether it is required.
Notification without undue delay
Under the GDPR, notification to the competent supervisory authority is generally expected without undue delay and, where feasible, within a defined short period of becoming aware of the breach. Because the exact timeframe should be verified against the current official text, the emphasis here is on the standard that delay must be justifiable rather than arbitrary.
Reasons for the delay
Where notification is not made within the expected timeframe, the GDPR generally requires that the notification be accompanied by reasons explaining the delay. This is the defining element of a 'delayed notification with reasons': the delay itself is not automatically a breach of the obligation, provided a justification is documented and communicated.
Phased or staged notification
Where all information about a breach is not available at once, information may be provided in phases without further undue delay. This allows an initial notification to be supplemented, and is distinct from, though sometimes confused with, delayed notification with reasons.
Accountability and documentation
The controller should typically document the facts of the breach, its effects, and the remedial action taken, as well as the reasoning behind any delay, so that the supervisory authority can verify compliance. The adequacy of the stated reasons is generally subject to assessment by the regulator.
Roles: controller and processor
The notification obligation to the supervisory authority generally falls on the controller. A processor is typically required to notify the controller without undue delay after becoming aware of a breach, which can affect the point at which the controller is deemed 'aware' and thus the delay calculation.
Common questions
Answers to the questions practitioners most commonly ask about Delayed Notification With Reasons.
Does the 72-hour timeframe mean a breach notification can simply be submitted late without consequence as long as reasons are attached?
No. The obligation is generally to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach. Where notification is not made within that period, it must be accompanied by reasons for the delay. This mechanism does not create an open-ended extension; it requires the controller to justify why the timeframe was not met and remains subject to the supervisory authority's assessment. Reliance on this provision should be treated as an exception to be documented, not a routine alternative to timely notification.
Does providing reasons for a delay convert a late notification into a fully compliant one?
Not necessarily. Stating reasons is a required element when the 72-hour timeframe is exceeded, but it does not by itself establish that the delay was justified or that the controller met its accountability obligations. A supervisory authority will typically assess whether the delay was reasonable in the circumstances. The adequacy of the reasons, the surrounding facts, and the controller's overall handling of the breach are all relevant, so compliance here is context and risk dependent rather than guaranteed by the presence of an explanation.
At what point does the 72-hour clock start, and how does that affect when a delay must be justified?
The period generally runs from when the controller becomes aware of the personal data breach, rather than from the moment the incident occurred. Determining the point of awareness can involve judgment, particularly where initial signals require investigation to confirm that a breach has occurred. Because awareness is the trigger, it is advisable to document the basis and timing of that determination, as this affects whether a notification is on time and, if not, what reasons for delay need to be recorded.
How should a controller document the reasons for a delayed notification in practice?
In most cases it is advisable to record the reasons contemporaneously as part of the internal breach record, including a factual account of the timeline, the point of awareness, the steps taken during the investigation, and the specific circumstances that prevented notification within the timeframe. Keeping this documentation supports the accountability principle and allows the controller to substantiate its position if the supervisory authority queries the delay. The record should reflect actual events and avoid retrospective justification that is not supported by the facts.
Can a notification be made in phases where full information is not available within the timeframe?
Generally, where it is not possible to provide all required information at the same time, the information may be provided in phases without further undue delay. This can allow a controller to notify within the timeframe on the basis of the information available and supplement it later, rather than delaying the entire notification. Phased notification and delayed notification are distinct concepts, so a controller should consider whether earlier partial notification is feasible before treating the situation as one requiring reasons for delay.
How does the delayed notification obligation interact with any duty to notify affected individuals?
The obligation to notify the supervisory authority is separate from any obligation to communicate a breach to affected data subjects, which typically arises where the breach is likely to result in a high risk to their rights and freedoms. The reasons-for-delay mechanism discussed here concerns notification to the supervisory authority. Controllers should assess each obligation on its own terms and timelines, as the criteria, triggers, and content differ, and should verify the specific requirements against the current official text and applicable national implementing law.
Common misconceptions
A late notification is always a violation in itself.
Notification after the expected timeframe is not necessarily a standalone infringement, because the GDPR generally permits later notification provided it is accompanied by reasons for the delay. Whether the reasons are adequate is, however, subject to assessment by the supervisory authority.
Any breach must be notified, so reasons for delay are only about missing a deadline.
Notification is generally required only where the breach is likely to result in a risk to the rights and freedoms of individuals; low-risk breaches may not require notification at all. Where notification is required and delayed, the reasons address the timing, not whether the breach was notifiable.
Delayed notification with reasons is the same as phased notification.
These are related but distinct. Phased notification concerns providing information in stages when not all details are available; delayed notification with reasons concerns explaining why the initial notification itself was not made within the expected timeframe. In practice both may apply to a single incident.
Best practices
Document the point at which the controller became 'aware' of the breach, since the delay is generally measured from that moment, and record how any processor notification fed into that awareness.
If notification cannot be made within the expected timeframe, record clear, specific reasons for the delay contemporaneously and include them in the notification to the supervisory authority.
Use phased notification where full details are not yet available, providing an initial notification without undue delay and supplementing it as information emerges, rather than withholding notification entirely.
Maintain internal breach documentation covering the facts, effects, and remedial actions, so the reasoning for both the notification decision and any delay can be demonstrated on an accountability basis.
Assess and document the likelihood of risk to individuals' rights and freedoms before concluding whether notification is required, keeping the risk assessment separate from the timing analysis.
Verify the applicable notification timeframe and any national or UK GDPR variations against the current official text and relevant regulator guidance, as the position and expectations may evolve.