A misconfigured database. An employee who emails a customer list to the wrong address. A vendor whose systems get hit by ransomware and takes your data down with it. Under India’s Digital Personal Data Protection Act, 2023, understanding DPDP Breach Notification Requirements is critical because every one of these events can trigger the same legal obligation: you have to tell someone, and you have to do it fast.

That obligation — DPDP breach notification — is one of the least forgiving parts of India’s new privacy law. There’s no size threshold. There’s no “the risk was low, so we didn’t bother” exception. There’s a clock that starts the moment your team becomes aware something went wrong, and it does not pause for weekends, board approvals, or ongoing forensic investigations.

For CEOs, founders, compliance heads, and company secretaries trying to get this right, the practical questions are rarely about the Act’s philosophy. They’re operational: What exactly counts as a breach? How many hours do we actually have? What has to go into the notification? Who do we tell first — the regulator or the customer? And what happens if we get it wrong?

This guide answers all of that in one place, grounded in the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025, notified by the Ministry of Electronics and Information Technology (MeitY) on November 13, 2025. It’s written for people who need to build a working breach response process — not just understand the law in the abstract.

What Counts as a “Personal Data Breach” Under the DPDP Act

Before you can notify anyone, you need to know what actually qualifies as a notifiable event — and the DPDP Act casts a wide net.

Under the Act, a personal data breach is defined broadly to cover any unauthorised processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data, where that event compromises the confidentiality, integrity, or availability of the data. In plain terms: if personal data was exposed, altered, lost, or made inaccessible without proper authorisation, it’s in scope — regardless of whether it was malicious, accidental, or purely a systems failure.

This is a much broader definition than many organisations initially assume. It’s not limited to hacking incidents. In practice, notifiable breaches under the DPDP Act typically fall into a handful of recurring categories:

Unauthorised access — an external attacker, a compromised account, or an insider viewing data outside their authorised scope. This is the most common trigger: think SQL injection into a customer database, credential-stuffing attacks, or a former employee’s account that was never deactivated.
Accidental disclosure — personal data unintentionally made available to the wrong audience. A misconfigured cloud storage bucket left publicly accessible, a CSV of customer records emailed to the wrong distribution list, or an API endpoint returning more fields than it should.
Loss or destruction — data that becomes permanently unavailable, whether through ransomware encryption without a clean backup, hardware failure, or an accidental bulk deletion.
Unauthorised alteration — personal data changed or manipulated without proper authority, which can be just as damaging as exposure, particularly for financial or health records.
Third-party and vendor incidents — a breach at a data processor, cloud host, or SaaS vendor that touches personal data you’re responsible for. The Act doesn’t let you outsource this liability; if your processor is breached, the obligation to notify still sits with you as the Data Fiduciary.
Loss of access — situations where data isn’t stolen or destroyed but becomes inaccessible to the organisation (and by extension, to the individuals whose data it is) for an extended period, such as in a prolonged ransomware lockout.

The threshold question every compliance team eventually asks is: “Does this specific incident actually require notification?” Under the DPDP Act, the honest answer is almost always yes if personal data was genuinely involved. Unlike some global frameworks, there is no built-in “low severity, so we can skip it” carve-out for individual notification. That single design choice is what makes DPDP breach notification meaningfully stricter than the regime many Indian companies are used to from GDPR benchmarking exercises — more on that comparison shortly.

The Legal Foundation: Section 8(6) and Rule 7

The breach notification obligation has two layers: the Act itself, and the Rules that operationalise it.

Section 8(6) of the DPDP Act, 2023 is the statutory anchor. It requires every Data Fiduciary — the entity that determines the purpose and means of processing personal data — to give intimation of a personal data breach to two parties: the Data Protection Board of India (DPBI) and each affected Data Principal, in the form and manner that is prescribed. The section itself doesn’t specify timelines or content in detail; it establishes the duty and leaves the mechanics to subordinate rules.

Rule 7 of the DPDP Rules, 2025 fills in exactly those mechanics. It sets out the timelines, the structure of the notification process, what has to be communicated, and to whom. This is the rule your incident response plan needs to be built around, and it works alongside Rule 6, which separately governs the “reasonable security safeguards” Data Fiduciaries are expected to maintain under Section 8(5) to prevent breaches from happening in the first place. The two rules are connected in practice: weak safeguards under Rule 6 are frequently what lead to the incidents that trigger Rule 7.

