DPDP Data Breach Reporting vs CERT-In: The 6-Hour and 72-Hour Incident Response Rules Indian Businesses Must Reconcile Before May 2027

At 11:30 PM on a weekday, your cloud provider's security team emails your CTO: an unauthorised party may have accessed a database containing customer records. By 5:30 AM, one legal clock has already run out. Not the one your privacy consultant has been briefing you about for the May 2027 DPDP deadline, but the one that has existed since 2022: the direction issued by the Indian Computer Emergency Response Team (CERT-In) on 28 April 2022, which requires covered organisations to report specified cyber incidents, including data breaches and data leaks, within six hours of noticing them or being brought to notice of them.

From 13 May 2027, when Rule 7 of the DPDP Rules, 2025 commences with the rest of the eighteen-month tranche, a second notification architecture will sit alongside it: affected Data Principals must be intimated without delay, the Data Protection Board must receive an initial intimation without delay, and a detailed report must follow within seventy-two hours unless the Board allows longer. These are separate obligations, to separate recipients, under separate statutes. Notifying CERT-In does not discharge the DPDP duty, and notifying the Board does not discharge the CERT-In duty. For the wider statutory frame, the pillar reference is Data Privacy Compliance in India: The DPDP Act Framework. This article deals with the hour when that framework is tested: how the two regimes actually fit together, and what a single incident-response workflow must look like.

One Breach Can Start Multiple Legal Clocks

The scenario above is deliberately ordinary, because the multi-regulator problem does not require an exotic attack. A compromised cloud instance, a misconfigured storage bucket, a ransomware event, a leaked database backup: each can simultaneously constitute a "cyber incident" under the Information Technology Act, 2000 and a "personal data breach" under the DPDP Act, 2023.

Map the same incident across the possible recipients:

Two design consequences follow immediately. First, the recipients want different things: CERT-In is building national cyber situational awareness and response; the Data Protection Board is supervising personal-data obligations; the Data Principal is being given information to protect herself. A notification drafted for one audience rarely satisfies another. Second, the clocks are not alternatives. The question after an incident is never "which regulator do we tell?" It is "which of these duties has this incident triggered, and in what order do we execute them?"

The CERT-In Six-Hour Rule Already Exists Today

This is the obligation with immediate force, and it is the one most likely to be missed precisely because DPDP commentary dominates the current conversation.

What the Direction Requires

CERT-In's directions of 28 April 2022, issued under Section 70B(6) of the IT Act and effective sixty days after issue, mandate that service providers, intermediaries, data centres, body corporates and Government organisations report cyber incidents listed in Annexure I within six hours of noticing the incident or being brought to notice of it. The Annexure I list runs to twenty categories and expressly includes data breach (xi) and data leak (xii), alongside unauthorised access, ransomware and malicious code attacks, attacks on applications such as e-commerce systems, and incidents affecting cloud systems. Reports go to CERT-In by email (incident@cert-in.org.in), phone or fax, in the published formats.

The same directions impose the surrounding machinery that determines whether the six-hour clock can be met at all:

• Synchronised clocks: ICT systems must connect to NIC or NPL Network Time Protocol servers, or an accurate traceable source, because incident timelines are meaningless if logs disagree about when events occurred.
• 180-day log retention: all ICT system logs must be enabled and maintained securely for a rolling 180 days within Indian jurisdiction, and produced with the incident report or on demand.
• Designated Point of Contact: every covered entity must nominate a PoC to interface with CERT-In, in the Annexure II format, and keep it updated.
• Five-year records for infrastructure providers: data centres, VPS, cloud and VPN providers must maintain validated subscriber and onboarding records for five years.

Failure to comply is punishable under Section 70B(7) of the IT Act, which carries imprisonment up to one year or a fine up to Rs. 1 lakh, or both.

Incomplete Facts Are Not a Reason to Wait

CERT-In's published FAQ guidance addresses the hesitation every incident team feels: what if we do not yet know the full picture? The answer is that the six-hour duty runs from noticing the incident, not from completing the investigation. Organisations should report the information available within the window and supplement it as the forensic picture develops. A "preliminary report" culture, where legal review delays filing until the facts are comfortable, is structurally incompatible with a six-hour clock.

DPDP Rule 7 Creates a Different Notification Architecture

The Three-Track Workflow

Rule 7 of the DPDP Rules, 2025, verified against the Gazette text, builds a notification system with three distinct tracks:

Read the architecture carefully. The Data Principal notification is not a courtesy; it is content-specified, including the safety measures she may take. The detailed Board report is not a resubmission of the initial intimation; it must include findings and remedial measures, which presumes forensic progress inside 72 hours. And the final element, a report regarding the intimations given to affected individuals, means the Board will be able to compare what you told it against what you told your users.

