Breach notification under the DPDP Act: what the clock actually starts on

One of the most common operational mistakes we see is treating "we noticed something odd in the logs" and "we have confirmed a personal data breach" as the same trigger. They aren’t, and conflating them either causes panic-notifications for non-events or delays for real ones.

A workable internal process separates detection (a security or engineering signal) from triage (does this actually involve personal data, and is it a breach as the Act defines it) from notification (informing the Data Protection Board and affected Data Principals as required).

Vendor and processor relationships are usually the weakest link here — your own detection is only as fast as your slowest data processor’s obligation to tell you something happened on their end. Contractual notification SLAs with processors are not optional if you want your own timelines to be realistic.

This is precisely the kind of end-to-end incident playbook the DCDPO track works through in detail, including how it interacts with a broader security incident response process most engineering teams already have.