DPDP breach notification: build the two-stage response

What actually counts as a personal data breach

Section 2(u) defines it broadly: 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.

Three words in that definition catch teams out. Accidental means intent is irrelevant - an email sent to the wrong recipient list qualifies. Alteration means a corrupting bug qualifies, not only a leak. And availability means a ransomware event that encrypts data you still hold, or a failed migration that loses access to it, is a breach even though nothing left the building.

The practical consequence is that breach intake cannot be a security-team mailbox. Signals arrive from support (a user seeing another user's data), from reliability (a restore that failed), from vendors, and from engineers who notice a misconfigured bucket. If the intake path only understands external attacks, most reportable events will be classified as ordinary incidents and never reach the clock.

Two audiences, and they are not on the same clock

Section 8(6) requires intimation to the Board and to each affected Data Principal. Rule 7 then splits those into different timings, and this is the part most incident plans get wrong.

Affected Data Principals must be informed without delay. There is no seventy-two hour grace period for telling the people whose data it is. The Board receives an initial intimation without delay as well, followed by fuller prescribed information within seventy-two hours, unless the Board allows longer on request.

So the seventy-two hours is not the deadline for discovering what happened before you tell anyone. It is the deadline for the Board's detailed follow-up. Reading it as a general grace period is the single most expensive misreading of Rule 7, because it delays the individual notice that has no grace period at all.

• Affected individuals: without delay, in the first stage.
• Board, stage one: intimation without delay.
• Board, stage two: prescribed detail within seventy-two hours, extendable on request.
• The clock starts on becoming aware, which makes detection capability a legal control.

Write the individual notice before the incident, not during it

The intimation to affected people has to describe the breach, its likely consequences, the measures being taken to mitigate risk, the safety measures they can take themselves, and the contact details of someone who can answer their questions.

That last item connects to section 8(9), which requires publication of the business contact information of a Data Protection Officer, where applicable, or of a person able to answer questions about the processing. If nobody is named and reachable before an incident, the notice cannot be completed during one.

Draft the template while calm. Incident-time writing produces either legalese nobody understands or reassurance that later turns out to be wrong, and both are worse than a plain description prepared in advance with the specifics left blank.

Rule 6 decides whether you can detect a breach at all

Section 8(5) requires reasonable security safeguards to prevent a breach. Rule 6 gives that content: measures such as encryption, obfuscation or masking, virtual tokens, access control, logs and monitoring, backups, and contractual measures binding processors.

Two of those are really breach-response controls wearing security clothing. Logs and monitoring are what let you know an event happened and determine its scope. Backups are what turn an availability breach into a recoverable incident. An organisation with neither will discover breaches from its customers and will be unable to tell the Board what was affected.

The Rules also require logs to be retained for a period sufficient to support investigation. Retention here works in the opposite direction to the erasure duty - you need the evidence to survive long enough to be useful. Those two obligations have to be reconciled deliberately rather than by whichever system happens to win.

Determining scope is the hard part, and it is a data problem

Every question the Board will ask is a scope question: which individuals, which data, over what period, through what route. Answering it requires knowing what personal data lives in the affected system and who it belongs to - which is the data inventory, built long before the incident.

Organisations without a purpose and system map answer these questions by exporting everything and reading it, under time pressure, during an active incident. That is how seventy-two hours becomes impossible and how notices go out describing the wrong population.

This is the strongest practical argument for doing the inventory work early. It is usually justified as a consent prerequisite, but its highest-value moment is the first serious incident.

Your processor's breach is your breach

Section 8(1) makes the Data Fiduciary responsible for compliance in respect of any processing undertaken by it or on its behalf, irrespective of any agreement to the contrary. A contractual clause allocating breach liability to a vendor does not move the statutory obligation.

That means the notification duty is triggered by an event at a processor exactly as it is by one in your own systems - and your seventy-two hours does not restart because the vendor took a fortnight to tell you. Section 8(2) requires processors to be engaged under a valid contract; Rule 6 requires that contract to carry security measures.

The clause that matters most is the notification clause, and it should require notice to you in hours rather than days, with a duty to preserve evidence and to co-operate with your investigation. Vendors will push back on tight timelines. The alternative is that you carry a statutory deadline you have no means of meeting.

Rehearse the decision, not just the technology

Most breach plans are tested as technical restores. The part that actually fails under pressure is the decision: is this a personal data breach, who decides, and on what evidence.

Run the exercise on ambiguous cases rather than obvious ones - a misdirected export, a contractor who kept a copy, a logging bug that wrote personal data to an unsecured stream for months. Those are the ones where teams disagree, escalate slowly and lose the day that mattered.

Record the decision and its reasoning either way. A defensible contemporaneous assessment concluding that an event was not reportable is worth far more later than a silent decision to do nothing.

• A named decision-maker, with a named deputy, reachable out of hours.
• A written test for reportability, applied to ambiguous cases in advance.
• Pre-drafted individual and Board templates with the specifics left blank.
• A contact point published under section 8(9) before you need it.
• An evidence log started at the first signal, not after triage.

What the Schedule says about getting this wrong

The Schedule places breach-related failures at the top of the penalty range. Failure to take reasonable security safeguards to prevent a personal data breach carries a ceiling of two hundred and fifty crore rupees - the highest in the Act. Failure to notify the Board or affected Data Principals carries up to two hundred crore.

Those are ceilings rather than tariffs. Section 33(2) requires the Board to have regard to the nature, gravity and duration of the breach, the type of personal data affected, whether the person mitigated the impact and how promptly, and their compliance history, among other factors.

Read together, the two provisions reward exactly the behaviour a good plan produces: fast detection, prompt mitigation, honest and timely notification, and a record that shows all three. The organisation that reports quickly and mitigates well is being assessed on a different footing from the one that concealed the same event.

DPDP is not the only breach clock you are on

An Indian organisation handling a security incident is usually subject to more than one reporting duty at once, and the DPDP timeline is not the tightest of them.

The CERT-In directions issued in April 2022 under section 70B(6) of the Information Technology Act, 2000 require specified cyber incidents to be reported within six hours of noticing them. Regulated sectors add more: banks, payment operators, insurers and market intermediaries carry their own incident-reporting obligations to the RBI, IRDAI or SEBI, with their own definitions and their own deadlines.

These duties are cumulative, not alternative. Satisfying CERT-In does not discharge section 8(6), and telling the Board does not discharge a sectoral direction. A single incident-response runbook should carry every clock the organisation is on, side by side, because the six-hour one will expire while the team is still deciding whether the seventy-two-hour one has started.

• CERT-In: six hours from noticing, for specified incident types.
• DPDP Board: intimation without delay, detail within seventy-two hours.
• Affected individuals: without delay, under Rule 7.
• Sectoral regulator: on its own terms, where you are regulated.
• Contractual: customer and partner notification clauses, often forty-eight hours.

The failures that recur

Incident reviews across organisations tend to surface the same handful of problems, and none of them are exotic. They are worth checking for directly rather than waiting to discover them under pressure.

The most common is a detection gap: the event is real, but nothing in the estate would have surfaced it, so the clock never starts until a third party makes contact. The second is scope paralysis - the team knows a system was affected but cannot enumerate whose data was in it, so notification stalls while an export is analysed.

The third is quieter and more damaging. Teams treat the seventy-two hours as permission to wait, and delay the individual notice that Rule 7 requires without delay. The Board's detailed report and the individual notice are different obligations with different timing, and conflating them converts a well-handled incident into a reporting failure.

What to build before 13 May 2027

The breach provisions commence with the main operational tranche on 13 May 2027. The build order matters, because the controls compound - detection makes notification possible, and inventory makes scope determination possible.

Start with logging and inventory, because they have the longest lead time and the widest system footprint. Templates and decision procedures can be written in a week; the ability to answer which individuals were affected cannot.

• Breach intake from security, support, reliability, vendors and engineering.
• Logging and monitoring adequate to detect and scope an event.
• A data inventory that maps systems to individuals and purposes.
• Processor contracts with tight notification and evidence-preservation duties.
• Pre-drafted notices for both audiences, and a published section 8(9) contact.
• A rehearsed reportability decision with a named owner.