DPDP Breach Notification: The 72-Hour Rule, CERT-In vs DPBI, and What You Must Report

You know what a personal data breach is. You know the penalties are severe. What you probably do not have is a clear, step-by-step answer to the question that matters at 2 AM when your security team calls: who do I notify, what do I tell them, and how many hours do I have before we are non-compliant?

That question is harder to answer than it should be, because India now runs two parallel breach reporting regimes with different timelines, different authorities, and different content requirements. One gives you 6 hours. The other gives you 72. And depending on your industry, there may be a third or fourth reporting obligation stacked on top.

This post breaks down every obligation, maps the overlaps, and gives you the operational playbook your team needs before an incident hits.

Key Takeaways

• The DPDP Act 2023 requires Data Fiduciaries to notify the Data Protection Board of India (DPBI) "without delay" and submit a detailed report within 72 hours of becoming aware of a personal data breach.
• CERT-In Directions (April 2022) separately require reporting cybersecurity incidents within 6 hours of detection to CERT-In, under the IT Act 2000.
• A single data breach can trigger both obligations simultaneously. They are not alternatives; you report to both.
• Financial institutions face additional sector-specific reporting to RBI, SEBI, or IRDAI, often within 2-6 hours, on top of the DPDP and CERT-In requirements.
• Failure to notify the DPBI and affected Data Principals of a breach carries a penalty of up to ₹200 crore. Inadequate security safeguards that caused the breach carry up to ₹250 crore.

What Counts as a "Personal Data Breach" Under DPDP?

Before anything else, you need to know what triggers the notification obligation.

Section 2(u) of the DPDP Act 2023 defines a personal data breach as "any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction of or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data."

That definition is broad by design. It covers the obvious scenarios (a database exfiltrated by an attacker, a ransomware encryption event) and the less obvious ones (an employee accidentally emails a customer spreadsheet to the wrong recipient, a misconfigured S3 bucket that was publicly accessible for three days before anyone noticed).

Three points to register here.

First, the definition includes "loss of access." A ransomware attack that encrypts your customer database qualifies as a breach even if the data was never exfiltrated. You lost access. That is sufficient.

Second, "accidental" events count. A breach does not require malicious intent. A developer who pushes a debug log containing personal data to a public repository has caused a personal data breach under this definition.

Third, there is no materiality threshold in the Act itself. The DPDP Act does not distinguish between a breach affecting 10 records and one affecting 10 million. Both trigger the notification obligation. The DPBI may ultimately develop severity-based guidance, but as of February 2026, the statutory text does not provide that flexibility.

Who Must You Notify? The Dual-Reporting Regime Explained

This is where most businesses get confused. India does not have a single breach reporting authority. Depending on the nature of the incident, you may need to notify two, three, or even four bodies.

Here is the complete map:

Authority	Legal Basis	Timeline	What You Report	Who Must Report
Data Protection Board of India (DPBI)	Section 8(6), DPDP Act 2023 + DPDP Rules 2025	Initial: "without delay." Detailed report: within 72 hours	Personal data breach (see Section 2(u))	Every Data Fiduciary
Affected Data Principals	Section 8(6), DPDP Act 2023 + DPDP Rules 2025	"Without delay"	Nature of breach, likely impact, measures taken, protective steps	Every Data Fiduciary
CERT-In	CERT-In Directions, April 2022 (under IT Act 2000, Section 70B)	Within 6 hours of detection	Cybersecurity incidents including data breaches, unauthorized access, malware	All entities (service providers, intermediaries, data centres, body corporates, government organisations)
Sector regulator (RBI / SEBI / IRDAI)	Sector-specific circulars and frameworks	Typically 2-6 hours	Cybersecurity incidents affecting regulated operations	Regulated financial entities only

The critical insight: CERT-In and DPBI are parallel obligations, not alternatives. A single data breach that involves both a cybersecurity incident and personal data compromise, which is almost every real-world breach, triggers reporting to both CERT-In (within 6 hours) and DPBI (initial notification without delay, detailed report within 72 hours).

