DPDP Breach Notification Requirements

A breach doesn't start the clock when your legal team finishes assessing it. It starts the moment someone on your team can reasonably say "yes, this happened." That single distinction trips up more organisations than any other part of Rule 7 of the Digital Personal Data Protection Rules, 2025, and it's exactly why we're writing this piece as a standalone, definitive guide rather than folding it into a broader compliance overview.

Most breach notification content available right now either paraphrases Rule 7 loosely or buries the actual sub-clause requirements under generic incident-response advice. This guide does neither. We go clause by clause through what Rule 7 requires, when it requires it, and what happens if you get it wrong, grounded directly in the statutory text rather than secondary summaries.

If you haven't yet read our broader guide to DPDP compliance in India, that's a useful starting point before this one. This piece assumes you already know the basics and want the specific mechanics of breach notification.

Table of Contents

• What Counts as a Personal Data Breach?
• Who Must Notify, and Who Gets Notified?
• When Does the Clock Start, and How Long Do You Have?
• What Must Each Notification Actually Contain?
• Where Do These Rules Come From, and When Do They Take Effect?
• Why "It Was Minor" Isn't a Defence
• How Much Does Getting This Wrong Cost?
• How to Build a Breach Notification Process That Actually Works
• Mistakes Businesses Make With Breach Notification
• FAQs

1. What Counts as a Personal Data Breach?

The DPDP Act defines a personal data breach broadly: any unauthorised processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises its confidentiality, integrity, or availability.

Notice what's absent from that definition. There's no carve-out for accidental internal mishaps versus malicious external attacks. There's no minimum number of records. An employee emailing a spreadsheet to the wrong internal address, if that spreadsheet contains personal data and the recipient wasn't authorised to see it, can meet this definition just as much as a ransomware attack does. The Act doesn't grade breaches by how they happened. It grades them by what happened to the data.

This matters because a lot of organisations mentally categorise "real breaches" as external, malicious, and large-scale, and treat everything else as an internal matter to quietly fix. That instinct doesn't hold up against the statutory definition, and it's the first mistake we'll return to later in this guide.

2. Who Must Notify, and Who Gets Notified?

Section 8(6) of the DPDP Act places the notification duty on the Data Fiduciary, the entity that decides the purpose and means of processing personal data, regardless of whether the breach actually originated with the Fiduciary or with a processor acting on its instructions. If your vendor's server gets compromised and it's processing data on your behalf, the notification obligation still sits with you.

Two recipients are mandatory, and this is where the DPDP framework departs meaningfully from other privacy regimes:

• The Data Protection Board of India, in every case, regardless of scale.
• Every affected Data Principal, also in every case, not just when the breach crosses some risk threshold.

Compare this to the GDPR, where individual notification is required only when a breach is likely to result in a "high risk" to the individual's rights and freedoms. The DPDP Act has no equivalent carve-out. If personal data was compromised, both the regulator and the people affected have to be told.

3. When Does the Clock Start, and How Long Do You Have?

This is the part organisations most commonly get wrong, so it's worth being precise. Rule 7 sets up two parallel notification tracks that both start at the same moment: when the Data Fiduciary becomes aware of the breach. Not when the investigation concludes. Not when the root cause is confirmed. When you know, to the best of your knowledge, that a breach occurred.

Track 1, the Data Principal notification, runs on "without delay." Rule 7(1) doesn't give you a fixed number of hours here; it uses the phrase "without delay," which is a stricter, more immediate standard than a 72-hour window. There's no grace period built in.

Track 2, the Board notification, runs in two stages. Rule 7(2)(a) requires an initial intimation "without delay," covering the nature, extent, timing, location, and likely impact of the breach, essentially a brief flag that something has happened. Rule 7(2)(b) then requires a detailed, updated report within 72 hours of becoming aware, or within a longer period if the Board grants an extension on a written request. That 72-hour window is for the comprehensive report, not the first alert.

A useful way to think about it: you flag first, on both tracks, almost immediately. Then you follow up with the full picture to the Board within three days, unless you've asked for and received more time.

4. What Must Each Notification Actually Contain?

The content requirements differ meaningfully between the two recipients, because they're being told for different reasons. The Data Principal needs to know how this affects them personally. The Board needs enough detail to assess systemic risk and regulatory response.

To the Data Principal, Rule 7(1) requires:

• A description of the breach, its nature, extent, and timing
• The consequences likely to arise for that specific individual
• The mitigation measures already implemented or underway
• Safety steps the individual can take to protect themselves
• Business contact information for someone who can answer their questions

