Breach notification: the clock starts before you know what happened

This is the point everything else follows from, and the one most incident processes get wrong. Under the GDPR a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach — not 72 hours from having established the cause, the scope or the number of records.

The regulation anticipates that you will not know everything in time, and says so: where the information is not all available, it may be provided in phases. Late notification is permitted but must be accompanied by reasons for the delay, which is a considerably less comfortable conversation than an incomplete first report.

So the operational question is not "how fast can we investigate" but "how fast do we know we have something". Awareness is the trigger, and organisations that cannot say when they became aware have a second problem on top of the first.

Under the GDPR the two obligations have different thresholds, and conflating them causes both over- and under-notification.

Article 33 — telling the supervisory authority — applies unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. That is a low bar: most reportable-looking incidents clear it.

Article 34 — telling the individuals — applies only where the breach is likely to result in a HIGH risk to them. And it has explicit carve-outs: notification is not required where the data was encrypted and the key was not compromised, where you have taken subsequent measures that mean the high risk is no longer likely to materialise, or where individual contact would involve disproportionate effort, in which case a public communication is used instead.

That encryption carve-out is worth noticing while designing systems rather than during an incident. It is one of the few places where a technical control directly removes a legal obligation.

The DPDP Rules take a different approach, and the difference is the single most important thing for an Indian organisation to plan around.

There is no risk threshold for telling individuals. On becoming aware of a personal data breach, a Data Fiduciary must inform each affected Data Principal, without delay, in clear and plain language — what happened, the likely consequences, the mitigation measures being taken, the safety measures the individual can take, and contact details for someone who can answer questions. No "high risk" gate, no encryption carve-out written into the rule.

Reporting to the Data Protection Board is two-stage: an intimation without delay describing the nature, extent, timing and location of the breach and its likely impact, followed within 72 hours — or longer if the Board allows — by a detailed report covering the facts and causes, the mitigation taken, findings about who was responsible, the steps taken to prevent recurrence, and a summary of what was told to the affected individuals.

Two design consequences fall out of that. You need the ability to identify and contact every affected individual, which is an exercise in knowing where personal data actually lives. And the 72-hour report asks for the cause and the responsible party — which means your forensic capability is on a clock too.

If you process personal data for customers, the binding number is rarely the regulation’s. A processor’s statutory duty under the GDPR is to notify the controller without undue delay — no fixed hours — but the data processing agreement you signed will have put a figure on it, and 24 hours is common.

That is not unreasonable of them: their own 72 hours depends entirely on you telling them. But it means a contractual commitment you may not have read is the real operational requirement, and it can be tighter than anything a regulator imposes.

Two practical steps. Read the breach clause in your standard DPA before the next incident, and know what number you have agreed to across your customer base — if different contracts say different things, your process has to run to the shortest. And check whether the clause is triggered by a confirmed breach or a suspected one, because those are very different operational burdens.

Working backwards from the obligations, four capabilities matter and none of them can be improvised.

Detection that produces a defensible moment of awareness, with a timestamp. A decision path that can classify an incident quickly against the relevant thresholds, with someone empowered to make the call outside working hours. The ability to determine which individuals are affected — which depends on knowing where personal data is, and is usually the longest pole. And the ability to draft and send communications at speed, which means templates written calmly in advance rather than legal review under a clock.

Test it before you need it. The gap between having a documented procedure and having a procedure people can execute at 2am is exactly the gap a tabletop exercise exists to expose, and it is also what an auditor is looking for when they ask about incident response — not the document, the evidence it has been rehearsed.