It’s worth sitting with why the law is structured this way. A breach notification requirement without safeguard requirements would just be paperwork after the fact. A safeguard requirement without a notification duty would let organisations quietly absorb incidents without any accountability to the people affected. Together, they’re designed to push organisations toward privacy regulation automation — systems that reduce the likelihood of a breach and, when one happens anyway, produce a fast, complete, and defensible response.

The DPDP Breach Notification Timeline: How the 72-Hour Clock Actually Works

This is the part every compliance officer needs memorised, because getting the sequencing wrong is one of the most common — and most expensive — mistakes organisations make.

Rule 7 sets up a two-track, two-stage notification structure. One track runs to the Data Protection Board of India. The other runs to affected Data Principals. Both start at the same moment: the point at which your organisation becomes aware that a personal data breach has occurred.

When does the clock actually start?

Awareness, not confirmation. The clock starts when your incident response team has enough information to conclude that personal data was compromised — not when you’ve finished a complete forensic investigation. This is a deliberately low bar, and it’s the single biggest operational adjustment most organisations need to make. You do not get to wait until you know exactly which records were affected, how the attacker got in, or how many individuals are impacted before the clock starts running. You need enough to know something happened.

Track 1: Notifying the Data Protection Board

Stage	Timing	What’s required
Stage 1 — Initial intimation	Without delay (in practice, within hours of confirmed awareness)	A preliminary alert describing the nature, extent, timing, and location of the breach, and its likely impact where known.
Stage 2 — Detailed report	Within 72 hours of awareness (extendable only if the Board permits a longer period on written request)	A comprehensive report covering the facts and circumstances of the breach, categories and approximate number of affected Data Principals, mitigation and remedial measures taken or planned, findings on the person or entity responsible (where identified), steps taken to prevent recurrence, and a summary of the notifications issued to affected Data Principals.

Track 2: Notifying affected Data Principals

Affected individuals must be notified without delay — the Rules don’t give Data Fiduciaries a separate 72-hour grace period for the individual notice the way some interpretations assume. In practice, this means the notice to your customers, employees, or users should go out on essentially the same timeline as your Board intimation, not after your Stage 2 detailed report is filed. Building a process where individual notification quietly waits for the “full picture” is a common and risky misreading of Rule 7.

Putting it together: a realistic 72-hour response window

Hour	What should be happening
Hour 0	Incident confirmed as a personal data breach. Clock starts.
Hours 0–6	Internal escalation, containment begins, legal and compliance briefed. If regulated by CERT-In Directions, the separate 6-hour CERT-In clock is already running in parallel (see comparison section below).
Hours 0–24	Initial Board intimation sent. Scoping continues: what data, how many individuals, contained or still active. Draft Data Principal notice prepared.
Hours 24–48	Data Principal notifications go out via registered communication channels (email, SMS, in-app, or account notice). Mitigation measures documented as they’re taken.
Hours 48–72	Detailed report to the Board finalised and submitted, including root cause findings so far, remediation steps, and a summary of individual notices already sent.

The takeaway for leadership teams: this is not a legal-team problem that surfaces after IT has “handled” the incident. It’s a cross-functional sprint that needs security, legal, compliance, and communications working from the same clock from hour zero.

What Must Be in a Breach Notification

Vague, boilerplate breach notices don’t satisfy Rule 7 — and they don’t protect you if the Board later reviews what was actually communicated. The content requirements differ slightly depending on the recipient.

To the Data Protection Board (initial intimation)

Nature of the breach — what type of incident occurred (unauthorised access, ransomware, accidental disclosure, insider misuse, etc.)
Extent — an initial estimate of scope, even if imprecise at this stage
Timing and location — when the breach is believed to have occurred and where in your systems or vendor stack it originated
Likely impact — an early assessment of consequences, where this can reasonably be judged this early

To the Data Protection Board (detailed follow-up report, within 72 hours)

