Rule 7: breach intimation under the DPDP Rules 2025

01 · What Rule 7 requires

Rule 7 of the Digital Personal Data Protection Rules 2025 governs what a Data Fiduciary must do on becoming aware of a personal data breach. It creates two distinct duties that run at the same time: tell the affected data principals, and tell the Data Protection Board. Neither waits for the other, and neither waits for certainty.

The obligation attaches to any breach of personal data, not only to breaches that cause demonstrable harm. There is no volume threshold and no materiality filter written into the rule. A single record, wrongly disclosed, is in scope.

The rule is also indifferent to who was operating the system. If a processor lost the data, the Data Fiduciary still files.

02 · When the clock starts

Every deadline in Rule 7 is measured from awareness. Nothing else in the rule is as consequential, and nothing else is as often reconstructed after the fact by someone reading your logs.

Two practical consequences follow. First, awareness is organisational, not individual: a support agent who sees customer records in a public bucket has made the organisation aware, whether or not the DPO was copied. Second, awareness is a finding of fact that your own records will settle. Ticket timestamps, alert emails and chat messages are the evidence, and they are rarely flattering.

Write down the awareness timestamp the moment you set it, with the reason you chose it. Changing it later without a documented basis is worse than choosing an early one.

03 · Intimation to the Board

The first intimation to the Board is made without delay, on the facts as they stand. It is not a forensic conclusion and should not read like one. State what happened, when it happened, when you became aware, what data and how many principals appear to be involved, and what you have already done to contain it.

Use ranges and say they are ranges. An intimation that reads “approximately 40,000–60,000 records, being verified” is stronger than a precise number you later correct.

04 · Notice to data principals

Each affected data principal is told directly, in plain language, on a channel they already receive communication from you on. The notice describes the breach and its likely consequences, the measures you have taken, what the individual can do to protect their own interests, and how to reach you or the Board.

The practical failure here is logistical rather than legal. Three million SMS notifications require a template registered on DLT, a sending window, and someone answering the calls that follow. Sequence that work before an incident, not during one.

A public notice on your website does not substitute for individual intimation where you hold contact details.

05 · The detailed report

Within seventy-two hours of awareness — or the longer period the Board allows on written request made before the window closes — you file the detailed report: an updated account of the breach and its circumstances, findings on the cause including any processor involvement, the remedial and preventive measures taken, and a report on the intimations sent to affected data principals.

Requests for more time are made inside the window, in writing, with a stated reason. Silence for seventy-three hours is not an extension.

06 · The CERT-In overlap

Most personal data breaches in Indian organisations are also cyber incidents, and the CERT-In directions of 2022 impose their own, much shorter clock.

Regulated sectors stack further reporting on top — RBI for banks and NBFCs, IRDAI for insurers, SEBI for market intermediaries. Map your reporting obligations once, in advance, and keep the formats side by side in the response plan.

07 · Worked example

A mid-size lending platform. A KYC document store operated by a processor is publicly indexed. Timestamps below are IST, and the awareness question is the whole exercise.

1. 02 Jun · 21:14Processor misconfigures a storage bucket. Nobody notices.
2. 11 Jun · 07:02A support agent receives a customer email containing someone else's Aadhaar image. Ticket logged, not escalated.
3. 13 Jun · 06:40Awareness. A journalist emails the CISO with a working link. All clocks start here on the organisation’s own reading.
4. 13 Jun · 12:40CERT-In six-hour window closes. Initial report filed at 11:20 — inside it, on ranges.
5. 13 Jun · 15:10Intimation to the Board. Principal notification begins in batches the same evening.
6. 14 Jun · 18:30Processor logs arrive. First unauthorised access is dated 02 Jun, and the 11 Jun ticket surfaces in review.
7. 16 Jun · 06:40Rule 7(2) detailed report due. Filed at 04:15, disclosing both the 02 Jun access and the 11 Jun ticket.

The 11 June ticket is the exposure. An investigator can argue the organisation was aware two days earlier than it claimed, which would have made the CERT-In report and the first intimation late. The defensible position is the one taken here: disclose the ticket in the detailed report, explain why awareness was fixed at 13 June, and show the control change that stops a next ticket from sitting unescalated.

08 · Evidence to keep

• The awareness determination, with its timestamp and its stated basis
• A decision log for the response, timestamped as decisions were taken
• Copies of every filing as submitted, with acknowledgements
• Evidence of principal notification: template, send logs, bounce handling
• Rule 6 logs for the affected systems, retained for one year
• Processor correspondence, including when they told you and what they said

A breach plan that has never been run against a clock is an untested control. We test them in Fortis Drills, and against your own systems in a DPDP Gap Assessment.