For a deeper understanding of Data Fiduciary obligations, including breach notification, see our guide to Data Fiduciary obligations under DPDP.

What is the 72-Hour Rule Under DPDP?

The DPDP Rules 2025 operationalise Section 8(6) of the Act with a two-stage notification process to the DPBI.

Stage 1: Initial Intimation ("Without Delay")

The moment a Data Fiduciary becomes aware of a personal data breach, it must provide an initial intimation to the DPBI. The Rules specify this must happen "without delay," which in practice means as soon as your incident response team confirms an incident has occurred.

The initial intimation should include:

• A description of the breach: its nature, extent, timing, and location
• The likely impact of the breach
• Any immediate containment measures already taken

This initial report is intentionally brief. The purpose is to put the DPBI on notice that an incident has occurred. You are not expected to have completed your forensic investigation at this stage.

Stage 2: Detailed Report (Within 72 Hours)

Within 72 hours of becoming aware of the breach, the Data Fiduciary must submit a comprehensive incident report to the DPBI. This is the substantive filing. The Rules require it to include:

1. Updated breach description: Nature, extent, timing, location, and impact (reflecting what you have learned since the initial intimation)
2. Root cause analysis: The facts, circumstances, and reasons that led to the breach
3. Affected scope: Categories and volume of personal data involved, number of Data Principals affected, systems and period affected
4. Detection timeline: When the breach occurred, when it was detected, and the gap between the two
5. Remediation measures: Actions taken or proposed to contain the breach and mitigate risk to Data Principals
6. Recurrence prevention: Steps to prevent similar incidents in the future
7. Responsible parties: Identity of the person or entity that caused the breach, if known
8. Notification summary: A summary of notifications issued to affected Data Principals

The 72-hour clock starts when you "become aware" of the breach. Not when your security operations centre first detects an anomaly. Not when a third-party vendor informs your support team six days after the fact. The clock starts at the point where a responsible person in your organisation identifies that a personal data breach has occurred. This distinction matters, and you should document the precise moment awareness crystallised.

What Happens If 72 Hours Is Not Enough?

The Rules include a provision allowing the DPBI to extend the deadline, but only if the Data Fiduciary requests it with justification. If your incident involves complex forensics (multi-vector attack, supply chain compromise, encrypted exfiltration that requires decryption to assess scope), request the extension proactively. The worst outcome is missing the deadline without having communicated with the Board.

The DPBI may also request follow-up reports as the investigation continues. Breach notification under DPDP is not a one-time filing; it is a continuing disclosure obligation until remediation is complete.

What Must You Tell Affected Data Principals?

The DPDP Rules 2025 also specify what you must communicate to the individuals whose data was compromised. This notification must be delivered through the Data Principal's user account on your platform, or through any registered mode of communication (email, SMS, or the contact method they provided during data collection).

The notification must include:

• What happened: A clear, plain-language description of the breach, including its nature, extent, and timing
• What it means for them: The likely consequences of the breach for the Data Principal
• What you are doing about it: Measures taken or being implemented to contain the breach and mitigate risk
• What they should do: Specific, actionable safety measures the Data Principal can take to protect themselves
• Who to contact: Business contact details for a person who can respond to queries about the breach

Two operational notes. First, the notification must be in "clear and plain language." Legalese-heavy breach notifications that obscure more than they reveal will not satisfy this requirement. Second, the Rules do not specify a separate deadline for notifying Data Principals, but the "without delay" standard from Section 8(6) applies.

How Does CERT-In Reporting Work Alongside DPDP?

The Indian Computer Emergency Response Team operates under Section 70B of the Information Technology Act, 2000. In April 2022, CERT-In issued mandatory Directions that require all entities to report cybersecurity incidents within 6 hours of detecting or being notified of the incident.

The 6-Hour Clock

