It does not require that a full investigation is complete. It requires that the organization had sufficient information to know that a personal data breach had likely occurred. The security team that identified an anomalous access event and opened an investigation ticket became aware at the moment they identified the anomaly — not at the moment the investigation concluded. The clock started when nobody thought it had.
The Awareness Problem
The gap between when a breach occurs and when an organization becomes aware of it is well understood. Detection capability, dwell time, and alert triage backlogs all affect the detection timeline. What is less well understood is the gap between when awareness actually occurs and when the organization realizes that awareness has triggered a regulatory obligation.
Awareness for notification purposes is not a binary state that an organization formally declares. It is a condition that arises when information available to the organization, taken in aggregate, indicates that a personal data breach has probably occurred. Regulatory guidance from the EDPB clarifies that this threshold is lower than many organizations assume: awareness arises when an organization has enough information to conclude that a breach is more likely than not, not when the investigation has produced a definitive conclusion.
The practical consequence is that the notification clock may start during the investigation process rather than at its conclusion. A security team that identifies an anomalous access pattern, confirms that a system containing personal data was involved, and opens an investigation ticket has met the awareness threshold for purposes of the notification obligation — even if the full scope of the breach is not yet known. The 72 hours that follow are not investigation time. They are notification preparation time.
The notification clock does not wait for the investigation to conclude. It starts when the organization knows enough to know that something probably happened to personal data. Most organizations have not built their incident response process around this threshold.
Where Organizations Lose the Clock
Security Teams That Don't Know the Threshold
In many organizations, the security team and the privacy team are separate functions with separate processes. The security team that detects and investigates incidents may not have a clear picture of when the privacy notification obligation is triggered. The investigation runs. Containment is the priority. Notification is understood as something that happens after the scope is determined. The 72-hour window may expire during the investigation, not because anyone decided not to notify, but because nobody connected the awareness event to the notification trigger.
Awareness That Is Distributed Across Teams
Complex incidents involve multiple teams: security operations, IT, business unit owners, legal, executive leadership. Awareness may be distributed — each team has partial information, and the full picture emerges as information is shared. The notification threshold may be crossed when the aggregate of distributed awareness is sufficient to indicate a probable breach, even before that aggregate picture has been formally assembled. The clock is running. The synthesis has not happened.
The Scope Determination That Delays Notification
Organizations that treat 72 hours as the window for determining the full scope of a breach before notification will consistently exceed the deadline for significant incidents. Full scope determination for complex breaches often takes days or weeks. The regulation does not require full scope determination before notification. It requires notification when the organization is aware that a breach has probably occurred, with the information available at the time. Notification with incomplete information is not a compliance failure. Delayed notification pending full investigation may be.
Building the Process Around the Actual Trigger
Organizations that handle the notification timeline well have built their incident response process around the awareness threshold rather than the investigation conclusion. The process includes an explicit step — typically within the first hours of incident response — that assesses whether the incident has crossed the GDPR Article 33 awareness threshold. The assessment does not wait for forensic conclusions. It asks: do we have enough information to conclude that personal data was probably affected? If the answer is probably yes, the notification clock is running.
The regulatory authority notification does not need to be a detailed incident report. Article 33(3) specifies what it must contain: the nature of the breach, the categories and approximate number of individuals concerned, the likely consequences, and the measures taken or proposed to address the breach. Information that is not yet available can be provided in stages as the investigation progresses. The initial notification acknowledges the breach and the uncertainty. The follow-up notifications add detail as it becomes available.
The key process design decision is separating the notification decision from the investigation conclusion. These are different decisions with different criteria and different timeframes. The investigation conclusion informs notification content. The notification decision is triggered by awareness, not by conclusion.
Build the awareness threshold into the incident response process explicitly. The clock does not start when you decide it has.
Train the security team on the notification trigger, not only on the notification process. The trigger assessment is the step that most incident response processes do not have.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.