Deep-dive · Respond 5.2
Engineers are usually the first to see the anomaly, so engineers usually start the clock. The catch is when it starts: not at the breach, but at the moment you are reasonably sure personal data was compromised. Scroll to run the clock.
DELETE FROM users, a lost laptopIt is not only "a hacker stole the database." A misconfigured S3 bucket, an accidental
DELETE FROM users with no backup, or a laptop of customer emails left in a taxi all count
(Art. 4(12)).
It is 72 hours from awareness, not from the incident. The flip side: "we didn't look at the alert" is wilful blindness, and it does not reset the clock either.
You are aware once you have a reasonable degree of certainty that an incident led to personal data being compromised. In practice, the moment an engineer writes "looks like the DB was exfiltrated" in Slack is when the clock can be argued to start. A short investigation to reach certainty is allowed; stalling is not.
Notify your lead supervisory authority (Art. 33). If you do not have the full picture at hour 72, notify with what you have and supplement later; Art. 33(4) explicitly permits phased notification.
Art. 33(3): the nature of the breach with approximate numbers of subjects and records affected, the DPO contact point, the likely consequences, and the measures taken or proposed to mitigate.
When the breach is likely to result in high risk to individuals, communicate to them without undue delay (Art. 34). Exemptions: the data was strongly encrypted with keys intact, the risk was mitigated afterwards, or contacting everyone is disproportionate (use a public notice instead).
You may skip notifying the authority only if the breach is unlikely to risk people's rights and freedoms, and you must document that assessment for every incident. For cross-border processing, notify your one lead authority, not all 27.