Data breach notification template
for India.
Four ready-to-edit notices built from the text of the law: the DPDP Rule 7 initial intimation to the Board, the 72-hour detailed report, the notice to each affected Data Principal, and a CERT-In incident report. Copy them, fill the brackets, and have counsel review them.
How to use these templates
Prepare them now, not during the incident. Fill in everything that does not depend on the incident: your legal name, address, contacts, CERT-In point of contact and channels. Store the result where the incident lead can reach it at 02:00. During an incident, one person fills the brackets from the incident record so the four documents agree on times and numbers.
- Order: CERT-In report first (six hours), then the Board's initial intimation and the notices to people (without delay), then the Board's detailed report (72 hours)
- Times: always in IST with the time zone written out, and taken from synchronised clocks
- Do not guess: 'under investigation' is better than a number you later have to correct
- Keep copies of every notice as sent, with its timestamp. The 72-hour report must describe them
The DPDP duties apply from 13 May 2027, under section 8(6) of the DPDP Act and Rule 7 of the DPDP Rules 2025. The CERT-In duty applies now, under the Directions of 28 April 2022.
1. Initial intimation to the Data Protection Board
Due without delay after becoming aware. Rule 7(2)(a) asks for a description of the breach, including its nature, extent, timing and location of occurrence, and the likely impact. Nothing more is required at this stage, which is the point: send it early.
INTIMATION OF PERSONAL DATA BREACH: INITIAL
Under section 8(6) of the Digital Personal Data Protection Act, 2023 and Rule 7(2)(a) of the DPDP Rules, 2025
To: Data Protection Board of India
From: [Legal name of Data Fiduciary], [registered address]
Reference: [Internal incident ID]
Date and time: [dd/mm/yyyy hh:mm IST]
1. Contact for this intimation
[Name], [role], [email], [phone]
2. Description of the breach
Nature: [What happened, e.g. unauthorised access to a production database replica
using a leaked access key]
Extent: [Categories of personal data affected; approximate number of Data Principals
and records; whether children's data is involved]
Timing: Occurred [dd/mm/yyyy hh:mm IST or "under investigation"]
Became aware [dd/mm/yyyy hh:mm IST]
Location: [Systems, data stores and their locations or cloud regions]
3. Likely impact
[Plain statement of the likely consequences for the Data Principals affected]
4. Status
[Contained / containment in progress]. A detailed report under Rule 7(2)(b) will follow
within 72 hours of [time of becoming aware].
[Name, designation, signature]What each part is for. Sections 2 and 3 are the whole of Rule 7(2)(a). Section 1 gives the Board someone to call. Section 4 commits you to the 72-hour report and records the awareness time the Board will count from.
2. Detailed report to the Board within 72 hours
Rule 7(2)(b) lists six items, numbered (i) to (vi) below in the same order so the Board can check them off. If you cannot complete it in time, ask the Board in writing for a longer period before the 72 hours run out.
DETAILED REPORT ON PERSONAL DATA BREACH
Under Rule 7(2)(b) of the DPDP Rules, 2025
To: Data Protection Board of India
From: [Legal name of Data Fiduciary]
Reference: [Internal incident ID]; initial intimation sent [dd/mm/yyyy hh:mm IST]
Became aware: [dd/mm/yyyy hh:mm IST]
Report due by: [awareness time + 72 hours] (or extended date allowed by the Board: [date])
(i) Updated and detailed description
[Nature, extent, timing and location as now known; what has changed since the
initial intimation]
(ii) Broad facts: events, circumstances and reasons leading to the breach
[Timeline from first malicious or accidental event to detection; root cause as
currently understood]
(iii) Measures implemented or proposed to mitigate risk
[e.g. credentials revoked at hh:mm; affected store isolated; forced password reset
for affected accounts; monitoring for misuse]
(iv) Findings regarding the person who caused the breach
[Internal / external / unknown; what is known; whether reported to law enforcement]
(v) Remedial measures to prevent recurrence
[Control changes, owners and dates]
(vi) Report on intimations to affected Data Principals
Number of Data Principals notified: [n] of [N] affected
Channels used: [user account notification / registered email / SMS]
Sent between: [dd/mm/yyyy hh:mm] and [dd/mm/yyyy hh:mm IST]
Copy of the notice: [attached]
Those not yet reached and why: [details]
Other notifications made: CERT-In [dd/mm/yyyy hh:mm]; [sector regulator] [time];
[EU supervisory authority] [time]
[Name, designation, signature]What each part is for. (i) to (v) mirror Rule 7(2)(b)(i) to (v). Item (vi), the report on intimations to Data Principals, is the one teams forget; it shows the Board that people were told, how and when. The 'other notifications' line keeps the story consistent across regulators.
3. Notice to each affected Data Principal
Rule 7(1) requires a concise, clear and plain notice, without delay, through the person's user account or a contact route they registered with you. It must cover five things: a description of the breach, the consequences relevant to them, your mitigation, the safety steps they can take, and a contact who can answer for you.
Subject: Important: a security incident affecting your [Company] account Dear [Name], We are writing to tell you about a security incident that affected some of your personal data held by [Company]. WHAT HAPPENED On [date], [plain description, e.g. "an unauthorised person accessed a copy of our customer database"]. We found out on [date] and [what we did straight away]. The data involved was your [list, e.g. name, email address, phone number and an encrypted form of your password]. [Payment card details / other data] were not involved. WHAT THIS MEANS FOR YOU [The consequences relevant to this person, e.g. "You may receive emails or calls pretending to be from us, asking for your password or a one-time code."] WHAT WE HAVE DONE [Mitigation done and in progress, e.g. "We closed the access route the same night, reset the passwords of affected accounts, and are monitoring for misuse."] WHAT YOU CAN DO - [e.g. Set a new password when you next sign in, and change it anywhere you reused it] - [e.g. We will never ask for your one-time code; do not share it with anyone] - [e.g. Watch for messages that claim to be from us and check them in the app] WHO TO CONTACT [Name or role], [email], [phone], [hours]. They can answer questions about this incident on behalf of [Company]. [Sign-off]
What each part is for. The five headings are Rule 7(1)(a) to (e) in order. Write it for the person, not for the Board: short sentences, no legal terms, and specific advice they can act on. Translate it into the languages your users read.
4. CERT-In incident report
Due within six hours of noticing the incident. The headings follow CERT-In's incident reporting form, which is optional: the same facts in an email to incident@cert-in.org.in are accepted. CERT-In's FAQs allow you to send what is known at six hours and update it later.
CYBER SECURITY INCIDENT REPORT TO CERT-In [Initial report / Update no. n] | Email: incident@cert-in.org.in | Phone: 1800-11-4949 I am: [the affected entity / reporting an incident affecting another entity] REPORTER Name and role: [ ] Organisation: [ ] Contact number / email: [ ] Address: [ ] BASIC INCIDENT DETAILS Affected entity (if different): [ ] Incident type (Annexure I): [e.g. (xi) Data Breach; (iii) Unauthorised access of IT systems/data] Critical to the organisation's mission? [Yes / No]: [brief details] AFFECTED SYSTEM (what is readily available) Domain / URL: [ ] IP address(es): [ ] Operating system: [ ] Make / model / cloud: [e.g. cloud provider, service, region] Affected application: [ ] Location (city, region, country): [ ] Network and ISP: [ ] DESCRIPTION [What was observed, what is known about the attack path, what has been done] TIMES (record time zone) Occurrence: [dd/mm/yyyy hh:mm, time zone, or "under investigation"] Detection: [dd/mm/yyyy hh:mm, time zone] LOGS [Which logs are attached or available on request, and the period they cover] This is an initial report sent within six hours of detection with the information available. Further details will follow. CERT-In point of contact for this organisation: [name, designation, email, mobile]
What each part is for. The system fields let CERT-In correlate your incident with others. The two times matter most: detection starts your six hours, occurrence shows how long the attacker had. The logs line reflects the Directions' duty to provide logs with an incident report.
Before you send anything
Check the four documents against each other: the same awareness time, the same count of people, the same categories of data. Inconsistency between what CERT-In, the Board and your customers were told is what turns a breach into an inquiry about candour. Get your deadlines from the breach notification deadline calculator, read how the two regimes differ in the CERT-In vs DPDP comparison, and see what a failure to notify can cost on the DPDP penalties page. If you are regulated, add your regulator's own report: RBI, SEBI and IRDAI each have one.
TryTrustable's breach simulator drafts the notification against your real data map, naming the stores, categories and residencies involved, so these brackets are already filled when you need them.
The things people ask us
Do we need a separate notice for the Board and for affected people?
Yes. Rule 7 sets different content for each. People get a concise, plain notice: what happened, what it means for them, what you did, what they can do, and whom to contact. The Board gets an initial description without delay and a detailed report within 72 hours, which must include a report on the notices sent to people.
How should we deliver the notice to Data Principals?
Rule 7(1) says through the person's user account or any mode of communication they registered with you, such as the email or phone number on file. A post on your blog or a press release alone does not meet that wording, because it does not reach each affected person through their own channel.
Do we have to use CERT-In's incident reporting form?
No. The form itself says it is not mandatory to fill or sign it, and that the same information may be given in an email or any other readable form. Using its headings is still sensible, because they are the fields CERT-In will ask for, and you can send what is known at six hours and update it later.
Can we send the DPDP notice before we know the full facts?
Yes, and Rule 7 expects you to. The initial Board intimation and the notice to people are due without delay, and the fuller analysis comes in the 72-hour report. Say what you know, say what you are still investigating, and avoid statements you may need to retract, such as 'no data was taken' before you are sure.
Is this template enough for the GDPR as well?
Not on its own. An Article 33 notice to an EU supervisory authority needs the categories and approximate number of people and records, the DPO or contact point, likely consequences and measures taken. Most of those facts are in the Board report above, but the authority will have its own form.
Fill the brackets before the incident, not during it.
Thirty minutes. We run the breach simulator against a sample data map and show you the draft notification it writes.