72-Hour Breach Notification Protocol: Meeting DPDP Board Mandates

I would read Rule 7 as two separate obligations stacked together, because treating it as a single 72-hour deadline is where I have seen incident response plans go wrong. The first obligation fires the moment you have identified a breach, not once you have fully investigated it, notify the Board and affected individuals without delay, with whatever description of the breach's nature, extent, timing and location you can reasonably provide at that point, plus a preliminary sense of likely impact. The second obligation is the fuller picture, due to the Board within 72 hours, an updated description, what caused it, what you have done to contain and remediate it, findings on who was responsible if known, and confirmation of what you told affected individuals.

That structure matters operationally. It means your incident response plan cannot wait until the investigation is "done" to say anything to the Board. It needs a documented process for issuing an early, necessarily incomplete notification fast, then following up with the fuller 72-hour report as the investigation matures. I have seen teams delay the first notification because they wanted to have a complete, polished story before contacting the regulator. Under DPDPA, that instinct is itself a compliance risk.

I would draft this template well before you ever need it, not during an active incident when everyone is stretched thin and legal review is competing with actual containment work. Plain language matters more than it sounds here, a notification stuffed with legal hedging and technical jargon does not meet the "concise, clear and plain" bar and does little to help someone actually protect themselves. Pre-draft a modular template with placeholders for the specific facts, so your team is filling in blanks under pressure rather than writing from scratch.

In practice I tell CISOs to plan for the immediate notification to go out within the first working day of confirmed detection, treating "without delay" as meaning something closer to hours than the outer edge of what might technically be defensible. Assign clear ownership before an incident happens, who drafts the Board notification, who approves it, who handles the individual notifications, who talks to the press if it escalates that far, because deciding these roles during the incident itself burns hours you do not have.

For the 72-hour report, build a standing internal checklist that mirrors what the Board expects, updated breach description, root cause findings so far, containment and remediation actions taken, and confirmation that individual notifications went out. If you are not going to make the 72-hour deadline, the extension request itself needs to go in writing before the deadline passes, not as an apology after it. I would treat a missed deadline with no extension request on file as one of the more avoidable ways to turn a technical incident into a regulatory enforcement problem.

I think the penalty number is less important than what it signals about how the Board is likely to treat process failures versus the underlying incident itself. A breach caused by a genuinely sophisticated attack, promptly and transparently reported, is a very different regulatory conversation than the same breach reported late or incompletely because nobody owned the process internally. The 72-hour rule rewards organisations that can demonstrate they had a functioning incident response capability, not organisations that simply avoided ever having an incident, which is not a realistic bar for anyone operating at scale.