DPDP Breach Notification Template & Response Playbook: A 72-Hour Step-by-Step Guide for Indian Businesses

Why "We'll Write It When It Happens" Is the Most Expensive Plan You Can Have

Every Indian business will eventually deal with a personal data incident — a misconfigured S3 bucket, a phished employee, a vendor leak, a lost laptop. Under the Digital Personal Data Protection (DPDP) Act, the operational question stops being "did we handle it well internally?" and becomes "did we file the right notice with the right authority in the right format within 72 hours of awareness?"

The companies that come out of a breach with their reputation intact are not the ones with the cleanest perimeter. They are the ones who pre-built the response. This guide gives you:

• A ready-to-adapt DPBI breach notification template aligned to what the Act and the draft DPDP Rules 2025 expect.
• A separate Data Principal (user) notification template in plain Indian English.
• An hour-by-hour response playbook covering the first 72 hours — and the CERT-In 6-hour parallel clock you cannot forget.

For the rule itself — what triggers the clock, who needs to be told, what counts as "awareness" — start with our 72-hour breach notification rule guide. This post is the operational complement: the templates and the playbook you actually pull out when an incident lands.

The Two Notifications You Must Send

Under the DPDP Act, a personal data breach triggers two distinct notification obligations, plus a third under the CERT-In Directions of April 2022:

1. To the Data Protection Board of India (DPBI) — notify "without delay" and submit a detailed report within 72 hours of awareness.
2. To every affected Data Principal — every individual whose data was involved, in clear, plain language.
3. To CERT-In — within 6 hours of detecting any reportable cybersecurity incident, under the April 2022 Directions.

A single breach can trigger all three clocks simultaneously. Each notification has its own template, its own audience, and its own consequences if you get it wrong.

Template 1 — Notification to the Data Protection Board of India (DPBI)

This is the detailed report due within 72 hours. The draft DPDP Rules 2025 expect the notification to cover, at minimum, the nature of the breach, the categories and approximate number of Data Principals affected, the likely consequences, the measures taken, and a point of contact. Use the template below as your starting structure.

DPBI Breach Notification — Template

