Two Clocks, One Breach: Data Breach Reporting in India Under CERT-In and the DPDP Act

Two Clocks, One Breach: Data Breach Reporting in India Under CERT-In and the DPDP Act

Most Indian companies picture data breach reporting in India as a single chore: something goes wrong, you tell a regulator, you move on. That picture is now wrong, and getting it wrong is costly. A serious incident at a typical Indian business today sets off two separate reporting duties, on two different clocks, to two different authorities. You have six hours to reach CERT-In and, once the DPDP Act's core provisions bite, roughly 72 hours to report a personal data breach to the Data Protection Board of India. Miss either deadline and you face a distinct penalty for that failure alone.

This matters right now because 2026 is the "build and test" year. Soft enforcement, meaning guidance and warnings rather than fines, is expected to run through this year, with full accountability arriving around 13 May 2027 when the Act's substantive obligations take effect. That gives you a window to build a breach process that answers to both regulators instead of just one. Spend it.

Where the two obligations come from

The first obligation predates the DPDP Act entirely. CERT-In, the national computer emergency response team, issued directions in April 2022 under Section 70B of the Information Technology Act, 2000. They require any organisation to report specified cyber security incidents within six hours of noticing them or being told about them. The list is broad: unauthorised access, data breaches, ransomware, attacks on servers and network infrastructure, and more. CERT-In does not care whether personal data was involved. It cares that a security incident happened on systems connected to Indian networks.

The second obligation is newer. Section 8(6) of the Digital Personal Data Protection Act, 2023 requires a Data Fiduciary to notify both the affected individuals and the Data Protection Board when a personal data breach occurs. The DPDP Rules, 2025, notified on 13 November 2025, spell out the mechanics in Rule 7. This track is specific to personal data, the phone numbers, health records, payment details and identity documents you hold about real people.

So one event, a ransomware attack that also exposes customer records, lands squarely in both regimes at the same moment.

The six-hour clock: CERT-In

Six hours is short. It starts when you become aware of the incident, not when you finish investigating it. In practice that means you rarely have the full forensic picture when the report is due, and CERT-In does not expect one. The initial report is technical and operational: what kind of incident, which systems are affected, when you noticed, what indicators of compromise you have, and your early assessment. You update as you learn more.

The trap here is treating the six-hour window as a security-team problem that legal and management can catch up on later. If your incident runbook does not already name who files the CERT-In report and how, six hours will pass while people search for the right form and email address.

The 72-hour clock: the Data Protection Board

The DPDP track works in two stages. On becoming aware of a personal data breach, you notify the Board and affected data principals without delay, with the facts known at that point. You then follow up with a fuller report inside roughly 72 hours covering the nature and scope of the breach, the categories and approximate number of people affected, the likely consequences, the steps you are taking to contain and remediate it, and the measures individuals can take to protect themselves.

Notice how different this content is from the CERT-In filing. CERT-In wants to understand the attack. The Board wants to understand the harm to people. You cannot copy-paste one report into the other. And the notification to affected individuals is a separate communication again, written in plain language they can act on, not regulator-speak.

Why "we told CERT-In" is not a defence

This is the single most common misreading I see. DPDP reporting does not replace the CERT-In obligation, and CERT-In reporting does not discharge your DPDP duty. They stack. A breach that is both a cyber security incident and a personal data compromise, which describes almost every real breach, triggers both.

The financial stakes make the stacking sharp. Under the DPDP Act's schedule, failure to take reasonable security safeguards can draw a penalty of up to ₹250 crore, and failure to notify a breach as required can draw up to ₹200 crore. Those are separate heads. An organisation that suffers a breach because its safeguards were weak, and then fails to report it properly, is exposed under both. CERT-In non-compliance carries its own consequences under the IT Act on top of that.

What this looks like in the first hour

When an incident hits, the clock you notice first is usually the tightest one, so build your process backward from six hours. A workable sequence looks like this: contain and preserve evidence, convene your response team, file the initial CERT-In report, assess whether personal data is involved, and if it is, prepare the Board notification and the message to affected individuals. Keep a written timeline from the first minute, because both regulators will ask when you knew what.

Decide in advance who owns each filing. Whether or not the Act formally requires you to appoint one, having a clear point person for privacy incidents, effectively a data protection officer role, removes the scramble. Keep the CERT-In reporting details, the Board's process, and draft notification templates in a folder your response team can reach at 2 a.m.

Getting ahead of both clocks

The businesses that will handle a breach calmly in 2027 are the ones treating 2026 as preparation time. Map what personal data you hold and where, so you can answer "who was affected" quickly. Write a single incident response plan that accounts for both reporting tracks rather than two disconnected ones. Rehearse it with a tabletop exercise. Check that your vendor contracts oblige processors to tell you fast, because their delay eats into your deadline.

A short readiness pass now is far cheaper than improvising during a live incident. Our DPDP compliance work and this readiness checklist are built to close exactly these gaps before enforcement arrives.

This article is general guidance for Indian businesses and is not legal advice; your specific obligations depend on your facts, so consult a qualified professional for your situation. If you want a clear starting point, work through our free checklist or get in touch for a readiness review.