Full facts and circumstances of the breach as understood at this stage
Categories and approximate number of Data Principals affected
Mitigation and remedial measures already taken or planned
Findings regarding the individual, group, or entity responsible, where this has been identified
Steps implemented (or planned) to prevent recurrence
A summary of the notifications already issued to affected Data Principals

To affected Data Principals

The notice has to be in clear, plain language — not legal or technical jargon — and delivered through a channel the person will actually see: their registered email, SMS, in-app notification, or user account. It must include:

A description of the breach — its nature, extent, and timing, described in terms an ordinary person can understand
Likely consequences — what could realistically happen as a result (for example, exposure to phishing, identity theft, or financial fraud if payment or identity data was involved)
Mitigation measures taken — what your organisation has already done or is doing to contain and address the incident
Safety steps the individual can take — practical, specific actions, such as changing a password, monitoring a bank statement, or enabling two-factor authentication
A contact point — a real channel through which the individual can ask questions and get answers, not a generic “no-reply” address

One operational note that trips up a lot of first-time responders: don’t wait for perfect information before sending the individual notice. Rule 7 expects a “without delay” notification built on your best current understanding, followed by updates if the picture materially changes — not silence until certainty arrives.

Who Is Responsible: Data Fiduciaries, Processors, and Significant Data Fiduciaries

The DPDP Act places the compliance burden squarely on the Data Fiduciary — the organisation that decides why and how personal data is processed — regardless of who actually caused the breach.

If you engage a Data Processor (a payroll vendor, a cloud host, a customer support platform, an analytics tool) and that processor suffers an incident involving your users’ data, the notification obligation to the Board and to Data Principals still sits with you. This is why vendor governance and contractual breach-notification clauses with every processor are not optional extras — they’re the only way you’ll actually know about an incident at a vendor in time to meet your own 72-hour clock. Your vendor’s SLA for telling you about a breach needs to be well inside 72 hours, or your own compliance timeline is dead on arrival before you’ve even started responding.

Significant Data Fiduciaries (SDFs) — organisations designated as such based on the volume and sensitivity of data they process, or their potential impact on India’s sovereignty, electoral democracy, state security, or public order — carry additional obligations under Section 10 of the Act, including appointing a Data Protection Officer and undergoing periodic data protection impact assessments and audits. While the core breach notification duty under Section 8(6) applies to every Data Fiduciary, SDFs should expect a higher standard of scrutiny in how their breach response and documentation hold up.

Penalties for Non-Compliance: The Real Cost of Getting Breach Notification Wrong

The Schedule to the DPDP Act sets out some of the steepest data protection penalties in the world, and breach-related failures sit at the top of the list.

Violation	Maximum Penalty
Failure to implement reasonable security safeguards (Section 8(5))	Up to ₹250 crore
Failure to notify the Board or affected Data Principals of a breach (Section 8(6))	Up to ₹200 crore
Non-compliance with special provisions for children’s data (Section 9)	Up to ₹200 crore
Failure to fulfil additional obligations of a Significant Data Fiduciary (Section 10)	Up to ₹150 crore
Any other violation of the Act or Rules by a Data Fiduciary	Up to ₹50 crore
Breach of a voluntary undertaking accepted by the Board (Section 32)	Equal to the penalty applicable to the original violation
Failure to observe the duties of a Data Principal (Section 15)	Up to ₹10,000

Two things make this schedule more dangerous than the headline numbers suggest.

First, the penalties stack. An organisation that had inadequate security safeguards (Section 8(5) exposure), then failed to notify on time (Section 8(6) exposure), is facing both penalty categories arising from a single incident — not a choice between them. A breach that could have cost you reputational damage and remediation expenses can, through a slow or missed notification, turn into a regulatory penalty on top of everything else.

Second, the Data Protection Board has independent investigative authority and considers factors like the nature and gravity of the breach, the number of individuals affected, your organisation’s compliance history, and how you responded when determining the actual penalty within these ceilings. A breach that surfaces publicly — through media coverage, a customer complaint, or a researcher’s disclosure — before the Board has received your formal intimation invites exactly the kind of scrutiny that pushes a penalty toward the higher end of the range.

