DPDP Data Breach Notification: Rules & Timelines

What counts as a personal data breach

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

This breadth matters. A breach is not only a malicious hacker exfiltrating a database; it includes an employee emailing a spreadsheet to the wrong recipient, a misconfigured cloud bucket left public, ransomware that encrypts your records, or even the accidental deletion of data you were obliged to protect.

Because so many events qualify, organisations need a clear internal definition and a low threshold for raising potential incidents, so that genuine breaches are caught and assessed rather than quietly overlooked.

A practical consequence of this breadth is that you should err toward raising potential incidents rather than dismissing them. It is far safer to assess an event and conclude it was not a reportable breach than to overlook one that was, and then face the Board having failed to notify.

The duty starts on awareness

A critical feature of the regime is that the notification duty is triggered when the fiduciary becomes aware of the breach, not when it has finished investigating. The clock starts on awareness, which fundamentally shapes how you must respond.

This means you cannot wait until you fully understand an incident before notifying. Organisations that hold back for certainty are precisely the ones that miss the deadline, because full understanding often takes far longer than the window allows.

The practical implication is a willingness to notify on partial, preliminary information and to update as the picture clarifies — a discipline that has to be agreed and rehearsed before any incident occurs.

This is also why a clear internal definition of 'awareness' matters. Deciding in advance who, on learning what, counts as the organisation becoming aware prevents arguments after the fact about exactly when the clock should have started.

Tier one: immediate notification

On becoming aware of a breach, the fiduciary must give an immediate intimation to both the Data Protection Board and the affected data principals. This first notification describes the breach in the terms then known: its nature, extent, the timing and location of the occurrence, and the likely consequences.

It must also identify a point of contact — typically the Data Protection Officer or a named responder — from whom more information can be obtained, so that both the Board and individuals have a route to follow up.

This immediate notice is deliberately about speed over completeness. Its purpose is to put the regulator and affected people on notice quickly, even before every fact is established. Building this into dpdp compliance means having templates ready to go.

Speed here protects individuals, who may need to act — changing passwords, watching for fraud — before you have finished your forensics. The immediate notice is as much about enabling self-protection as it is about regulatory compliance.

Tier two: the detailed report within 72 hours

The second tier is a fuller report to the Board, generally required within 72 hours of becoming aware, though the Board can grant an extension on request. This report covers the broader and updated facts of the breach.

It typically includes the circumstances and reasons that led to the breach, the measures implemented to mitigate the risk, the findings on who may have caused it, the remedial steps taken to prevent recurrence, and a report on the notifications given to affected individuals.

This is where the early investigation pays off: the detailed report demonstrates not just that a breach occurred, but that the organisation responded competently — which materially affects how the Board views the incident.

Requesting an extension, where genuinely needed, is better than filing a rushed and inaccurate report. The Board can grant more time, but you should ask rather than simply miss the deadline, and you should still have notified at the first tier on awareness.

What you must tell affected individuals

Affected data principals must be informed in clear and plain language, without delay. The communication should describe the breach, its likely consequences for the individual, the measures the fiduciary has taken or is taking to mitigate it, and the safety measures the individual can take to protect their own interests.

It should also provide contact details for the person able to answer their questions. The goal is to give people enough understanding to protect themselves — for example by changing passwords or watching for fraud — rather than a vague, anxiety-inducing notice.

Communicating well here is both a legal duty and a trust test: a clear, honest, helpful breach notice can preserve a relationship, while a defensive or confusing one can destroy it.

The tone of the individual notice matters enormously. A calm, specific, action-oriented message reassures people that you have things in hand, whereas a vague or evasive one amplifies alarm and erodes the trust the relationship depends on.

Why detection and logging are prerequisites

You cannot report a breach you never detect. Many breaches are discovered late, or by outsiders, which makes the awareness-based clock almost impossible to meet. Investment in monitoring and detection is therefore as important as the response plan itself.

Logging is the other prerequisite. The Rules expect logs to be retained for at least a year precisely so that, when a breach occurs, you can reconstruct what happened, when, and to whom — the very facts the detailed report demands.

Without detection and logging, breach notification becomes guesswork, and guesswork does not satisfy the Board or protect affected individuals.

Building a breach-response runbook

The only reliable way to meet these obligations is a documented, rehearsed runbook. It should define how incidents are detected and triaged, who decides that a reportable breach has occurred, who drafts and approves notifications, and how the Board and individuals are reached.

Pre-drafted notification templates — for the immediate notice, the detailed report, and the individual communication — save precious hours when the clock is running. Named owners and clear escalation prevent the paralysis that strikes unprepared teams mid-incident.

Crucially, the runbook must be tested. A tabletop exercise walking a realistic scenario through detection, decision and notification reveals the gaps — unclear ownership, missing contacts, slow approvals — that only surface under pressure.

Turning a crisis into a controlled process

Done well, breach response transforms a potential catastrophe into a controlled, defensible process. The organisations that fare best are not those that never have incidents — incidents are inevitable — but those that respond quickly, transparently and competently.

Because penalties of up to ₹200 crore attach to notification failures specifically, the ability to report correctly and on time is itself a major risk control, independent of how well you prevent breaches in the first place.

Investing in detection, logging, a tested runbook and ready templates is therefore among the highest-return actions in any compliance programme — insurance you hope never to use but cannot afford to lack.