DPDP Breach Notification: The 72-Hour Rule and the CERT-In Complication

A personal data breach notification under India's DPDP Rules must reach the Data Protection Board within 72 hours of the fiduciary becoming aware of it, with affected individuals notified as well. That is the headline. The complication is that CERT-In's incident reporting rules run on a different clock, and a single breach can trigger both.

This post is the runbook for that situation: what the DPDP obligation requires, how CERT-In's rules interact, and how to structure a breach response so neither clock gets missed. It is not legal advice; it is operational guidance for engineering and security teams.

The DPDP obligation

Rule 7 of the DPDP Rules, 2025 requires a data fiduciary to notify the Data Protection Board of a personal data breach. The notification must happen within 72 hours of becoming aware, and affected data principals must also be notified. The intent is clear: breaches get disclosed quickly, to the regulator and to the people affected, so harm can be mitigated.

The 72-hour clock starts at awareness, which makes breach detection a compliance issue, not just a security issue. If you discover a breach three weeks late, you have already missed the notification deadline, and the lateness itself becomes part of the record.

The CERT-In complication

CERT-In's Cyber Security Directions require reporting certain security incidents on a shorter timeline. For the incidents covered, the reporting requirement can be as tight as six hours from detection. The covered categories include data breaches, which is where the overlap bites.

The result is two obligations for one event:

| Authority | Timeline | Trigger | |-----------|----------|---------| | CERT-In | Hours (as short as six for covered incidents) | Security incident, including data breach | | Data Protection Board | 72 hours | Personal data breach |

These are different authorities, different thresholds, and different timelines. A team that only knows the DPDP 72-hour rule is exposed on the CERT-In side. A team that only knows CERT-In misses the DPDP obligation entirely.

What a practical runbook looks like

A breach runbook that covers both clocks has the same shape as a good incident response runbook, with a notification track added:

1. Detect and confirm. The breach is real, not a false alarm. Who confirmed it, when?
2. Scope it fast. What data, which systems, how many principals? The data map earns its keep here; a company with an inventory can scope in hours, one without takes days.
3. Notify CERT-In for covered incidents, on its clock. The runbook should name the person who does this and the template to use.
4. Notify the Data Protection Board within 72 hours of awareness. Include what is known, what is being done, and the remediation plan.
5. Notify affected individuals as required, with clear language about what happened and what they can do.
6. Document everything. The notification trail, the scope assessment, the remediation actions, and the evidence package.

The documentation step is not optional. Under DPDP's evidence orientation, how you handled a breach is as important as the breach itself.

Why breach response is a product problem

Breach response is usually framed as a security team problem, and it is. But the DPDP-era framing adds a product dimension: the quality of your breach response depends on infrastructure you build in peacetime.

• A data map determines whether scoping takes hours or days
• The rights workflow determines whether you can tell affected users what data you hold on them
• The evidence trail determines what the Board sees when it asks

That is why Erasure's stack includes Data Maps, Rights cases, and Evidence. The same machinery that fulfils deletion requests in peacetime produces the scope and evidence a breach response needs. The data mapping post and the deletion workflow guide are the two halves of that story.

Common failure modes

The breaches that become enforcement cases share patterns:

• Detection lag: the breach sat undiscovered for weeks, so the notification clock was already blown
• No inventory: scoping took days because nobody knew where the data lived
• CERT-In missed: the team knew the DPDP rule but not the incident-reporting obligation
• No record: after the panic, nothing documented, so the response cannot be reconstructed

Every one of these is preventable with the right machinery and a runbook that names owners and templates.

The bottom line

DPDP breach notification is a 72-hour clock to the Data Protection Board, and CERT-In's directions add a second, faster clock for covered incidents. A single breach can trigger both, and the runbook has to handle both without dropping the faster one. Detection, scope, notification, and documentation are the four pillars, and the first three get dramatically easier with a data map.

For the broader DPDP operational picture, the compliance checklist covers where breach response sits, and the Rules explainer has the regulatory detail on Rule 7.