The practical implication for boards and founders: breach notification compliance isn’t really a compliance-team line item. It’s enterprise risk management with a number attached that can materially affect a company’s balance sheet.

DPDP vs GDPR vs CERT-In: How India’s Breach Notification Regime Compares

Many Indian organisations — particularly SaaS companies and BPOs serving global clients — already have breach response processes built around GDPR or US frameworks. It’s tempting to assume that process transfers directly to DPDP compliance. It mostly doesn’t, and the gaps matter.

Dimension	DPDP Act, 2023 (India)	GDPR (EU)	CERT-In Directions (India)
Regulator notification deadline	72 hours from awareness (two-stage: initial + detailed report)	72 hours from awareness (Article 33)	6 hours from noticing/detecting the incident
Individual notification trigger	Mandatory for every breach — no risk threshold	Only if the breach is likely to result in “high risk” to the individual (Article 34)	Not applicable — CERT-In reporting is a cyber incident regime, not an individual-rights regime
Minimum size/severity threshold	None — a breach affecting one record carries the same duty as one affecting millions	Effectively risk-based in practice for individual notice	None for the specified incident categories under the Directions
What triggers the obligation	Any unauthorised processing, or accidental disclosure, acquisition, alteration, destruction, or loss of access, that compromises confidentiality, integrity, or availability of personal data	A “personal data breach” under Article 4(12), similarly broad	A defined list of cyber incident types (not limited to personal data)
Maximum penalty	Up to ₹200 crore for breach notification failure; up to ₹250 crore for inadequate safeguards	Up to €20 million or 4% of global annual turnover, whichever is higher	Penalties under the IT Act, generally lower and framed differently

The distinction that catches out the most organisations transitioning from a GDPR mindset: DPDP has no risk-based exception for notifying individuals. Under GDPR, a company can reasonably decide not to notify affected users if the breach is judged unlikely to cause them real harm — that judgment call simply doesn’t exist under the DPDP Act. Every qualifying breach gets notified to both the Board and every affected Data Principal, full stop.

The other operational reality: if your organisation is also subject to the CERT-In Directions of 2022 under the IT Act — which applies to most companies operating digital infrastructure in India — you’re not choosing between CERT-In reporting and DPDP breach notification. You’re doing both, on two overlapping but distinct clocks, with the CERT-In 6-hour window arriving first. A breach response plan built only around DPDP’s 72-hour timeline will blow through the CERT-In deadline before your DPDP process has even reached its first checkpoint.

When Does This Actually Apply? The Phased Implementation Timeline

One question compliance teams ask constantly: is breach notification already legally enforceable, or is there still runway?

The answer requires some precision. MeitY notified the DPDP Rules, 2025 on November 13, 2025, alongside a notification bringing the substantive provisions of the DPDP Act into force in a staggered, three-phase timeline:

Phase 1 (effective immediately, November 2025): Provisions establishing the Data Protection Board of India and its administrative functioning.
Phase 2 (effective 12 months later, November 2026): Provisions governing the registration and obligations of Consent Managers.
Phase 3 (effective 18 months later, May 2027): The substantive obligations most organisations associate with “DPDP compliance” — Data Fiduciary obligations, Data Principal rights, cross-border data transfer rules, children’s data processing safeguards, security safeguard requirements under Rule 6, breach notification under Rule 7, and appeal provisions.

In other words, breach notification under Rule 7 becomes formally enforceable in May 2027. That fact is easy to misread as “we have until 2027 to worry about this,” and that reading will cost organisations dearly. A few reasons why treating this as a distant deadline is the wrong call:

Security incidents don’t wait for enforcement dates. A breach that happens today still damages customers, exposes the company to IT Act liability, and creates reputational risk with or without DPDP penalties attached.
Building a working 72-hour response capability takes months, not days. Incident detection tooling, escalation runbooks, pre-approved notification templates, vendor breach-notification clauses, and cross-functional response drills all need to exist and be tested before you need them — not assembled in a panic during an actual incident.
Regulators and enterprise customers increasingly expect DPDP-readiness now, independent of the formal enforcement date, particularly in due diligence for funding rounds, vendor onboarding, and enterprise sales.

