DPDP Breach Notification: The Rule 7 Playbook

Who this is for: CISOs, security leaders, compliance heads and legal counsel who will own the response when a breach happens, and who need a process that meets the DPDP Act's timelines under pressure.

Every organisation plans for breaches it hopes will never happen. Under the DPDP Act, the quality of that plan has direct legal consequences. Notification is mandatory for every personal data breach, two of the three notices are due "without delay", and the Data Protection Board must weigh how quickly and effectively you responded when it sets a penalty.

This playbook sets out exactly what Rule 7 requires, when the clock starts, what each notice must contain, how DPDP reporting fits alongside CERT-In, and how to build a response that holds up. For the wider legal context, see The DPDP Act, Explained. Rule 7 takes effect on 13 May 2027, as set out in our DPDP compliance timeline.

What counts as a personal data breach?

Section 2(u) of the Act defines a personal data breach as any unauthorised processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration or destruction of, or loss of access to, personal data, that compromises its confidentiality, integrity or availability.

The definition is deliberately wide. It covers far more than a hacker exfiltrating a database:

The three notifications at a glance

Rule 7 creates three separate duties. Treat them as parallel workstreams, not a sequence.

The common mistake is to treat 72 hours as the deadline. It is only the deadline for the detailed report. The notices to individuals and the initial Board intimation are due earlier: "without delay" means as soon as you reasonably can, not at the end of three days.

When does the clock start?

All three duties run from the moment you become aware of a personal data breach. This is a factual question, and the Board will look at your records to answer it.

In practice, awareness is not the first alert in your SIEM. It is the point at which your organisation has a reasonable degree of certainty that a security incident has affected personal data. But you cannot delay awareness by delaying investigation. Build your process so that:

• every security incident is assessed for personal data impact as a standard triage step
• the time of that assessment, and of the decision that personal data is affected, is logged
• the decision is taken by a named role (typically the DPO or incident lead), not left to whoever is on shift

The awareness timestamp is the single most important record in your breach file. It anchors every deadline that follows.

Notifying affected individuals

Rule 7(1) requires you to notify each affected Data Principal, to the best of your knowledge, without delay, in a concise, clear and plain manner, through their user account or any mode of communication they have registered with you. The notice must include:

1. a description of the breach, including its nature, extent, and the timing and location of occurrence
2. the consequences relevant to them that are likely to arise from the breach
3. the mitigation measures you have implemented or are implementing
4. the safety measures they can take to protect their interests
5. the business contact information of a person who can respond to their queries

A strong notice is specific and actionable. Compare these two openings:

• Weak: "We recently became aware of a security incident that may have affected some customer information."
• Strong: "On 3 June, we found that an unauthorised party accessed a database containing your name, mobile number and order history. Your payment card details were not stored in this database. We recommend that you ignore unexpected calls or messages claiming to be from us and asking for OTPs."

Write the notice for the individual, not for your legal team. Translate it into the languages your customers use, and prepare templates in advance so the first notice is not drafted at 2 a.m.

Notifying the Data Protection Board

Initial intimation (Rule 7(2)(a)), without delay. A description of the breach, including its nature, extent, timing and location of occurrence, and its likely impact. This is a first account, not a full investigation. Submit what you know and say what you are still establishing.

Detailed report (Rule 7(2)(b)), within 72 hours. The report must include:

1. updated and detailed information on the description already provided
2. the broad facts relating to the events, circumstances and reasons leading to the breach
3. measures implemented or proposed to mitigate risk
4. any findings about the person who caused the breach
5. remedial measures taken to prevent recurrence
6. a report on the notifications given to affected individuals

If a credible report genuinely cannot be completed within 72 hours, for example because forensic analysis is still running, request an extension in writing before the deadline. An extension the Board has granted puts you in a very different position from a deadline you missed.

Running DPDP and CERT-In reporting together

Many Indian organisations are also bound by CERT-In's Directions of 28 April 2022 under Section 70B(6) of the IT Act. They require specified types of cyber incidents to be reported to CERT-In within 6 hours of noticing them, and ICT system logs to be maintained for 180 days within India.

One ransomware attack can trigger both regimes, plus any sector regulator's reporting rules (for example, from the RBI, SEBI or IRDAI). Run one incident process with a single timeline, and assign each regulatory notice to a named owner. Do not let three teams draft three different accounts of the same facts.

When the breach is at your vendor

Many breaches happen at a processor: a cloud provider, CRM platform, payroll bureau or call centre. Under Section 8(1), you remain responsible for compliance, including notification. Your 72 hours start when you become aware, but you can only become aware if your vendor tells you.

Your processor contracts should therefore require:

• notification to you of any suspected breach within a short, fixed window (many organisations set 12 to 24 hours or less)
• the information you need for Rule 7: affected data categories, numbers of individuals, timeline and root cause
• cooperation with your investigation and with the Board
• the reasonable security safeguards required by Rule 6, written into the contract as Rule 6 itself requires

Penalties, and how your response reduces them

Two penalties in the Schedule to the Act relate directly to breaches:

• up to ₹250 crore for failing to take reasonable security safeguards to prevent a personal data breach (Section 8(5))
• up to ₹200 crore for failing to notify the Board or affected individuals of a breach (Section 8(6))

Under Section 33(2), when setting a penalty the Board must consider factors including the nature, gravity and duration of the breach, the type of personal data affected, whether the breach was repeated, and the action taken to mitigate its effects, and the timeliness and effectiveness of that action. Section 32 also allows the Board to accept a voluntary undertaking from a fiduciary during proceedings.

In other words, a fast, honest, well-documented response is not just good practice. It is a legal factor in how much you pay.

Prevention is the bigger penalty

The highest penalty under the Act is not for failing to report a breach. It is for failing to prevent one. Rule 6 sets out the minimum reasonable security safeguards:

• appropriate encryption, obfuscation, masking or virtual tokens
• access controls on computer resources that process personal data
• logs, monitoring and review to detect unauthorised access, and to investigate and remediate it
• measures such as backups to keep processing going if data is compromised
• retention of logs and personal data for at least one year to support detection and investigation
• matching safeguards written into processor contracts
• technical and organisational measures to make sure all of this is actually followed

A strong notification process does not offset weak security. The Board will look at both.

An hour-by-hour response plan

The step that usually takes longest is identifying whose data was affected. Organisations with an up-to-date Record of Processing Activities can answer that in hours. Those without one can spend days.

Breach readiness checklist

Common breach notification mistakes

• Treating 72 hours as the only deadline. Individuals and the Board must be notified without delay. The 72 hours is only for the detailed report.
• Waiting for certainty before notifying. The initial intimation is meant to be preliminary. Update it as facts emerge.
• Applying a GDPR-style risk threshold. The DPDP Act has no "unlikely to result in risk" exception.
• Forgetting vendors. If your contracts do not force fast notification from processors, your clock can run out before you know there is a breach.
• Writing notices for lawyers. Vague, defensive notices fail the Rule 7 requirement to be concise, clear and plain, and they damage trust.

How ConsentifyAI helps

When a breach happens, the hardest questions are whose data was affected, how to reach them, and how to prove what you did. ConsentifyAI links incident records to your Record of Processing Activities, so you can identify affected data categories, systems and individuals quickly. It tracks each Rule 7 notice against its deadline, uses the contact channels individuals have registered, and records every step in a tamper-evident audit trail that feeds directly into the 72-hour report.