Controllers should not assume the 72 hour clock starts when the processor learns of the breach. Under the revised WP29 guidance, a controller is deemed aware when the processor informs it. That means teams need contractual escalation paths, fast internal triage, and a notification workflow that can assess risk to individuals and prepare regulatory reporting without unnecessary delay.
When the 72-hour clock really starts
The GDPR reporting timeline is driven by the controller’s awareness, not by the processor’s private knowledge of the incident. That distinction matters because many organisations mistakenly treat processor discovery as the start point and lose time in internal escalation. The practical question is whether the controller has enough verified information to assess whether personal data has been compromised and whether the event is notifiable.
In practice, the controller should treat processor discovery as an escalation trigger, not as a completed notification event. The controller still needs a fast path to gather facts, validate scope, and decide whether the incident reaches the threshold for regulator notification and, separately, whether affected individuals must be informed.
This is why the contractual and operational design matters as much as the legal rule. If a processor finds the incident first, the controller’s ability to meet the deadline depends on whether the processor can escalate immediately, provide the minimum facts needed for triage, and keep feeding updates as the investigation matures. For a practical reference point on the control environment around incident handling and reporting, see EU General Data Protection Regulation (GDPR) and CIS Controls v8.
What organisations need to build into the response path
A controller cannot rely on ad hoc email chains or informal phone calls if the processor discovers the breach first. The response path should define who receives the alert, who validates the facts, who assesses risk to individuals, and who drafts the notification package. The more distributed the processing chain, the more important it is to predefine the handoff points so that the notification decision does not stall while teams debate ownership.
Controllers should also distinguish between legal awareness and operational awareness. Legal awareness under GDPR may begin when the processor informs the controller, but the organisation still needs an evidence trail showing when the alert arrived, what information was available at each stage, and why the final reporting decision was made. That documentation becomes especially important when the incident unfolds in phases or when multiple processors and subprocessors are involved.
Where third parties or shared services are part of the processing chain, the notification workflow should be tested against a real breach scenario, not just documented in a policy. The most useful control is the one that produces timely escalation, a defensible risk assessment, and a notification draft that can be issued without waiting for a fully closed forensic report.
Risk and Threat Considerations
The main risk is deadline slippage caused by misreading who is “aware” of the breach and by waiting for internal certainty that is no longer available within the reporting window. A delayed controller response can turn a manageable incident into a compliance failure, and it can also increase exposure if the incident involves sensitive or high-impact personal data.
Failure mechanism: The processor detects the incident, but the contract, escalation path, or triage workflow does not move the information to the controller fast enough to support a timely notification decision. Ambiguous ownership, incomplete incident facts, and parallel approvals can all delay the point at which the controller can act.
Impact: The controller may miss the reporting deadline, submit an underdeveloped notification, or fail to preserve evidence showing why the report was made when it was. That creates regulatory, reputational, and remediation risk, especially when the incident later proves to have wider data exposure than first believed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Incident Response and Transparency | GDPR breach handling depends on timely incident disclosure and documented response decisions. |
| Recommendation — Build a documented breach workflow that preserves timing evidence and supports timely regulator notice. | ||
| CIS Controls v8 | 17 — Incident Response Management | This subject turns on rapid escalation, triage, and evidence preservation after a breach is discovered. |
| 14 — Security Awareness and Skills Training | Breach notification depends on staff recognising and routing processor-reported incidents correctly. | |
| Recommendation — Test and maintain an incident escalation process that moves processor alerts into controller triage immediately. Train responders to identify reportable incidents and route them to the right legal and security owners fast. | ||
| NIST CSF 2.0 | RS.AN-1 — Notifications from Detection Processes | The controller must translate a discovered incident into a timely notification decision and workflow. |
| RS.CO-2 — Incident Reporting | This maps to coordinating breach information flow across processors, controllers, and regulators. | |
| Recommendation — Use a notification workflow that converts incident intake into rapid analysis and reporting decisions. Define reporting channels and escalation thresholds so processor discoveries reach the controller without delay. | ||
Practitioner Guidance
What to verify: The processor agreement should define immediate escalation, required incident fields, and the expected update cadence. If the contract only says “notify without undue delay” but does not define operational handoff, the controller will still struggle to act within the deadline.
Decision rule: If the processor has discovered the incident first, start the controller’s notification triage as soon as the processor’s alert is received, even if the full facts are not yet known. Treat “incomplete but credible” as a reason to continue triage, not as a reason to pause the clock.
Practitioner takeaway: The key judgement is to separate legal awareness from forensic certainty, because GDPR reporting succeeds when escalation is fast, ownership is explicit, and the controller can make a defensible decision from partial but credible facts.
Related resources from NHI Mgmt Group
- How should security teams build an incident response process that satisfies breach notification obligations under GDPR?
- Should organisations prioritise external exposure or internal credential governance first?
- What do organisations get wrong about breach notification and accountability under the revised FADP?
- What happens when organisations do not build clear processes for DSARs and breach notification under LGPD?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