To the Board, Rule 7(2) requires, across its two stages:

• Stage 1: nature, extent, timing, location, and likely impact
• Stage 2, within 72 hours: updated and detailed information on the above, the broad facts and circumstances leading to the breach, mitigation measures taken or proposed, findings regarding who caused it, remedial steps to prevent recurrence, and a summary of the notifications sent to affected Data Principals

One detail worth flagging for anyone building the notification workflow: Rule 7 defines "user account" broadly enough to include any profile, handle, email address, or phone number a Data Principal registered to access your service. That's your valid notification channel, and it means "we didn't have their current address" is a weaker excuse than it might have been under other frameworks.

5. Where Do These Rules Come From, and When Do They Take Effect?

Rule 7, titled "Intimation of personal data breach," sits within the Digital Personal Data Protection Rules, 2025, which the Ministry of Electronics and Information Technology notified on 13 November 2025. Rule 6, which governs the reasonable security safeguards Data Fiduciaries must maintain to prevent a breach in the first place, sits alongside it and is worth reading in tandem, since the two rules cover prevention and response respectively.

Here's the detail that changes how urgently you should treat this: Rule 7 doesn't commence immediately. It falls within the Rules' third and final commencement phase, an eighteen-month period for phased compliance that runs from the November 2025 notification date, landing on 13 May 2027. Until then, breach notification isn't yet legally enforceable under the Rules, though Section 8(6) of the Act itself establishes the underlying duty.

That gap between "not yet enforceable" and "not yet worth building" is exactly where organisations tend to make a costly assumption. We'll come back to that in the readiness section below. For context on how this phased timeline fits the wider compliance calendar, including how it interacts with Significant Data Fiduciary obligations, see our guide on Significant Data Fiduciary obligations under the DPDP Rules.

6. Why "It Was Minor" Isn't a Defence

We touched on this above, but it deserves its own section because it's the single biggest mental adjustment organisations coming from a GDPR-influenced mindset need to make.

Under GDPR, a genuinely low-risk incident, say, a single record briefly exposed and immediately contained, might reasonably be assessed as not requiring individual notification. Under the DPDP Act, that same reasoning doesn't apply. There's no statutory mechanism for a Data Fiduciary to internally decide a breach is too minor to notify. If the definition is met, both notifications are owed.

Encryption doesn't create an exemption either. A breach involving properly encrypted personal data still meets the statutory definition if unauthorised access, disclosure, or loss occurred. Strong encryption is good practice and genuinely reduces the practical risk to affected individuals, but it isn't a legal safe harbour that removes the notification duty.

The practical implication is that your breach assessment process needs a low bar for "does this trigger notification," not a high one. Organisations that build their incident response around a materiality judgment call are building around a standard the DPDP Act doesn't actually offer.

7. How Much Does Getting This Wrong Cost?

The Schedule to the DPDP Act sets separate penalty ceilings depending on what specifically went wrong:

• Up to ₹250 crore for failing to implement reasonable security safeguards under Section 8(5), the provision that covers prevention.
• Up to ₹200 crore for failing to notify a breach under Section 8(6), the provision this guide covers.
• Up to ₹50 crore for a breach of any other provision of the Act or Rules not separately specified.

These aren't mutually exclusive. An organisation with genuinely weak security controls that also fails to notify a resulting breach on time can face penalties under both Section 8(5) and Section 8(6) for the same underlying incident. Weak prevention and slow disclosure compound each other; they don't get bundled into a single, smaller fine. For the full penalty schedule and how the Data Protection Board actually runs an inquiry before imposing one, see our guides on the DPDP Act's penalty and enforcement structure and how the Data Protection Board's role and process work.

8. How to Build a Breach Notification Process That Actually Works

Rule 7's enforceability date of May 2027 is not a reason to wait, for the same reason a fire drill isn't scheduled for the week a fire is expected. A few concrete steps make sense starting now:

• Define "awareness" internally before you need the definition. Write down, in your incident response policy, what specifically constitutes your organisation "becoming aware" of a breach, whose confirmation triggers it, and who gets notified internally within the first hour. Ambiguity here is exactly what causes the 72-hour clock to quietly run out before anyone realises it started.
• Pre-draft your notification templates. Both the Data Principal and Board notifications have fixed, known content requirements. There's no reason to draft either from scratch during an actual incident. A template with placeholders for the specific facts lets your team move in minutes, not hours.
• Map every registered communication channel per user. Since "user account" covers emails, phone numbers, and app handles, your breach response needs to know, systematically, which channels are actually live and monitored for a given affected individual, not just which one was collected first.
• Build the Board's Stage 2 report structure into your incident response plan now. The six-item detailed report, root cause, mitigation, findings, remedial steps, and a notification summary, maps almost exactly onto a standard post-incident review. If your security team already produces this kind of report internally, the compliance version is a formatting exercise, not a new process.
• Treat encryption as risk reduction, not exemption. Keep investing in it, but don't let it quietly become the reason a breach goes unreported.

