Home/Blog/DPDP Act Data Breach Notification: How Many Hours Do You Actually Have?
Compliance

DPDP Act Data Breach Notification: How Many Hours Do You Actually Have?

The DPDP Act's breach-reporting clock has two different deadlines, not one — here's exactly what must happen immediately versus within 72 hours, and what it costs to get it wrong.

Hardik Patel
Hardik PatelSep 3, 2026 · 7 min
Cover image: DPDP Act Data Breach Notification: How Many Hours Do You Actually Have?
Summary
  • The DPDP Act's breach-reporting clock actually has two separate deadlines, not one: an immediate "without delay" alert, and a detailed report within 72 hours.
  • Affected individuals and the Data Protection Board must both be told "without delay" — there's no fixed hour count for this first step, and waiting to gather all the facts first is the wrong instinct.
  • Failing to report a breach can draw a fine of up to ₹200 crore; failing to have "reasonable" security safeguards in place can draw a separate fine of up to ₹250 crore.

If you run a business in India and someone asks how many hours you have to report a data breach under the DPDP Act, the honest answer is: it depends which deadline they mean, because there are two of them.

Table of Contents

  • The Two-Stage Breach Notification Timeline
  • What "Without Delay" Actually Requires
  • What Goes Into the 72-Hour Report to the Board
  • What Counts as a Reportable Breach
  • What It Costs to Get This Wrong
  • A Practical Breach-Response Checklist
  • Frequently Asked Questions
  • How iTechFixr Can Help

The Two-Stage Breach Notification Timeline

Rule 7 of the Digital Personal Data Protection Rules, 2025 sets out two distinct notification obligations for a Data Fiduciary (the business that decides why and how personal data is processed) once it becomes aware of a personal data breach:

  • Stage 1 — Without delay: An initial notification to every affected Data Principal (the individual whose data was exposed), and a separate initial alert to the Data Protection Board, both issued as soon as the business becomes aware of the breach.
  • Stage 2 — Within 72 hours: A detailed follow-up report to the Board only, due within 72 hours of becoming aware of the breach, or a longer period if the Board grants an extension on a written request.

The 72-hour figure is the one most businesses have heard of, because it is concrete and quotable. But it only applies to the Board's detailed report. The obligation to affected individuals — and the Board's first alert — has no fixed hour count at all. It has to happen "without delay," which in practice means as soon as you have enough information to act, not once you have every detail confirmed.

What "Without Delay" Actually Requires

This is the deadline most businesses underestimate, because "without delay" sounds softer than a hard number. In practice, regulators read it as "as soon as reasonably possible" — not "once the investigation is complete."

The notification to each affected Data Principal has to be concise, clear, and in plain language, and it must include:

  • A description of the breach, in plain terms — what happened, in language a non-technical person can understand.
  • The likely consequences for that individual.
  • The mitigation measures the business has already implemented.
  • Safety recommendations the individual can act on themselves.
  • A contact point for questions.

The parallel alert to the Board covers the nature, extent, timing, and location of the breach, along with its likely impact — again, as an initial notice, not a full investigation report.

The practical implication: a business cannot wait until it has fully scoped the breach, identified the root cause, and fixed the vulnerability before telling anyone. The "without delay" clock starts the moment the business becomes aware something happened, not the moment it fully understands what happened.

What Goes Into the 72-Hour Report to the Board

The second stage — due within 72 hours of the business becoming aware of the breach — is a more complete report, submitted to the Board only (not to affected individuals directly). It has to include:

  • A detailed description of the breach's circumstances and causes.
  • The risk-mitigation measures taken or proposed.
  • Findings on who, if anyone, was responsible for the breach.
  • The remedial actions implemented to prevent a repeat.
  • A summary of what was communicated to the affected individuals in Stage 1.

If 72 hours genuinely isn't enough — for a complex intrusion where the full scope isn't yet clear — a business can request more time from the Board in writing. That request has to happen before the 72-hour window closes, not after.

What Counts as a Reportable Breach

The DPDP Act defines a personal data breach broadly, 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.

That definition is wide enough to cover far more than a dramatic ransomware attack. A misconfigured cloud storage bucket left publicly accessible, an employee emailing a customer list to the wrong address, or a lost laptop with an unencrypted customer database can all qualify. Unlike some other data protection regimes, the DPDP Rules do not currently carve out a materiality or harm threshold below which reporting isn't required — the obligation is triggered by the breach occurring, not by how serious it turns out to be.

What It Costs to Get This Wrong

The DPDP Act's penalty structure treats breach notification failures and security failures as two separate violations, each with its own fine ceiling:

  • Failure to notify a breach as required: a fine of up to ₹200 crore.
  • Failure to implement reasonable security safeguards: a separate fine of up to ₹250 crore.

These are ceilings the Data Protection Board can impose, not automatic penalties for every incident — but they signal how seriously the framework treats the notification obligation on its own, independent of whatever the underlying breach itself already cost the business in remediation, downtime, and customer trust.

A Practical Breach-Response Checklist

Most Indian SMEs don't have a dedicated legal or compliance team to manage this timeline in the moment. A short, pre-agreed checklist matters more than a long policy document nobody reads during an actual incident:

  • Before anything happens: Know who internally is authorised to declare an incident a "breach" and start the clock — don't leave that decision ambiguous during a crisis.
  • Within the first hours: Contain what you can, but don't let containment delay the "without delay" notifications — they can go out with an honest "here's what we know so far" framing.
  • Draft templates in advance: Have a plain-language breach notice template ready before you need it, so Stage 1 isn't being written from scratch under pressure.
  • Track the 72-hour clock explicitly: Note the exact time the business became aware of the breach — that is the start of the 72-hour window, not the time the breach itself occurred.
  • If you'll miss 72 hours, request an extension before the deadline, not after.

Frequently Asked Questions

Does the 72-hour rule apply to notifying affected customers?
No. The 72-hour deadline applies only to the detailed report sent to the Data Protection Board. Affected individuals must be notified "without delay," which has no fixed hour count but is generally understood to mean as soon as practically possible.

What if we don't know the full scope of the breach yet?
The initial "without delay" notifications are meant to happen with whatever information is available at the time, not after a full investigation. The 72-hour Board report can then be updated as more facts emerge, and an extension can be requested in writing if genuinely needed.

Do small businesses get an exemption from breach notification?
The Act does not currently carve out a small-business exemption from the breach notification obligation itself, though compliance timelines are being phased in — most day-to-day obligations, including breach notification, become enforceable during an 18-month implementation window, with full compliance required by mid-2027.

How iTechFixr Can Help

iTechFixr helps Indian businesses build a DPDP-ready incident response plan before they need one — pre-drafted notification templates, a clear internal escalation path, and a security audit that identifies the gaps most likely to cause a reportable breach in the first place. If your business doesn't yet have a documented breach-response process, that's the single highest-leverage compliance gap to close first.

Not sure where you stand? Check your DPDP readiness free (2 minutes).

Hardik Patel
Hardik Patel
CEH v12 onwards certified cybersecurity trainer & consultant, iTechFixr Infotech LLP. 7+ years in offensive security and VAPT.

Need Help With This?

Talk to Hardik directly about your organisation's cybersecurity needs — get a tailored response within 24 hours.