Breach notification and the clock you are on
You will not have finished the investigation inside 72 hours and you are not expected to. Article 33 requires notification without undue delay and where feasible within 72 hours of becoming aware, and Article 33(4) explicitly allows information to be provided in phases. What ends careers is not an incomplete first notification but an organisation that cannot say how many people are affected, or whose 72 hours started three months after the intrusion.
When does the clock start?
At awareness, which means having a reasonable degree of certainty that a security incident has occurred leading to personal data being compromised. Not at the moment of intrusion, and not at the end of the investigation. A short initial verification period is accepted, and it is meant to be short: European guidance treats awareness as arriving quickly once an indicator is credible, and deliberately slow triage will be read as avoidance.
The 72 hours are calendar hours. They include a weekend, a public holiday and the period during which your senior people are unreachable, which is why the routine part of this to design is the decision route rather than the report. Somebody must be authorised to decide notifiability at 2am on a Sunday, and a delay caused by waiting for a committee is not a defence.
A regulator will also ask why awareness took as long as it did. That question moves the discussion to Article 32 and Article 5(1)(f), and to whether your monitoring was adequate to the risk. Late awareness is a separate failure from late notification, and it is the one that is harder to explain.
What counts as a personal data breach?
More than a leak. Article 4(12) defines it as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Loss of availability is included, so ransomware that encrypts your own database without anyone exfiltrating a record is a breach, and so is a deletion that destroys the only copy of data you were obliged to hold.
The threshold for telling a supervisory authority is risk. You notify unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. The threshold for telling the individuals themselves is higher: Article 34 requires it where there is a high risk, and one exception is where the data was rendered unintelligible to anyone unauthorised, for example by encryption with keys the attacker did not obtain.
That exception is why key custody is an incident response question and not only an architecture one. If you cannot demonstrate that the exposed data was encrypted and that the keys were held separately and were not compromised, you cannot rely on it, and reconstructing that evidence during an incident is not realistic. Article 33(5) also requires you to record every breach internally, including the ones you decide not to notify, with the reasoning.
Which clock applies to you?
Possibly several at once, with different deadlines and different recipients, which is the practical difficulty. A single incident at a payments company operating in the EU can trigger a supervisory authority notification, a customer contractual notice, a financial regulator report and a card scheme notification, on four different timescales. Work out which apply in advance and record them in one place.
| Regime | Who you tell | Deadline | Trigger |
|---|---|---|---|
| GDPR Article 33 | Lead supervisory authority | 72 hours from awareness, phased allowed | Any breach not unlikely to result in a risk |
| GDPR Article 34 | The affected individuals | Without undue delay | High risk to rights and freedoms |
| GDPR Article 33(2) | Your controller, if you are a processor | Without undue delay, hours fixed by contract | Any breach affecting their data |
| NIS2, where in scope | National CSIRT or competent authority | Early warning 24 hours, notification 72, report one month | Significant incident, as nationally transposed |
| DORA, for in-scope financial entities | Financial regulator | Initial, intermediate and final reports on set deadlines | Major ICT related incident |
| Card scheme rules | Acquirer and schemes | Contractual, commonly immediate | Suspected compromise of card data |
| Sector and national law elsewhere | Varies widely by jurisdiction | Varies, US health sector notice runs to 60 days | Depends entirely on the statute |
What must you be able to answer inside the window?
Four things: what happened, which categories and approximate number of individuals and records are affected, the likely consequences, and the measures taken or proposed. Article 33(3) lists them. The second is the one that fails, because answering it requires knowing which stores held which people, which is exactly what the data map exists for and exactly what most organisations cannot produce at speed.
This is why the guides in this cluster are ordered as they are. An accurate map of where personal data lives, a subject identity resolution service and a current record of who had access are not compliance paperwork; they are the components that make a 72 hour answer possible. Without them the first notification says the scope is under investigation and stays that way, which invites the next set of questions.
Prepare the approximate answer in advance. For each major store, know the record count, the categories of data held, and the identifiers present. That single table converts scoping from an investigation into an arithmetic exercise in the first hours, when everyone is busy with containment.
Why is container evidence usually gone?
Because the platform is designed to discard it. A compromised pod gets rescheduled or replaced, its filesystem disappears, its logs go with it unless they were shipped, and the horizontal autoscaler has already destroyed the instance you needed. Teams then try to determine what code was running and find that the image tag was mutable and has since been overwritten, so the exact build cannot be identified.
The controls that preserve an answer are all set before the incident. Ship logs off the node, retain the Kubernetes audit log and the cloud provider audit trail for a period long enough to cover a late discovery, deploy by immutable image digest rather than by tag, and retain registry pull records so you know which digest ran where and when. Keep egress connection logs, because the question of whether data left is answered there or not at all.
Add one runbook step that people forget under pressure: snapshot before you terminate. Cordon the node, capture a volume snapshot and the running container's filesystem, and preserve the memory dump if your tooling allows it, before scaling the workload back up. Containment and evidence preservation are in genuine tension in a container platform, and the order has to be decided in advance rather than argued about at the time.
What should you rehearse?
A tabletop with one hard question and a timer. Announce that a database credential appeared in a public repository twelve hours ago, then ask the team to produce the four Article 33 answers within two hours, using only the tooling that exists today. Do not let anyone say they would check something; make them check it.
Time three things specifically: how long to identify every store that credential reached, how long to determine who accessed it and from where, and how long to reach a person authorised to decide notifiability. The third is usually the surprise, because organisations invest in detection and leave the decision unassigned.
Then write down what you could not answer and fix the two cheapest gaps before the next rehearsal. This is the exercise that most reliably converts privacy documentation into working capability, and it also produces the internal breach register entries and the reasoning trail that Article 33(5) expects you to keep.
Common questions
- When does the 72 hour GDPR breach clock start?
- At awareness, meaning when you have a reasonable degree of certainty that a security incident has occurred and personal data has been compromised. A short verification period before that is accepted, but deliberate slowness will be treated as avoidance. The 72 hours are calendar hours including weekends and holidays, and Article 33(4) allows the notification to be provided in phases where you cannot supply all the detail at once.
- Does ransomware count as a personal data breach?
- Yes. Article 4(12) covers accidental or unlawful destruction, loss and alteration as well as unauthorised disclosure or access, so a loss of availability is a breach even where nothing was exfiltrated. Ransomware that encrypts your database, a failed migration that destroys records, and an accidental deletion of the only copy of data you were required to keep all qualify and all need the notifiability assessment.
- Do you have to tell the individuals affected?
- Only where the breach is likely to result in a high risk to their rights and freedoms, which is a higher threshold than the one for notifying a supervisory authority. Article 34(3) sets out exceptions, including where the data was rendered unintelligible to unauthorised parties, for example by encryption whose keys were not compromised. Relying on that requires evidence about the encryption and key custody that has to exist beforehand.
- What information must a breach notification contain?
- Article 33(3) requires the nature of the breach, the categories and approximate number of individuals and of records concerned, contact details for the data protection officer or other contact point, the likely consequences, and the measures taken or proposed to address it and mitigate harm. The approximate number is the answer that most often cannot be produced quickly, because it depends on knowing which stores held which people.
- Why is forensic evidence hard to obtain in a container platform?
- Because ephemerality is a design goal. A compromised pod is replaced, its filesystem and unshipped logs vanish, and mutable image tags mean the exact build that ran may no longer be identifiable. The controls that preserve answers are configured in advance: shipped logs, retained cluster and cloud audit trails, deployment by immutable digest, registry pull records, egress connection logs, and a runbook step to snapshot before terminating.
- Do you have to record breaches you decide not to report?
- Yes. Article 33(5) requires the controller to document all personal data breaches, including the facts, the effects and the remedial action taken, regardless of whether they were notifiable. That internal register is one of the first artefacts a supervisory authority asks for, and a register showing consistent reasoning about non-notifiable incidents is considerably more persuasive than one that is empty.