The CERT-In timeline is significantly more aggressive than the DPDP timeline. Six hours from detection, not six hours from classification or investigation. If your SOC detects a breach indicator at 3:15 AM on a Tuesday, the CERT-In report is due by 9:15 AM.

Reportable incidents under the CERT-In Directions include:

• Targeted scanning or probing of critical networks
• Compromise of critical systems or information
• Unauthorised access to IT systems or data
• Defacement of websites or intrusion into web applications
• Malware deployment (including ransomware)
• Data breaches and data leaks
• Attacks on servers, databases, and network infrastructure
• Identity theft, spoofing, and phishing attacks
• Denial of service and distributed denial of service attacks

Note the overlap: "data breaches and data leaks" appear on both the CERT-In list and the DPDP definition. In practice, most personal data breaches will trigger both reporting obligations.

Key Differences Between CERT-In and DPBI Reporting

Dimension	CERT-In	DPBI (under DPDP)
Legal basis	IT Act 2000, Section 70B + CERT-In Directions 2022	DPDP Act 2023, Section 8(6) + DPDP Rules 2025
Reporting timeline	6 hours from detection	Initial: without delay. Detailed: 72 hours from awareness
Scope	All cybersecurity incidents (including but not limited to data breaches)	Personal data breaches specifically
Who must report	All entities: service providers, intermediaries, data centres, body corporates, govt orgs	Data Fiduciaries (entities determining purpose and means of personal data processing)
Must notify individuals?	No individual notification required	Yes, must notify affected Data Principals
Penalty for non-reporting	Up to 1 year imprisonment + INR 1 lakh fine (IT Act)	Up to ₹200 crore (DPDP Act Schedule, Item 2)
Log retention	ICT system logs for 180 days, synced to Indian NTP servers	Not separately specified under DPDP Rules
Focus	National cybersecurity resilience and incident coordination	Individual data protection and privacy rights

The practical consequence: your incident response plan must account for both timelines. CERT-In is the first deadline you will hit. The DPBI gets the more detailed submission.

What About Financial Institutions? The Triple-Reporting Problem

If you operate in financial services, the reporting landscape adds another layer. RBI-regulated entities (banks, NBFCs, payment system operators), SEBI-regulated entities (market infrastructure institutions, brokers, depositories), and IRDAI-regulated entities (insurers, intermediaries) each face sector-specific incident reporting requirements.

Regulator	Reporting Timeline	Additional Requirements
RBI	2-6 hours for critical incidents; next working day for material incidents	Root cause analysis, Format for Incident Reporting Exchange (FIRE), mandatory CERT-In co-reporting
SEBI (CSCRF)	6 hours initial email; 24 hours via SEBI Incident Reporting Portal	Covers ransomware, data breaches, service disruptions, fraud incidents
IRDAI	6 hours (reduced from previous 24-hour window)	ICT logs retained for 180-day rolling period, mandatory CERT-In co-reporting

A bank that suffers a personal data breach may need to file four separate reports: CERT-In (6 hours), RBI (2-6 hours), DPBI (initial without delay, detailed within 72 hours), and individual Data Principal notifications (without delay). Each has its own format, content requirements, and authority to contact.

If your organisation falls into a regulated sector, your incident response plan needs pre-built templates for each authority. You cannot draft four different regulatory filings from scratch in the middle of a live incident.

What Are the Penalties for Failing to Notify?

The DPDP Act's penalty framework for breach-related failures operates at two levels:

Failure Type	Maximum Penalty	DPDP Act Reference
Failure to implement reasonable security safeguards, resulting in a breach	₹250 crore	Schedule, Item 1
Failure to notify DPBI and affected Data Principals of a breach	₹200 crore	Schedule, Item 2

These are per-violation ceilings, not annual caps. A Data Fiduciary that both failed to implement adequate security (causing the breach) and then failed to report it (trying to cover it up) could face penalties under both items, potentially reaching ₹450 crore from a single incident.

