Your Startup Had a Data Breach. Here Is What You Are Legally Required to Do
A startup data breach can trigger two separate obligations. CERT-In requires reporting specified cybersecurity incidents within 6 hours of noticing them, a rule in force since 28 June 2022. The DPDP Act adds its own Data Protection Board notification duty under Rule 7, though that duty does not take effect until 14 May 2027.
The Phone Call Nobody Wants to Make
It usually starts with a slack message from an engineer at 2 AM, or an email from a security researcher who found your S3 bucket open to the world. Once you confirm it is real, the legal clock starts running whether you have read the DPDP Act or not. Most Indian founders learn the compliance requirements for a data breach during the breach itself, which is the worst possible time to be reading law.
Here is what actually applies, stripped of jargon.
Two Regulators, Two Different Obligations
If your startup handles personal data of Indian users, a breach can trigger duties under two separate frameworks: the Digital Personal Data Protection Act, 2023 (DPDP Act) and CERT-In's cybersecurity incident reporting rules. They are not the same thing, and satisfying one does not automatically satisfy the other.
CERT-In (the Indian Computer Emergency Response Team, under MeitY) has required reporting of specified categories of cybersecurity incidents since its 2022 directions came into force. Its scope covers a defined list of incident types: unauthorised access, data breaches, ransomware, DDoS attacks, and several others. The reporting window is famously tight, incidents in the listed categories must be reported to CERT-In within 6 hours of noticing them. That timeline has caught more than one well-funded company off guard because "noticing" starts the clock, not "confirming."
The DPDP Act sits on top of this for personal data specifically, though not yet in practice. Section 8(6) of the Act, operationalized through Rule 7 of the DPDP Rules, 2025, requires a Data Fiduciary (that is you, if you collect or process personal data) to notify the Data Protection Board of India and the affected individuals when a personal data breach occurs. The DPDP Rules, 2025 were notified in the Official Gazette on 13 November 2025 with a staggered three-phase commencement schedule, and Rule 7's breach-notification duty falls in the final phase, which only takes effect on 14 May 2027. As of now, that obligation is not yet enforceable, while CERT-In's 6-hour rule has been in force since 28 June 2022 and applies regardless of where the DPDP Rules stand.
Once Rule 7 does take effect, the timelines are concrete rather than vague: the initial notification to the Board and to affected individuals must happen "without delay," and the Board's detailed follow-up report is due within 72 hours, extendable at the Board's discretion. Do not rely on a specific hour count you saw in a LinkedIn post for the DPDP side, and do not assume the obligation is live today. Confirm the current commencement status for your situation before you act, ideally with someone who tracks the rules as they get notified and clarified.
What You Actually Have to Report
Under CERT-In, the report typically needs to capture what happened: the nature of the incident, systems affected, indicators of compromise, and the timeline as you understand it at that point. You are not expected to have a full forensic picture in 6 hours. You are expected to have started the process and to be transparent about what you know and do not yet know.
Under the DPDP Act, the notification to affected users needs to actually help them, not just cover you legally. That means telling people in plain language what data was involved, what you are doing about it, and what they should do on their end (change a password, watch for phishing, whatever is relevant). A notice stuffed with legal hedging that nobody can parse defeats the point of the requirement.
Why the Panic Response Fails
The instinct after a breach is to lock down engineering first and figure out legal obligations later. That order gets startups into trouble. Evidence gets overwritten by well-meaning engineers trying to "clean up" systems. Nobody assigns a single person to own external communication, so users hear conflicting things from different channels. And because nobody knows the reporting deadline going in, the 6-hour CERT-In window is often blown before anyone has even looked it up.
An incident response plan does not need to be a fifty-page document. At minimum it should name who declares an incident, who talks to CERT-In, who drafts the user notice, and where your logs and backups live so you are not searching for them mid-crisis. Write it once, when you are calm, and it pays for itself the one time you need it.
Getting This Right Before You Need To
Breach response sits at the intersection of engineering, communications, and law, and getting the legal piece wrong compounds the damage of the breach itself. If your startup is building an incident response plan, or you are staring at an actual breach right now and need to know what applies to you specifically, Vaksy can connect you with a verified advocate on the platform who can walk through your situation in your own language and help you meet the right deadlines with the right regulator.
Get this reviewed for your case. General guides don't know your state, your facts, or your deadline. Vaksy matches you with a verified advocate on the platform who can review your situation and draft what you need, in your own language.