DPDP breach notification runs on two clocks, not one. Rule 7 requires you to tell each affected Data Principal without delay, and to give the Data Protection Board a first intimation without delay. Only the Board's detailed submission carries the 72-hour deadline, and it runs from the moment you became aware of the breach.
Most circulating summaries get this backwards. They describe a single 72-hour window and apply it to individuals, which is both wrong and dangerous: "without delay" is the tighter standard, and it governs the duty with a 200 crore rupee penalty band attached. A runbook built on the wrong clock fails on exactly the obligation you most needed it to cover.
What Rule 7 Actually Requires
Rule 7 requires two recipients and three separate communications, and it reads as confusing because one recipient gets told twice. Each affected Data Principal gets one intimation, without delay. The Board gets a first intimation without delay, then a detailed submission within 72 hours of your becoming aware, or a longer period the Board allows on a written request.
Nothing in the rule lets the individual notification wait for the Board filing, or for your investigation to conclude. The duties are independent, so a programme that treats the Board filing as the primary deliverable and the customer email as a follow-up has inverted the risk.
The penalty structure makes the asymmetry concrete. The Schedule to the Act sets a band of up to 200 crore rupees for failure to give the Board or affected Data Principals notice of a personal data breach, under section 8(6) — separate from the up-to-250-crore band for failing to take reasonable security safeguards under section 8(5). You can be penalised for the notification failure even where the safeguards themselves were defensible.
Rule 7 sits in the eighteen-month commencement tranche, which lands in mid-May 2027 as a single cliff rather than a ramp — no partial-credit period in which an incomplete runbook is acceptable.
The Three Communications, Side by Side
The 3 communications differ in recipient, contents and clock, and only 1 of the 3 carries an hour count. Pin them inside the incident runbook as a single table.
| Recipient | What you send | Clock |
|---|---|---|
| Each affected Data Principal | Description, nature, extent and timing; consequences relevant to her; mitigation already implemented or under way; safety measures she can take; business contact details of someone who can answer her questions | Without delay |
| The Board, first intimation | Description including nature, extent, timing and location of occurrence, and likely impact | Without delay |
| The Board, detailed submission | Updated detail; broad facts, circumstances and reasons; mitigation implemented or proposed; findings on who caused it; remedial measures to prevent recurrence; a report on the intimations given to affected Data Principals | Within 72 hours of becoming aware, or a longer period the Board allows on written request |
Assign ownership per row, not per incident. The Board's first intimation belongs to whoever runs the incident, since it is a factual description of what is known and files straight from the incident record. The detailed submission belongs jointly to the incident commander and legal or privacy counsel, because it asserts causation and remediation. The Data Principal intimation belongs to the function that can actually reach customers — support, marketing operations, whoever owns the mail platform — working from pre-approved copy.
Three rows, three named owners, three named deputies. If one person owns all three, the third one gets sent late.
Becoming Aware Is What Starts the Clock
Becoming aware triggers the 72-hour clock, and it is not the same thing as detection. The gap between the two is where programmes actually fail, because a clock that starts earlier than your process assumes consumes the window before anyone has decided an incident exists.
An alert fires at 02:00 and the on-call engineer defers it as noisy. At 09:00 a second engineer links it to an exposed storage bucket. At 14:00 a manager calls it a personal data breach and pages legal. You do not get to pick the latest of those because it is the most convenient. The defensible reading is the point at which your organisation held information from which a reasonable person would conclude personal data had been compromised, which is usually earlier than the formal declaration.
Two controls close the gap. Give the on-call rota authority to declare a suspected personal data breach without management confirmation, and make the declaration cheap to reverse; a programme that penalises false positives produces exactly the delay that costs the window. Then timestamp everything. Rule 6's third safeguard requires visibility on access through logs, monitoring and review sufficient to detect unauthorised access and support investigation and remediation, and that same trail is what later evidences when you knew. Its one-year retention floor for logs and personal data, unless another law requires otherwise, exists partly so the record survives the incident.
Write the awareness determination down at the time, with the facts it rested on. Reconstructing it three weeks later, under inquiry, from Slack scrollback is a bad position to be in.
Want your rule 7 runbook reviewed against both clocks?
Share your work email and we'll walk your existing incident response plan against rule 7 — awareness trigger, the three communications, named owners and the affected-population query you would need to run.
What Goes in Each Communication
What goes in each communication is specified in the Rules precisely enough that all 3 templates can be built from the rule text rather than from invented fields. Writing one from scratch during an incident is how required elements get omitted.
The Data Principal Intimation
The Data Principal intimation carries 5 required elements: a description of the breach including its nature, extent and timing; the consequences relevant to her; the mitigation measures already implemented or under way; the safety measures she can take to protect her interests; and the business contact details of a person able to answer her questions.
Read that list as 5 mandatory blocks. The two that drafts usually miss are the safety measures she can take — advice she can act on, not a general reassurance — and the named contact, discussed below. "Consequences relevant to her" also resists a single template: a leaked email address and a leaked identity document have different consequences, so the template needs a variable block keyed to data category.
The Board's First Intimation
The Board's first intimation is narrower, asking for 5 facts and nothing more: a description including the nature, extent, timing and location of occurrence, and the likely impact. It is a factual notice rather than an analysis, and it is due without delay.
Because it asks for so little, the incident commander should be able to file it within hours of awareness. Teams that stall here are usually trying to answer questions the first intimation never asked — cause, attribution, remediation. Those belong in the detailed submission.
The 72-Hour Detailed Submission
The 72-hour detailed submission is the one with the hard deadline and the one that requires real investigative output. It carries updated detail; the broad facts, circumstances and reasons leading to the breach; mitigation measures implemented or proposed; findings on the person who caused it; remedial measures to prevent recurrence; and a report on the intimations given to affected Data Principals.
That last element is the structural reason the individual notification cannot be deferred. Your Board filing has to report on what you told individuals, so a programme that has notified nobody arrives at the 72-hour mark with a gap in its own submission.
The Rules allow a longer period where the Board permits it on a written request. Treat that as a request you may have to make under pressure, not as slack in the schedule: it has to be in writing, and the extension is the Board's to grant. Keep a draft in the runbook.
Why Telling Individuals Is the Harder Duty
Telling individuals is operationally harder than telling the Board, and the reason has nothing to do with drafting. The Board filing needs facts about the incident, which the incident team already has. The individual intimation needs an accurate list of affected people, which almost nobody has on the day.
To produce that list you need to know which systems hold personal data, which categories sit in each, which identifiers link a record to a contactable individual, and which records fall inside the compromised boundary. That is data inventory and mapping work, and it either exists before the incident or it does not get done during one. Teams discover this at the worst moment: forensics are clear, copy is approved, and "who do we send it to?" has no answer better than "everyone".
The practical test is whether you can answer today, in under a day: for a given system, which Data Principals have records in it, and how do we reach them? If that needs a bespoke engineering effort, rule 7 is not yet achievable at your organisation however good the plan document looks. The fix is a maintained inventory recording, per system and per data category, the identifier that resolves to a contact channel — plus a saved, tested query that produces the affected-population export.
Over-notification carries its own cost. Telling two million users about a breach that touched eight thousand of them is a support surge and a trust loss the facts did not require. Precision in the inventory buys proportionality in the notification.
Pre-Draft the Templates and Name the Contact
Pre-drafting the templates and naming the contact are the 2 preparation tasks that pay back fastest, because both are pure drafting work that cannot be compressed once a clock is running.
Pre-draft 4 artifacts and keep them in version control alongside the incident response plan, not in a shared drive nobody can find at 2am:
- The Data Principal intimation, with all 5 required blocks and variable sections for data category and the safety measures relevant to each.
- The Board's first intimation, structured as nature, extent, timing, location and likely impact, completable from the incident record.
- The detailed submission skeleton, with headings matching the required elements including the report on individual intimations.
- The written request for a longer period, for where the investigation genuinely cannot conclude inside 72 hours.
Then name the person. Rule 7 requires the Data Principal intimation to carry the business contact details of someone who can answer her questions, and the only way to satisfy that at speed is to decide in advance who it is, how they are reachable and what they are briefed to say. For a Significant Data Fiduciary notified under section 10 of the Act, the India-based Data Protection Officer appointed under section 10(2) is the obvious holder, since that person is already the contact point for grievance redressal. Everyone else needs a named individual with a monitored mailbox, a stated response expectation and a deputy — a shared alias with no owner answers nothing.
Brief them beforehand. They will be asked questions the breach notice does not answer, and the gap between what they are asked and what they may say is where a controlled notification becomes a public one.
Free runbook
The DPDP Breach Response Runbook
All three intimations drafted with worked example content, an awareness-determination checklist that decides when the clocks start, a role card naming the eight jobs an incident needs filled, and the preparation that cannot be done once an incident is running. Enter your work email and we'll send it.
Sector Regulators Run Alongside, Not Instead
Sector regulators impose their own incident reporting obligations, and those run alongside rule 7 rather than instead of it. An entity regulated by the Reserve Bank of India, the Securities and Exchange Board of India or the Insurance Regulatory and Development Authority of India already reports incidents under that regulator's own framework. Satisfying it does not discharge rule 7, and satisfying rule 7 does not discharge it.
Build the runbook to assume multiple recipients with independent triggers, contents and timelines. Sector incident reporting typically differs in what counts as reportable, in how the triggering event is defined, in the filing channel, and sometimes in having a tighter deadline than DPDP's. Check the deadline in your own regulator's instrument rather than assuming it matches the 72-hour breach report India has in rule 7, because where the sector rule is stricter it governs your schedule. The Ministry of Electronics and Information Technology publishes the DPDP instruments at meity.gov.in; your sector obligations come from your regulator's circulars, and both belong in one matrix.
What works is one incident record feeding several notification workstreams, each with its own owner, clock and template, and one timeline showing all of them against the awareness timestamp. What fails is a single "notify regulator" step that assumes one regulator.
Processors sit in this picture too. A Data Processor does not carry the rule 7 duty directly, but its customer does, and that customer cannot meet "without delay" if the processor takes a week to confirm an incident. Expect Indian enterprise buyers to impose a contractual notification deadline tighter than anything in the Rules, because they need it to be.
DPDP Breach Notification Questions Teams Ask
These are the DPDP breach notification questions teams ask most often once they realise rule 7 sets more than one clock.
No. The 72-hour clock applies only to the Board's detailed submission, measured from when you became aware of the breach. Affected Data Principals must be told without delay, which is the tighter standard. The Board also gets a first intimation without delay, so two of the three required communications carry no fixed hour count and should go out as soon as you have the facts they require. Treating 72 hours as the universal deadline is the most common error in circulating summaries, and it is the one that puts the notification duty at risk.
No, and the structure of rule 7 makes that clear. The Board's first intimation asks only for the nature, extent, timing and location of the breach and its likely impact — facts you have early. The Data Principal intimation asks for mitigation already implemented or under way, which assumes the response is still in progress. The detailed submission is where investigative conclusions belong, including findings on who caused the breach and remedial measures to prevent recurrence, and that is the filing with the 72-hour clock on it.
The Rules tie the detailed submission to becoming aware of the breach, not to a formal internal declaration. The defensible reading is the point at which your organisation held information from which a reasonable person would conclude personal data had been compromised, which is typically earlier than the moment a manager declares an incident. Close the detection-to-awareness gap by letting on-call staff declare a suspected breach without escalation, and record the awareness determination with the facts it rested on at the time.
Yes, but only by the Board and only on a written request. The rule allows the detailed submission within 72 hours of becoming aware or within a longer period the Board allows on written request. That is permission to be sought, not time you can assume, so keep a draft request in the runbook and treat the 72-hour date as the working deadline regardless. Nothing in the extension affects the without-delay clocks on the first intimation or the individual notifications.
No. Sector incident reporting obligations run alongside rule 7, not instead of it, and they generally differ in threshold, triggering event, recipient, contents and deadline. A regulated entity may need to file with its sector regulator and give the Board both a first intimation and a detailed submission and notify affected individuals, all from the same incident. Build the runbook as one incident record feeding several notification workstreams, each with a named owner and its own clock measured from the same awareness timestamp.
See the rule 7 clocks tracked as obligations, not as a plan document
Book a demo and we'll show how Konfirmity holds the awareness timestamp, the three rule 7 communications and their owners against one incident record, with the evidence the Board's detailed submission needs.
Book a demo
Build the Runbook Against Both Clocks
Build the runbook against both clocks, then test it. Pick a plausible scenario, start the stopwatch at a realistic awareness timestamp rather than a convenient one, and see whether 3 communications leave the building with every required element and a named person on the individual notice. Most teams fail that exercise on the affected-population list, not on the drafting.
The work that decides the outcome happens before the incident: the data inventory that resolves a compromised system to a contactable list of individuals, the 4 pre-drafted templates, the named contact with a briefed deputy, and the notification matrix that puts your sector regulator next to the Board rather than in place of it. None of it can be produced inside 72 hours.
Start with the inventory, since every other step depends on it, then wire rule 7 into the plan you already run instead of writing a parallel one. The DPDP compliance checklist shows where breach intimation sits among the twelve duties, the rule 6 security safeguards supply the logs that evidence when you knew, and if you already operate a GDPR incident response plan most of the machinery transfers once you correct the clocks. What does not transfer is the assumption of a single 72-hour deadline.