The organisations that will be caught out in May 2027 aren’t the ones who haven’t achieved perfect compliance yet — they’re the ones who haven’t started building.

Building a DPDP-Ready Breach Response Plan: A Practical Framework

A policy document sitting in a shared drive isn’t a breach response plan. A functioning one needs to move through five stages, each with clear ownership.

1. Detect

You can’t notify a breach you don’t know about. This means having actual visibility into where personal data lives — across your own systems and every vendor’s — and monitoring that’s sensitive enough to catch anomalies quickly. Organisations that discover breaches weeks after the fact, through a customer complaint or a dark-web listing, have already lost the ability to meet a 72-hour clock that started long before they noticed.

2. Assess and classify

Once something looks wrong, someone needs the authority to formally declare “this is a personal data breach” and start the clock — without waiting for a complete investigation. This stage should answer: what category of personal data is involved, roughly how many Data Principals are affected, is the incident contained or ongoing, and does it also trigger a CERT-In reporting obligation.

3. Contain and notify — in parallel, not in sequence

This is where most improvised response plans fail. Containment (isolating systems, revoking access, patching the vulnerability) and notification (Board intimation, Data Principal notice) need to run at the same time, run by different people. Waiting for containment to finish before starting the notification process is one of the fastest ways to blow through the 72-hour window.

4. Document everything, in real time

Every action taken — who was told, when, what was said, what containment steps were executed and at what time — needs to be logged as it happens, not reconstructed afterward. This documentation is what your detailed Board report at hour 72 is built from, and it’s also your primary evidence if the Board later reviews whether your response was reasonable.

5. Remediate and close the loop

After the immediate notifications, the work shifts to root cause analysis, closing the specific gap that caused the incident, updating your risk assessment, and — where the incident revealed a pattern — reviewing whether similar gaps exist elsewhere in your data processing activities. This stage also feeds back into your Rule 6 security safeguards, since a breach that recurs because the underlying cause was never fixed is a much harder conversation with the Board the second time.

A plan built this way isn’t just a compliance document — it’s a genuine test of your organisation’s data governance maturity, and it tends to expose gaps in access controls, application security, and vendor oversight long before an actual incident does.

Common Mistakes Organisations Make With Breach Notification

Most breach notification failures aren’t caused by bad intent. They’re caused by predictable, avoidable gaps in process:

Waiting for a “complete picture” before notifying anyone. Rule 7 expects timely notification based on the best available information, not a fully resolved investigation. Organisations that delay notification until they have every fact end up missing the clock entirely.
Treating vendor breaches as someone else’s problem. If a processor is breached, the notification duty is still yours. Without contractual clauses requiring vendors to notify you fast, you may not even learn about an incident until it’s too late to respond within your own timeline.
No pre-approved communication templates. Drafting a plain-language, legally sound breach notice from scratch, under pressure, during an active incident, consistently produces slower and weaker notifications than having a reviewed template ready in advance.
Confusing CERT-In reporting with DPDP compliance. Filing a CERT-In report within 6 hours does not satisfy the separate DPDP obligations to the Data Protection Board and to affected Data Principals. Teams that treat these as one obligation frequently miss the DPDP-specific content requirements entirely.
Applying a risk-based filter to individual notification. Deciding internally that a breach was “too minor” to bother telling affected users is a GDPR-era instinct that doesn’t hold up under the DPDP Act’s no-threshold design.
No single owner for the breach response process. When detection, legal review, and communications sit with three different teams with no defined handoff, critical hours are lost simply figuring out who’s supposed to act next.
Undocumented decision-making. If the Board later asks why a notification took the time it did, “we don’t have records of what happened when” is not a defensible answer.

Best Practices for Breach Notification Readiness