This is precisely the operational gap RuleExpert's Breach Management module is built to close: structured incident intake, investigation workflows, and templated notifications aligned to Rule 7's exact content requirements, so your team isn't drafting a statutory notice under pressure for the first time during a real incident. You can see how the fuller platform fits together on our DPDP compliance solution page. If you'd rather walk through your specific incident response gaps directly, book a demo with RuleExpert and we'll map them against your actual systems.

9. Mistakes Businesses Make With Breach Notification

• Waiting for full certainty before notifying. The obligation triggers on awareness, not on a completed forensic investigation. Teams that wait to "know everything" before notifying are already past the "without delay" standard by the time they act.
• Treating internal mishaps as exempt. An accidental internal disclosure meets the same statutory definition as an external attack. Quietly fixing it internally without notification isn't a compliance option.
• Assuming encryption removes the obligation. It reduces harm; it doesn't remove the duty to notify.
• Applying a GDPR-style risk filter. Deciding a breach is "too minor" to notify individuals is a judgment call the DPDP Act doesn't grant you.
• Confusing the two Board deadlines. The initial "without delay" alert and the 72-hour detailed report are different obligations with different content requirements. Treating them as one deadline means the first one is usually missed.
• Not knowing which contact channels count. Notification sent only to a primary registered email, when the Data Principal has since gone quiet on that channel but is active on another registered one, may not satisfy the "best of its knowledge" standard Rule 7 sets.
• Building the process only after Rule 7 is enforceable. May 2027 is the enforcement date, not a reasonable start date for building the underlying capability.

10. Frequently Asked Questions

• What is the DPDP breach notification requirement? Under Section 8(6) of the DPDP Act and Rule 7 of the DPDP Rules, 2025, a Data Fiduciary that becomes aware of a personal data breach must notify both the Data Protection Board of India and every affected Data Principal, regardless of the breach's scale or severity.
• How long do you have to report a data breach under the DPDP Act? The Data Principal notification must go out "without delay," with no fixed grace period. The Board notification happens in two stages: an initial alert "without delay," followed by a detailed report within 72 hours of becoming aware of the breach, or longer if the Board grants an extension on written request.
• Does every data breach need to be reported under the DPDP Act? Yes. Unlike frameworks such as the GDPR, the DPDP Act sets no materiality or harm threshold. Any breach meeting the statutory definition, unauthorised processing or accidental disclosure, acquisition, sharing, alteration, destruction, or loss of access to personal data, triggers the notification duty.
• What information must be included in a breach notification to affected individuals? Rule 7(1) requires a description of the breach, the consequences likely to affect that individual, mitigation measures taken, protective steps the individual can take, and contact details for follow-up questions.
• What must be reported to the Data Protection Board? Rule 7(2) requires an initial notification covering the nature, extent, timing, location, and likely impact of the breach, followed within 72 hours by a detailed report covering root causes, mitigation measures, findings on responsibility, remedial steps, and a summary of Data Principal notifications sent.
• When does the 72-hour clock start? It starts the moment the Data Fiduciary becomes aware of the breach, not when an investigation concludes or a root cause is confirmed.
• Is an encrypted data breach exempt from notification? No. The DPDP Act provides no statutory safe harbour for encrypted data. Encryption may reduce the practical risk to affected individuals, but the notification obligation still applies if the statutory definition of a breach is met.
• When does Rule 7 become legally enforceable? Rule 7 falls within the third commencement phase of the DPDP Rules, 2025, effective 13 May 2027, eighteen months after the Rules were notified. Section 8(6) of the Act itself establishes the underlying obligation independently of this Rules timeline.
• What is the penalty for failing to notify a data breach? Up to ₹200 crore per instance under the Schedule to the DPDP Act for a breach of Section 8(6), separate from the up to ₹250 crore ceiling for inadequate security safeguards under Section 8(5). Both can apply to the same underlying incident.
• Who is responsible for breach notification when a third-party vendor is involved? The Data Fiduciary remains responsible for notification even when the breach originates with a processor or vendor acting on its instructions. Vendor contracts should include obligations to inform the Data Fiduciary promptly enough to meet the statutory timelines.