Defines what qualifies as a personal data breach under Section 2(u) of the DPDP Act, the 72-hour notification requirement, and why "we didn't think it was serious" isn't a valid reason to skip reporting.
Most people picture a "data breach" as a hacker gaining access to a server — dramatic, external, unmistakable. Under the DPDP Act, the definition is considerably wider than that, and it's the width of that definition that trips businesses up. A misdirected email with a customer list attached, an employee's laptop lost on a train, a vendor's misconfigured cloud bucket left open by mistake, an ex-employee's access that was never revoked — under the Act, every one of these can qualify as a personal data breach, whether or not anyone acted maliciously.
That matters because the obligations that follow a breach — notification, containment, documentation — don't wait to find out whether the incident was deliberate. They attach the moment the definition is met.
The Statutory Definition, in Full
Section 2(u) of the DPDP Act defines a personal data breach as 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.
Unpacked, that definition covers three distinct types of harm, and an incident only needs to hit one of them to qualify:
| Type of Compromise | What It Means | Example |
|---|---|---|
| Confidentiality | Data is seen or accessed by someone who shouldn't have access | A misconfigured database exposes customer records publicly |
| Integrity | Data is altered without authorization | An attacker or insider modifies stored records |
| Availability | Data becomes inaccessible or is destroyed | Ransomware encrypts a payroll database; a backup is accidentally deleted |
Note what's absent from this definition: any requirement that the incident be intentional, external, or the result of a cyberattack specifically. Accidental loss counts. An employee's mistake counts. A vendor's failure counts, since the accountability for what a processor does still sits with the Data Fiduciary.
What This Actually Looks Like in Practice
Framed around real scenarios rather than legal language, the following would all typically qualify as personal data breaches under the Act:
- A misconfigured cloud storage bucket leaves KYC documents publicly accessible, even briefly
- An employee emails a spreadsheet of customer contact details to the wrong recipient
- A former employee's system access isn't revoked, and they later access records after leaving
- A ransomware attack encrypts a server holding employee payroll data, making it unavailable
- A courier misplaces physical files containing patient records
- A third-party vendor's system is compromised, exposing data the vendor was processing on your behalf
The common thread isn't the cause — it's the outcome. If personal data's confidentiality, integrity, or availability was compromised, the breach threshold is met, regardless of how mundane or accidental the trigger was.
What Happens Once a Breach Occurs
Section 8(6) of the Act requires a Data Fiduciary to notify both the Data Protection Board of India and every affected Data Principal once a personal data breach occurs. Rule 7 of the DPDP Rules, 2025 fills in the mechanics of how and when:
| Requirement | What It Involves |
|---|---|
| Notification to affected individuals | Communicated promptly, describing the nature of the breach and what's being done about it |
| Detailed report to the Board | A comprehensive report, including root cause, scope, and remedial steps, due within 72 hours of becoming aware of the breach |
| Ongoing cooperation | The Data Fiduciary remains responsible for coordinating the response, even where a processor's system was the actual point of failure |
There's an important, separate obligation worth distinguishing here: specified categories of cybersecurity incidents also need to be reported to CERT-In within 6 hours, under 2022 IT-sector directions that exist independently of the DPDP framework. The two timelines run in parallel, not as alternatives — a serious cyber incident involving personal data can trigger both obligations at once, on two different clocks.
Why "We Didn't Know It Was That Serious" Isn't a Defense
The Act notably doesn't build in a materiality threshold at the statutory level — meaning the notification obligation isn't limited to breaches above some minimum severity. This is a deliberate design choice: it removes the temptation to quietly assess an incident as "probably not a big deal" and skip notification. In practice, this means an organization's internal incident-response process needs to be built around detecting and escalating potential breaches quickly, not around trying to first determine whether the incident is significant enough to report.
The Readiness Gap Most Organizations Have
A breach-response obligation with a 72-hour clock only works if the underlying groundwork already exists. That means, before any incident occurs:
- Knowing what personal data exists across your systems and vendors, so you can quickly assess what was actually affected
- Having a documented incident-response process with clear ownership, not an ad hoc scramble when something goes wrong
- Vendor contracts that require processors to notify you immediately — well inside your own 72-hour window, not at the edge of it
- A tested communication template and process for notifying affected individuals without unnecessary delay
Organizations that only think about breach response after an incident occurs typically discover, in real time, that they can't answer basic questions fast enough: which systems were affected, whose data was involved, and what needs to go into the Board's report. That's a costly moment to be building the process for the first time.
What Non-Compliance Actually Costs
Failing to implement reasonable security safeguards — the underlying obligation a breach often exposes — carries a penalty of up to ₹250 crore under the Act's schedule. Separately, failing to notify the Board or affected individuals of a breach that did occur carries its own penalty, up to ₹200 crore. These are two distinct failure points: an organization can face exposure for the breach itself, and again for how it was — or wasn't — reported.
Getting Ahead of the Definition, Not Just the Penalty
Understanding how broadly the Act defines a personal data breach is the first step toward taking it seriously long before an incident occurs. The harder, more valuable work is building the underlying readiness — knowing what data exists, having a response process that can move within hours rather than days, and vendor contracts that don't leave you finding out about a breach after your own reporting clock has already started running.