The Data Protection Board has discretion in setting actual penalty amounts based on factors including:

• The nature, gravity, and duration of the contravention
• The type and volume of personal data affected
• Whether the Data Fiduciary made good-faith efforts to comply
• Whether voluntary corrective action was taken
• Aggravating and mitigating circumstances

Separately, non-compliance with CERT-In Directions carries penalties under the IT Act: imprisonment for up to one year and a fine of up to INR 1 lakh. The penalty quantum is far lower, but it carries criminal liability, which the DPDP Act does not.

For a full breakdown of the DPDP penalty regime, including how the Board calculates fines, see our DPDP Act 2023 complete guide.

The Breach Response Playbook: Step by Step

Here is the operational sequence your team should follow when a potential personal data breach is detected. This is the minimum viable playbook; you should adapt it to your organisation's size, sector, and risk profile.

Phase 1: Detection and Triage (Hours 0-2)

Step 1: Confirm the incident. Your SOC, IT team, or a third-party vendor has flagged an anomaly. The first task is to determine whether this is a confirmed personal data breach or a false positive. Assign an incident lead immediately.

Step 2: Document awareness. Record the exact date, time, and person who confirmed the breach. This timestamp starts both the CERT-In 6-hour clock and the DPDP 72-hour clock. Be precise. "Sometime Tuesday morning" will not hold up to regulatory scrutiny.

Step 3: Assess initial scope. Before filing anything, get a rough answer to: what systems are affected, what categories of personal data are involved, and how many Data Principals are potentially impacted? This assessment will be incomplete. That is acceptable at this stage.

Step 4: Activate containment. Isolate affected systems. Revoke compromised credentials. Block attack vectors. Preservation of evidence and stopping the bleeding happen simultaneously.

Phase 2: Regulatory Notifications (Hours 2-6)

Step 5: File CERT-In report. Within 6 hours of detection, submit your incident report to CERT-In. This report covers the cybersecurity incident; it does not need to address personal data specifics in the level of detail DPBI requires.

Step 6: File sector regulator report (if applicable). If you are RBI/SEBI/IRDAI-regulated, your sector-specific report is due in the same window. Use your pre-built template.

Step 7: File DPBI initial intimation. Submit the initial notification to the Data Protection Board. Include: nature of breach, extent, timing, location, likely impact, and immediate containment measures. Keep it factual and concise.

Phase 3: Investigation and Detailed Reporting (Hours 6-72)

Step 8: Conduct forensic investigation. Bring in your forensics capability (internal or external). Determine root cause, full scope of data affected, attack vector, timeline of unauthorized access, and whether data was exfiltrated or merely exposed.

Step 9: Notify affected Data Principals. As soon as you have enough information to provide meaningful notification, communicate with affected individuals. Do not wait until hour 71. The "without delay" standard means as soon as is practicable given the facts you have.

Step 10: Prepare and submit DPBI detailed report. Within 72 hours of awareness, file the comprehensive report covering all elements specified in the DPDP Rules (root cause, affected scope, detection timeline, remediation, recurrence prevention, responsible parties, and notification summary).

Phase 4: Remediation and Follow-Up (Hours 72+)

Step 11: Implement remediation. Fix the vulnerability or gap that allowed the breach. Update security controls. Patch the systems.

Step 12: Respond to regulatory queries. Both CERT-In and DPBI may request follow-up information. The DPBI explicitly reserves the right to require additional reports until remediation is complete. Be responsive.

Step 13: Conduct post-incident review. Once the incident is closed, run a structured post-mortem. Document what happened, what went wrong, and what you are changing. Update your incident response plan based on lessons learned.

Step 14: Update your breach log. Maintain a register of all personal data breaches, including near-misses. This log becomes critical evidence of good-faith compliance if the DPBI ever audits your breach record.

Common Mistakes in Breach Notification

Having helped organisations build incident response programs, I see the same failures repeatedly.