Maintain a live, accurate data registry. You can’t scope a breach quickly if you don’t already know what personal data you hold, where it lives, and which systems process it. This is foundational to everything else in this section.
Put breach notification clauses in every vendor and processor contract, with a notification SLA meaningfully shorter than your own 72-hour window — ideally within 24 hours of the vendor becoming aware.
Pre-draft and legally review notification templates for the Board and for Data Principals, so the response team is filling in specifics under pressure, not writing from scratch.
Run a tabletop breach simulation at least annually. A response plan that has never been rehearsed rarely survives contact with a real incident.
Assign clear, named ownership for detection, legal sign-off, Board notification, and Data Principal communication, with defined backups for each role.
Centralise documentation as the incident unfolds, not after — timestamps, actions taken, and communications sent all need to be captured in a single, audit-ready record.
Build your Rule 6 security safeguards and Rule 7 breach response as one connected system, not two separate compliance exercises — the incidents you prevent are the notifications you never have to send.
Track regulatory reporting tools and workflows the same way you track any other operational SLA — with owners, deadlines, and escalation paths, not a static policy PDF.

How Automation Changes Breach Notification Compliance

Manual breach response is fragile precisely where the law is least forgiving: speed, completeness, and evidence. A spreadsheet-and-email process might get you through one incident. It rarely survives the pressure of an actual 72-hour clock, a distracted team, and a Board that expects a documented, defensible response.

This is the gap automated compliance management platforms like RuleExpert are built to close — not by replacing judgment, but by removing the operational friction that causes organisations to miss deadlines they were fully capable of meeting.

A few ways this plays out in practice:

Breach Management workflows turn the five-stage response framework above into a structured, trackable process — incident intake, investigation workflows, risk assessment, evidence management, corrective action tracking, and audit-ready breach documentation, all in one place instead of scattered across email threads and shared drives.
A live Data Registry means you’re not scoping a breach from scratch. Because personal data inventory, data mapping, and processing purpose documentation already exist, assessing “what data, how many people, how serious” happens in hours, not days.
SLA monitoring and automated reminders keep the 72-hour clock visible to every stakeholder in real time, rather than relying on someone remembering to check.
Vendor Governance modules track vendor risk assessments, due diligence, and review reminders — which is exactly the infrastructure that lets you actually hold processors to a notification SLA instead of finding out about a vendor breach from a news headline.
Audit trails and centralised documentation capture every action as it happens, so your detailed Board report and your defence of the response, if it’s ever questioned, are built from a real-time record rather than a reconstructed timeline.
Role-based access control ensures the right people — legal, compliance, security, communications — see and act on the right information during an incident, without bottlenecking through one person.

None of this replaces having a competent incident response team. What it does is remove the specific failure modes — lost time, missing documentation, unclear ownership, forgotten vendor obligations — that turn a manageable incident into a regulatory penalty. That’s the practical difference between privacy policy automation as a documentation exercise and compliance automation as an operational capability your organisation can actually execute under pressure.

For organisations still relying on manual document management and ad hoc risk assessment processes, breach notification readiness is often the clearest, most concrete argument for automation — because it’s the one compliance obligation where the cost of being slow is measured in a specific number on a penalty schedule.

Industry-Specific Considerations

Breach notification obligations under the DPDP Act apply uniformly, but the operational stakes differ by sector:

Healthcare and HealthTech organisations handle some of the most sensitive personal data categories, and a breach involving health records tends to carry disproportionate reputational and individual harm — the “likely consequences” section of your Data Principal notice carries real weight here.
BFSI and FinTech entities face breach scenarios that frequently overlap with RBI and other financial regulator reporting obligations, on top of DPDP and CERT-In — meaning breach response plans in this sector need to map three regulatory timelines simultaneously, not one.
E-commerce and platforms with large user bases face breach scenarios at scale, where “approximate number of affected Data Principals” can run into the millions, and where the Third Schedule’s sector-specific data retention timelines are directly relevant to what data is even at risk in the first place.
B2B SaaS companies processing personal data on behalf of enterprise clients need contractual clarity on who notifies whom — the SaaS provider is typically a Data Processor, meaning its enterprise client (the Data Fiduciary) carries the regulatory notification duty, but only if the SaaS provider notifies its client fast enough for that duty to be met.

Frequently Asked Questions

1. What is the DPDP breach notification timeline? Under Rule 7 of the DPDP Rules, 2025, Data Fiduciaries must send an initial intimation to the Data Protection Board “without delay” upon becoming aware of a breach, followed by a detailed report within 72 hours. Affected Data Principals must also be notified without delay — not held back until the 72-hour Board report is filed.