(Adapt the fields below. File via the channel the DPBI prescribes at the time of the incident — the Board's reporting portal once operational, and a written backup to the official email of record.)

To: Data Protection Board of India

From: [Legal Name of Data Fiduciary], [Registered Address]

Reference: Personal Data Breach Notification — [Incident Reference Number] — [Date]

1. Reporting Entity

• Legal name of Data Fiduciary: [Name]
• CIN / Registration number: [Number]
• Registered office: [Address]
• DPDP point of contact: [Name, designation, email, phone]
• Data Protection Officer (if applicable): [Name, email, phone]

2. Incident Summary

• Date and time of breach (best estimate): [YYYY-MM-DD HH:MM IST]
• Date and time of awareness: [YYYY-MM-DD HH:MM IST]
• Date and time of this notification: [YYYY-MM-DD HH:MM IST]
• Nature of the breach (confidentiality / integrity / availability): [Describe]
• Brief description of what happened in 3–4 plain-language sentences: [Description]

3. Data Affected

• Categories of personal data involved: [e.g., name, email, phone, PAN, transaction history]
• Special categories or sensitive data (e.g., financial, health, children's data): [Yes / No / Describe]
• Approximate number of records: [Number or range]
• Approximate number of Data Principals affected: [Number or range]
• Whether children's data is involved (Data Principals under 18): [Yes / No]

4. Likely Consequences

• Anticipated harm to Data Principals (financial, reputational, identity-theft risk, discrimination, distress): [Describe]
• Risk classification (low / medium / high) and reasoning: [Describe]

5. Measures Taken

• Immediate containment actions (e.g., access revoked, systems isolated): [Describe with timestamps]
• Remediation in progress: [Describe]
• Forensic investigation status: [In progress / complete + brief findings]
• External parties engaged (forensic firm, counsel, vendor): [List]

6. Notification to Data Principals

• Method of notification (email, SMS, in-app, registered post): [Describe]
• Date and time notification began: [YYYY-MM-DD HH:MM IST]
• Approximate completion timeline: [Date]
• Sample of notification text: [Attach as Annexure A]

7. Lessons Learned and Preventive Steps

• Root cause (preliminary): [Describe]
• Controls being added or strengthened: [Describe]
• Timeline for completion of remediation: [Date]

8. Supporting Documentation

• Annexure A: Sample Data Principal notification
• Annexure B: Internal incident timeline
• Annexure C: CERT-In notification reference (if separately filed)
• Annexure D: Forensic report (if available)

Signed: [Authorised signatory name, designation, date]

Template 2 — Notification to Affected Data Principals

The user-facing notification must be in clear, plain language. It must say what happened, what it means for the user, and what they should do. Avoid legalese. Translate it into the languages your users actually read — Schedule 8 of the Constitution lists 22.

Data Principal Breach Notification — Template

Subject line: Important: Information about your account and a recent security incident

Hello [User First Name],

We are writing to let you know about a security incident that may have affected your information with [Company Name], and to tell you what we are doing about it and what you can do to protect yourself.

What happened

On [date], we discovered that [plain-language description of the incident — for example, "an unauthorised person was able to access one of our internal systems for a short period"]. We immediately took steps to stop the access and to find out what was affected.

What information was involved

Based on our investigation so far, the information involved for your account may include:

• [List specific categories — e.g., name, email address, phone number, transaction history]

We have no evidence at this time that [list categories that were NOT affected — e.g., your password, your PAN, your bank account number] was accessed.

What we are doing

• We have closed the path the attacker used and added new safeguards.
• We are working with independent security experts to confirm the full scope of the incident.
• We have notified the Data Protection Board of India and other relevant authorities as required.
• We are monitoring our systems closely for any unusual activity related to this incident.

What you can do

• Be alert for unexpected emails, calls, or messages claiming to be from us or asking you for sensitive information. We will never ask for your password, OTP, or PIN.
• If you reuse the password from your [Company Name] account anywhere else, change it on those other services as soon as you can.
• Review your account activity at [link]. If you see anything unusual, contact us immediately.

How to reach us

If you have any questions, please contact us at [dedicated breach support email] or [phone number]. You also have the right to make a complaint to the Data Protection Board of India.

We are sorry that this happened, and we are committed to being open with you about what we know as we learn more.

Regards,
[Senior named executive]
[Company Name]

The 72-Hour Response Playbook, Hour by Hour

Key Insight: The 72 hours start at awareness, not at occurrence. If a Friday-evening SOC alert at 6 p.m. is the first confirmed signal, your detailed DPBI report is due by 6 p.m. on Monday. Bake the weekend into your plan.

Hour 0 — Awareness

• Confirm the signal is a probable personal data breach (not just any security event).
• Page the on-call breach commander. Open a dedicated war-room channel.
• Start the immutable incident log. Every action from here gets a timestamp.
• Issue a preservation hold on relevant systems, logs, and backups.

Hours 0–2 — Contain and Triage

• Isolate the affected systems where possible without destroying forensic evidence.
• Revoke compromised credentials and access tokens.
• Begin the CERT-In assessment. If the incident matches a reportable category under the April 2022 Directions, file the CERT-In notification within the 6-hour window.
• Notify the standing breach response team: security, legal, communications, DPO, executive sponsor.

Hours 2–12 — Scope

• Identify which categories of personal data are involved.
• Run the consent and data map query: who are the affected Data Principals, and how do we reach them?
• Engage external forensics if the scope is unclear or the incident is material.
• Draft the executive briefing: what happened, what we know, what we do not yet know.

Hours 12–36 — Investigate and Draft

• Forensic investigation continues. Update the incident log every two hours.
• Begin filling in the DPBI notification template using the facts available — do not wait for a perfect picture.
• Begin filling in the Data Principal notification template. Get it legally reviewed and translated into the languages of the affected users.
• Prepare your internal communications: customer support brief, sales brief, social media holding statement.

Hours 36–60 — Validate and Approve

• Final legal review of both notifications.
• CEO or senior executive sign-off on the Data Principal notification.
• Confirm the delivery channels for the user notification — email service ready, SMS provider ready, in-app banner ready.
• Confirm the filing channel for the DPBI report.

Hours 60–72 — File and Notify

• File the DPBI report. Save the acknowledgement.
• Send the Data Principal notifications. Begin the delivery in waves if your customer base is large enough that a single blast would overwhelm support.
• Publish the public statement and the dedicated incident FAQ page.
• Brief customer support with the FAQ, the escalation path, and the legal-approved talking points.

After Hour 72 — Sustain

• Continue investigation. File supplementary updates to the DPBI as new facts emerge.
• Monitor for phishing attacks impersonating your breach notification — attackers know users are primed to click.
• Hold a post-incident review within 14 days. Capture what worked, what failed, what to fix.
• Update the playbook. The next breach should be at least one step easier than this one.

What Makes a Breach Notification Land Well

The difference between a notification that earns user trust and one that destroys it is rarely the speed. It is the tone, the specificity, and the follow-through.

1. Be specific about what was and was not affected. Vague notifications ("some user information may have been accessed") spread panic. Specific notifications ("your name and email were involved; passwords were not") let users assess their own risk.
2. Use plain language. If a phrase needs a glossary, rewrite it. The DPDP Rules 2025 explicitly require plain-language notices.
3. Lead with action. Users want to know what they should do. Bury the legal disclaimers; surface the practical steps.
4. Sign with a named executive. "Regards, the [Company] team" is not accountability. A named CEO, COO, or DPO is.
5. Open a dedicated channel. A breach-only email address and FAQ page, with a real human responding, signals that you are taking it seriously.
6. Follow up. Send a second update when the investigation closes. Silence after the first notification reads as a cover-up.

The Pre-Breach Investments That Make This Playbook Executable

None of the templates above are useful if, at hour 12, you cannot answer "whose data was in scope?" The playbook depends on infrastructure that has to be in place before the breach happens:

• A centralised consent and data map that tells you, in minutes, which Data Principals are affected and through which purposes.
• An immutable consent ledger so you can show the Board exactly what each affected user consented to and what notice they saw.
• A multilingual notification capability so the Data Principal notice goes out in the languages your users actually read.
• A pre-tested incident channel — the wrong day to discover your email service rate-limits at 50,000 sends per hour is the day you have to notify 200,000 customers.
• A quarterly tabletop drill. Every gap you find in a drill is a gap you will not find in a real incident.

How Consently Supports Breach Response

Consently is built so that the worst day of your year is at least the most prepared. Our platform gives you the consent and data foundation the playbook depends on:

• A consolidated consent ledger queryable by purpose, product, and Data Principal — answer "who is affected" in minutes.
• Per-purpose, per-version consent records with immutable timestamps, exportable as evidence.
• Multilingual notification support across all 22 Schedule 8 languages, so user notifications go out in the language each user actually reads.
• India-resident infrastructure on the Mumbai region, with on-premise and sovereign-cloud options for enterprises that need full control.
• Zero-PII Consent ID architecture — the consent layer itself is a smaller breach target.
• Webhooks and APIs that plug into your incident management tooling so the consent system is in the war room from minute one.

The 72-hour rule rewards preparation and punishes improvisation. The templates above will get you started; the underlying consent and data infrastructure is what makes them actually work under pressure. Talk to the Consently team about getting your breach-readiness foundation in place — or revisit the underlying rule with our 72-hour breach notification rule guide first.