Mistake 1: Waiting to notify until the investigation is complete. The DPDP Rules explicitly require initial notification "without delay." The 72-hour window is for the detailed report, not for your first communication with the DPBI. Organisations that wait three days to file anything are already non-compliant from hour one.

Mistake 2: Forgetting the CERT-In obligation. Many teams treat DPDP as the primary reporting framework and overlook that CERT-In has a much tighter 6-hour deadline for the same incident. These are separate legal obligations under separate laws.

Mistake 3: Sending generic data principal notifications. "We experienced a security incident and take your privacy seriously" is not a valid notification under the DPDP Rules. The notification must describe the specific breach, its consequences for the individual, and actionable steps they can take. Generic templates fail this standard.

Mistake 4: Not documenting the awareness timestamp. The 72-hour clock starts when you "become aware." If you cannot prove when awareness occurred, the DPBI may default to the earliest indicator in your logs, which could mean your report was late before you even knew you were supposed to be counting.

Mistake 5: Treating Data Processor breaches as someone else's problem. If your Data Processor suffers a breach affecting personal data you entrusted to them, the notification obligation falls on you, the Data Fiduciary. Section 8(1) is clear: compliance responsibility stays with the Fiduciary, irrespective of any contractual arrangement. Your vendor agreements should include mandatory breach notification clauses requiring the Processor to inform you immediately.

Frequently Asked Questions

Does every data breach require notification to the DPBI under the DPDP Act?

As of February 2026, the DPDP Act 2023 does not include a materiality threshold for breach notification. Section 8(6) requires notification for "a personal data breach," regardless of scale. Whether the breach affects 10 records or 10 million, the notification obligation is triggered. The DPBI may develop severity-based guidance in the future, but the current statutory text requires notification for every confirmed personal data breach.

Do I report to CERT-In or the DPBI, or both?

Both, in most cases. CERT-In reporting (within 6 hours) covers cybersecurity incidents under the IT Act 2000. DPBI reporting (initial without delay, detailed within 72 hours) covers personal data breaches under the DPDP Act 2023. A data breach that involves both a cybersecurity incident and personal data compromise triggers parallel obligations to both authorities. They are governed by separate laws, have separate timelines, and require separate filings.

What happens if I discover a breach that occurred weeks or months ago?

The notification timelines start when you "become aware" of the breach, not when the breach itself occurred. If a forensic investigation reveals that data was exfiltrated three months ago but you only confirmed this today, the 72-hour DPBI clock and the 6-hour CERT-In clock start from today's confirmation. Document the discovery carefully, including the detection gap, as this will be relevant to the DPBI's assessment of your security safeguards under Section 8(4).

Are Data Processors required to notify the DPBI independently?

No. The obligation to notify the DPBI and affected Data Principals rests with the Data Fiduciary, not the Data Processor. However, the Data Processor must inform the Data Fiduciary of the breach without delay. Your data processing agreements should include explicit clauses requiring the Processor to notify you immediately upon becoming aware of any incident affecting the personal data you have entrusted to them, with enough detail to enable your regulatory filings.

Is the 72-hour deadline calculated in calendar hours or business hours?

Calendar hours. The 72-hour window runs continuously from the moment of awareness, including weekends, public holidays, and outside business hours. If your team confirms a breach at 6 PM on a Friday, the detailed DPBI report is due by 6 PM on Monday. This is why your incident response plan, templates, and escalation procedures must be operational around the clock.

Simplify Your DPDP Compliance

This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.

Building a breach response program that satisfies both DPDP and CERT-In requirements takes preparation: documented procedures, pre-built templates, trained staff, and systems that detect incidents before auditors do. ComplyZero's self-serve platform helps Indian businesses implement DPDP compliance in minutes, not months: automated consent management, privacy notices in 22 Indian languages, and audit-ready compliance records that hold up when regulators come asking.

Join the waitlist to get early access before enforcement begins in May 2027.