2. Do I need to report a breach even if I don’t think anyone was harmed? Yes. Unlike GDPR, the DPDP Act does not include a risk-based exception for individual notification. If personal data was involved in unauthorised processing, accidental disclosure, alteration, destruction, or loss of access, the notification obligation applies regardless of the perceived severity or actual harm caused.

3. What happens if we miss the 72-hour deadline? Failure to notify the Board or affected Data Principals under Section 8(6) can attract a penalty of up to ₹200 crore. If the underlying cause was also inadequate security safeguards, a separate penalty of up to ₹250 crore under Section 8(5) can apply on top of that — the two are not mutually exclusive.

4. Is there a minimum number of affected individuals before notification is required? No. The DPDP Act sets no minimum threshold. A breach affecting a single Data Principal carries the same notification obligation as one affecting millions.

5. Who is responsible for breach notification — us or our cloud/SaaS vendor? The obligation sits with the Data Fiduciary — the organisation that determines the purpose and means of processing — even when the actual incident occurs at a Data Processor. This is why vendor contracts need clear, fast breach-notification clauses; without them, you may not learn about an incident in time to meet your own deadline.

6. How is DPDP breach notification different from CERT-In reporting? They’re separate obligations that often apply in parallel. CERT-In Directions require reporting specified cyber incidents to CERT-In within 6 hours of detection, under the IT Act framework. DPDP breach notification, under Section 8(6) and Rule 7, requires separate notification to the Data Protection Board and to affected Data Principals, with different content requirements and a 72-hour Board reporting window. Filing one does not satisfy the other.

7. What exactly should a breach notification to customers say? It should describe the nature, extent, and timing of the breach in plain language, explain the likely consequences for the individual, detail the mitigation steps already taken, recommend specific safety actions the person can take, and provide a real contact point for questions — not generic, boilerplate language.

8. Are DPDP breach notification requirements already legally enforceable? The DPDP Rules were notified on November 13, 2025, with implementation staggered across three phases. The core Data Fiduciary obligations — including breach notification under Rule 7 and security safeguards under Rule 6 — come into force in the third phase, in May 2027. However, waiting until then to build a response capability is a significant operational risk, given how long it takes to build and test a working process.

9. How is DPDP breach notification different from GDPR’s Article 33 and 34? Both frameworks set a 72-hour regulator notification deadline. The key difference is individual notification: GDPR only requires notifying affected individuals if the breach is likely to result in high risk to their rights (Article 34), giving organisations a judgment call. DPDP has no such threshold — every qualifying breach must be notified to affected Data Principals, without exception.

10. Can automation actually reduce our risk of missing a notification deadline? Yes, primarily by removing the friction points that cause delays: not knowing what data was affected, unclear ownership of the response, vendor incidents surfacing too late, and undocumented actions that slow down report preparation. Platforms with live data registries, breach management workflows, SLA monitoring, and vendor governance modules are built specifically to compress the time between “we noticed something” and “we’ve notified correctly.”

Getting Ahead of the May 2027 Deadline

DPDP breach notification requirements reward organisations that treat this as an operational build, not a policy exercise. The 72-hour clock is unforgiving, the individual notification duty has no exceptions, and the penalty schedule is steep enough that a slow response can cost more than the breach itself.

The organisations that will handle this well in 2027 are the ones building the muscle now: a live data registry, tested response workflows, vendor accountability, and documentation that holds up under regulatory review.

RuleExpert’s Breach Management module — alongside Consent Manager, Data Registry, DSR Automation, and Vendor Governance — is built to operationalise exactly this kind of DPDP readiness, so your team is executing a rehearsed process during an incident, not improvising one.

Book a demo to see how RuleExpert helps you build a DPDP-ready breach response process before you need one.

Author Bio

Nitin Ray is a thought leader in DPDP compliance, healthcare data privacy, and governance technology. He regularly writes about data protection, privacy governance, AI compliance, vendor governance, breach management, and regulatory best practices. His mission is to help hospitals, healthcare providers, and enterprises build stronger compliance frameworks, protect sensitive personal data, and adopt technology-driven governance solutions that support long-term digital trust.

DPDP Breach Notification Requirements: The Complete Guide for Indian Businesses