Personal Data Breach Reporting Under the DPDP Rules: What and When to Report

Breach reporting is where good intentions meet a stopwatch. Under India's Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, the obligation to report a personal data breach is broad, fast, and has no materiality threshold. If you wait until an incident happens to figure out your process, you will miss the window. Here is what the law requires and how to be ready.

What counts as a "personal data breach"

The Act defines a personal data breach expansively: any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access, that compromises the confidentiality, integrity, or availability of personal data. Crucially, there is no minimum size or harm threshold — a single exposed record, a lost laptop, or a ransomware lockout that merely affects *availability* all qualify.

What to do: Calibrate your incident triage to this broad definition. Availability incidents (an outage that loses access to data) count too, not just confidentiality leaks.

You must notify two audiences

The Act requires a Data Fiduciary to give intimation of a breach to the Data Protection Board and to each affected Data Principal (§8(6)). The Rules set out the mechanics (Rule 7), and the two notifications run on different clocks and contents.

Notifying affected individuals — without delay

On becoming aware of the breach, you must tell each affected Data Principal without delay, in clear and plain language, through their account or a registered channel. The notice must describe:

• The nature, extent, and timing of the breach
• The likely consequences for the individual
• The measures you are taking to mitigate risk
• The safety measures they can take to protect themselves
• Business contact details of someone who can answer their questions

What to do: Pre-write this notice as a fill-in-the-blanks template now. In an incident, you supply the specifics; you do not draft from scratch.

Notifying the Board — two stages

To the Board, Rule 7 sets a two-stage intimation:

• Without delay: an initial description — the nature, extent, timing, and location of the breach and its likely impact.
• Within 72 hours (or a longer period the Board allows on written request): an updated, detailed report covering the broad facts and circumstances, the measures taken to mitigate, findings on who caused it, remedial measures to prevent recurrence, and a report on the intimations you gave to affected individuals.

What to do: Build a 72-hour clock into your incident runbook with named owners for each section of the detailed report. The clock starts when you become *aware* — define internally what "aware" means so it cannot be gamed or missed.

What the timelines are — and are not

It is worth being precise, because the public discourse is muddled. The 72-hour figure applies to the detailed Board report (Rule 7). A separate 48-hour figure exists elsewhere in the Rules — it is the pre-erasure notice before deleting data under retention limits (Rule 8) and has nothing to do with breach reporting. Do not conflate them.

A breach-reporting playbook

A workable playbook turns a chaotic incident into a checklist:

What to do: Run a tabletop exercise against this playbook before you need it. Most teams discover their 72-hour report has no clear owner only when the clock is already running.

Why this connects to everything else

Breach duties do not live in isolation. Your ability to identify *affected individuals* depends on good data inventory; your ability to *notify* them depends on the contact and grievance plumbing you built for Data Principal rights; and if you are a Processor, your duty is to alert your customer fast enough for them to meet their Board window — see DPDP for SaaS companies.

These obligations commence with the rest of the substantive Rules on 13 May 2027 (timeline) — but breach readiness takes months of drills to get right.

The first hour: before the clock pressure hits

The 72-hour Board report is won or lost in the first hour, when instinct says "contain quietly and decide later." Resist that. A disciplined first hour looks like this:

• Declare. Call it a suspected breach and trigger the runbook — do not wait for certainty about scope.
• Timestamp awareness. Record the moment you became aware; this starts the 72-hour clock and you will need it for the report.
• Contain without destroying evidence. Stop ongoing exposure, but preserve logs and forensic artefacts you will need to describe what happened.
• Assign owners. Name who drafts the principal notification, who files the Board intimation, and who leads remediation — in parallel, not in sequence.
• Start the affected-list scope. Identifying who was affected is usually the long pole; begin it immediately.

What to do: Bake these five steps into the top of your incident runbook so the first responder acts, rather than deliberating. The teams that miss the window are almost always the ones who spent the first hours deciding whether to treat it as a breach at all.

Frequently asked questions

How fast must we report a breach to the Board?

In two stages (Rule 7): an initial description without delay, then a detailed report within 72 hours of becoming aware — or a longer period if the Board allows it on a written request. The clock starts at awareness, so define internally what "aware" means.

Is there a minimum size before a breach is reportable?

No. There is no materiality threshold. A single exposed record is reportable, and breaches affecting only *availability* (such as a ransomware lockout) count alongside confidentiality leaks.

Do we always have to tell the affected individuals?

Yes. You must intimate each affected Data Principal without delay, in clear and plain language, describing the breach, its likely consequences, your mitigation, the safety steps they can take, and a contact who can answer questions (Rule 7).

Is the "48-hour" figure a breach deadline?

No — and this trips many teams up. The 48-hour figure in the Rules is a pre-erasure notice before deleting data under retention limits (Rule 8). It has nothing to do with breach reporting.

What if a Processor causes the breach?

The Fiduciary remains responsible for reporting. Your DPA should require the Processor to alert you fast enough to meet the 72-hour Board window — see DPDP for SaaS companies.

How Sammati helps

Sammati is a consent management platform (CMP) and Data Processor — not a registered Consent Manager — that supports incident response:

• An immutable, hash-chained record of consent and processing that helps scope which Data Principals were affected
• Audit-ready exports to assemble the Board's detailed report
• Multilingual notification templates to reach affected individuals across India quickly
• Rights and grievance workflows wired to the same contact point regulators expect

Take the free DPDP assessment or talk to our team about breach readiness.