Rule 7 Is Not Yet Operative, and That Distinction Matters

Rule 7 sits in the eighteen-month commencement tranche under Rule 1: Rules 3, 5 to 16, 22 and 23 come into force on 13 May 2027, eighteen months after the Rules were published in the Gazette on 13 November 2025. From the date of this article, that is 215 days away. Until that date, a personal data breach does not attract the Rule 7 workflow, although CERT-In's six-hour duty and the Act's security-safeguards obligations continue to apply. Content that tells businesses the "72-hour DPDP duty" already applies is misstating the law, and the correction matters practically: businesses should use the remaining months to build the machinery, not to comply with a duty that has not yet commenced. The related preparation questions, what data you hold, where it sits and which processors touch it, are covered in What Indian Websites Get Wrong About DPDP.

Six Hours vs 72 Hours: Why Businesses Need One Incident-Response Workflow

The two regimes are easiest to see on a single timeline:

Two cautions belong in any honest treatment. First, the triggers are not identical: CERT-In's clock runs on "noticing" a listed cyber incident, while Rule 7 runs on "becoming aware" of a personal data breach. A ransomware event with no evidence of personal data exposure is squarely a CERT-In matter but may never become a DPDP one; an accidental emailing of a customer list to the wrong recipient may engage the DPDP architecture without fitting any Annexure I category. Each incident needs a classification decision, on the record, for each regime. Second, the content cannot simply be copy-pasted between regulators: the six-hour CERT-In filing is a technical incident report, while the Rule 7(1) intimation to Data Principals is a plain-language communication about consequences and self-protection.

The practical lesson is architectural: do not build a CERT-In response plan and a DPDP response plan independently. Build one escalation architecture that classifies the incident once and then executes every branch it triggers, with named owners for each filing. The organisations that will miss these clocks are not the ones without policies; they are the ones whose policies live in separate documents owned by separate teams.

Your SaaS Vendor Can Destroy Your Reporting Timetable

Both regimes run their clocks from when you notice the incident or are brought to notice of it, but in modern architectures the first party to notice is usually a vendor. If your cloud provider discovers the exfiltration on Monday and its contract obliges it to tell you "within 72 hours," your CERT-In clock has arguably been running the whole time, and your six-hour window may close before the vendor's notification obligation even matures.

This is the incident-response face of a risk we have analysed in The Hidden Liability in Your Tech Stack: Why Your SaaS Vendors Expose You Under the DPDP Act: under Section 8(1), the Data Fiduciary answers for processing undertaken on its behalf, irrespective of contrary contract terms. The breach-reporting layer adds a timing problem to that liability problem. Processor and vendor contracts therefore need escalation timelines measured in hours, not days: immediate notification on detection of any incident capable of affecting your data, defined channels and named contacts, an obligation to share forensic indicators as they emerge rather than in a final report, and cooperation duties through the 72-hour detailed-report window. A vendor contract whose incident clause is slower than your fastest regulatory clock is not a risk transfer; it is a deadline trap.

What Should Be Prepared Before a Breach Occurs?

Incident response under a six-hour regime cannot be improvised. The preparation that matters, in buildable form:

The unglamorous items on this list are the decisive ones. The six-hour CERT-In filing fails on item 9 more often than on legal analysis, and the Rule 7(1) Data Principal intimation fails on item 5, because plain-language consequence drafting is genuinely hard to do at 2 AM without a template.

The May 2027 Breach-Response Readiness Test

Strip the frameworks back to one boardroom question: if your cloud provider emails your CTO at 11:30 PM tonight saying customer records may have been exfiltrated, does everyone in your organisation know who must make which legal decision before 5:30 AM?

If the answer is yes, the remaining work is to extend that muscle to the DPDP tracks before they commence on 13 May 2027: the Board intimation owner, the Data Principal template, and the 72-hour detailed-report drill. If the answer is no, the immediate exposure is not the future DPDP regime at all; it is the CERT-In direction that has been law since 2022. Either way, the correct build is a single workflow that knows which regulatory branches to trigger, tested before it is needed, with vendor contracts that escalate faster than your fastest clock. Breach response is where data protection stops being policy and becomes operations, and it is the one part of compliance that cannot be remediated after the fact.

This article is published for general informational purposes and reflects the IT Act, 2000, the CERT-In directions of 28 April 2022, and the DPDP Act, 2023 and DPDP Rules, 2025 as notified. It does not constitute legal advice on any specific set of facts.