Personal data breach runbook: who does what, hour by hour, under Rule 7

This is the “what to do” page. When something goes wrong, open it and follow it. It tells a 5–200 person company who decides, who writes and who sends; what to do in each hour after you become aware of a personal data breach; and which messages to send, with a template for each. Rule 7 of the DPDP Rules, 2025 applies from 13 May 2027 (Rule 1(4)).

Part of the DPDPA checklist for small companies. For what the law says and why, read personal data breach intimation under the DPDP Act. For detection and dispatch in code, see DPDPA breach notification automation and the open-source breach-notification module, which also has the templates below as files, an incident log model and a tested deadline calculator.

These are templates, not legal advice. The roles, hour targets and templates on this page are our suggestions for meeting the law in practice. The law sets the duties and the content; it does not set your process. Have a lawyer check your final versions.

Who decides, who writes, who sends?

Write the names in before an incident. In a 10-person company one person may hold two roles. Never let one person hold all of them: someone should check the messages before they go.

Role	What they do	10-person company	150-person company
Incident lead (decides)	Declares a personal data breach, records the aware time, owns both Rule 7 clocks, decides whether to ask the Board for more time	Founder or CTO	Named security or engineering lead, with a deputy
Fact writer (writes)	Writes the facts: what happened, which data, how many people, which systems, when. Fills in the Board templates and the incident log	Lead engineer	On-call engineer, then the investigation owner
Message writer (writes)	Turns the facts into the plain-language message to each affected person	Founder	Support or communications lead
Approver (signs off)	Approves every message before it leaves	A director	A director or the COO
Sender (sends)	Sends to the Board and to each affected person; keeps the delivery record	Founder	Support operations, with the incident lead
CERT-In Point of Contact	Sends any CERT-In incident report and receives CERT-In’s communications	CTO	Security lead
Contact person	Answers affected people’s questions. This is the person you already publish under Rule 9; Rule 7(1)(e) puts their details in every message	Whoever you publish	Whoever you publish

The CERT-In directions require you to designate a Point of Contact and send CERT-In its details (direction (iii) and Annexure II). That is a duty in its own right, not only an incident task.

The decisions to make first

Work through these in order. Write each answer, with the time and who decided, into the incident log (template (e)).

1. Is the data in scope? The DPDP Act covers digital personal data, including paper records that were digitised later (S.3(a)). Personal data is any data about an identifiable individual (S.2(t)). Customers, employees, job applicants and leads all count. If the records were only ever on paper, the Act does not reach them.

2. Is it a personal data breach (S.2(u))? Ask each question. A “yes” to any one means it is in scope:

• Was personal data processed without authorisation?
• Was it accidentally disclosed, acquired, shared or used?
• Was it altered or destroyed, or did you lose access to it?
• Did that compromise its confidentiality, integrity or availability?

There is no harm test in Rule 7. It applies to “any personal data breach”. Likely harm goes into the message; it does not decide whether you send one. A misdirected email, a lost unencrypted laptop and ransomware that only locks files all qualify.

3. Whose data is it? If your company decides why and how the data is processed, you are the Data Fiduciary (S.2(i)) and the intimations are yours (S.8(6)). If you only process it for a client, you are that client’s Data Processor (S.2(k)), and S.8(6) puts the intimation duty on the client. Tell the client at once, under your contract. For a child, the Data Principal includes the parents or lawful guardian (S.2(j)(i)), so the message goes to them.

4. Is a processor involved? If the breach happened at your cloud host, payroll provider or email platform, it is still yours to intimate. You stay responsible for processing done on your behalf (S.8(1)), and your safeguards duty covers it (S.8(5)). The Act sets no deadline for the vendor to tell you. That deadline belongs in the contract (S.8(2); Rule 6(1)(f)). In our view, the moment the vendor tells you is usually your aware time.

5. Is it also a cyber incident CERT-In wants reported? CERT-In’s Annexure I lists 20 types of cyber security incident, including “Unauthorised access of IT systems/data”, ransomware and other malicious code, “Data Breach” and “Data Leak”. CERT-In’s FAQs say the 6-hour report is for listed incidents that meet its criteria, and any data breach or data leak meets them; other listed types count when they are severe, large-scale or affect people’s safety (FAQ Q30). If yours qualifies, the 6-hour CERT-In report runs in parallel. See the CERT-In section below.

6. Will the detailed report be ready in time? Decide by hour 48. If not, send the written request (template (d)) before the 72 hours end.

What do you do, hour by hour, after becoming aware of a breach?

Hours are counted from T, the time your written “aware” trigger was met. The Rules don’t define becoming aware, so set a trigger you can apply at 3 a.m., for example “the incident lead confirms personal data is involved”. All hour targets below are ours. The only hour count in the law is the 72 hours for the detailed Board report (Rule 7(2)(b)). CERT-In’s 6 hours is a different law, with a different start point.

1. Hour 0: record the times. The incident lead writes T into the incident log, with who confirmed it and on what evidence. If you are dealing with a cyber incident, also record when it was first noticed (call it N). N can be earlier than T, and CERT-In’s clock runs from N.
2. Hour 0–1: decide and contain. Work through decisions 1 to 5. In parallel, stop the damage: revoke credentials, isolate hosts, pull back misdirected messages where you can, pause the affected integration. Snapshot systems and secure logs before you wipe or rebuild anything. Rule 6(1)(c) asks for logs that enable detection, investigation and remediation. This is when you use them.
3. Within 6 hours of N: report to CERT-In, if it applies. If the incident qualifies (decision 5), the CERT-In Point of Contact reports it within 6 hours of noticing it, using CERT-In’s published format. If you don’t have everything the form asks for, send what you know: CERT-In’s FAQs say entities “may provide information to the extent available at the time of reporting” and add the rest later (FAQ Q30). This does not replace anything in Rule 7.
4. Hour 1–4: first scope. The fact writer records, “to the best of its knowledge” (Rule 7(1)), the nature, extent, timing, location and likely impact. Mark anything unknown as “not yet known”. Don’t wait for certainty.
5. Same working day: first intimation to the Board. Fill in template (b), get it approved, and send it. Record the time and keep a copy. If you have the five items within an hour, send within the hour. “Without delay” may mean sooner than our target (Rule 7(2)(a)).
6. Same working day: intimate each affected person. The message writer fills in template (a). The approver signs off. The sender sends it through each person’s user account or a contact method they registered with you (Rule 7(1)). If you can identify only some people yet, start with them and add others as you find them. Log every message.
7. Hour 4–60: investigate. Find the events, circumstances and reasons behind the breach, any findings about who caused it, and what will stop it happening again. These are the headings of the detailed Board report (template (c)).
8. By hour 48: decide on more time. If the detailed Board report won’t be ready by hour 72, the incident lead sends the written request (template (d)). Only the Board can allow a longer period (Rule 7(2)(b)).
9. By hour 72: send the detailed Board report. Fill in template (c), including the report on the intimations sent to people (Rule 7(2)(b)(vi)). Send it within 72 hours of T, or within the longer period the Board allowed.
10. After: keep the record and review. Keep the incident log, every message sent, the Board correspondence and the evidence. Keep the logs and personal data needed for the investigation for one year (Rule 6(1)(e)). Within two weeks, review what failed and update this breach runbook.

Stay available after hour 72. On receiving an intimation, the Board may direct urgent remedial or mitigation measures and inquire into the breach (S.27(1)(a)). The Board functions as a digital office (Rule 20), but the Rules prescribe no channel for Rule 7 intimations. Check what the Board publishes and write its channel into your runbook in advance.

Why the log matters. When the Board sets a penalty, one factor is whether you acted to mitigate the effects, and how quickly and how well (S.33(2)(e)). A timestamped log is how you show that.

What about CERT-In’s 6-hour report?

CERT-In’s reporting duty is a different law from the DPDP Act. It comes from directions CERT-In issued on 28 April 2022 (No. 20(3)/2022-CERT-In) under section 70B(6) of the Information Technology Act, 2000. The key direction reads:

Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents.

— CERT-In Directions under section 70B(6) of the IT Act, 2000, 28 April 2022, direction (ii)

Both duties can apply to one incident. The DPDP Act says it is “in addition to and not in derogation of any other law” (S.38(1)). So a CERT-In report does not count as a Rule 7 intimation, and a Rule 7 intimation does not count as a CERT-In report.

Rule 7 and CERT-In side by side:

	DPDP Rules, Rule 7	CERT-In Directions, 28 April 2022
Law	DPDP Act, 2023, S.8(6), and DPDP Rules, 2025, Rule 7	Information Technology Act, 2000, S.70B(6)
In effect	From 13 May 2027 (Rule 1(4))	60 days after issue, as the directions state; 25 September 2022 for MSMEs (CERT-In notice of 27 June 2022)
Who reports	The Data Fiduciary	”Any service provider, intermediary, data centre, body corporate and Government organisation”
What triggers it	Any personal data breach (S.2(u))	The cyber incident types in Annexure I (20 types); for the 6-hour report, those meeting CERT-In’s criteria, which include any data breach or data leak (FAQ Q30)
Clock starts	”On becoming aware” (Rule 7(1), 7(2))	“noticing such incidents or being brought to notice about such incidents”
Deadline	Without delay for people and the Board; the detailed Board report within 72 hours, or a longer period the Board allows (Rule 7(2)(b))	Within 6 hours
Goes to	Each affected Data Principal, and the Board	CERT-In
Channel	People: user account or a registered contact method (Rule 7(1)). Board: none prescribed	Email incident@cert-in.org.in, phone 1800-11-4949, fax 1800-11-6969; formats on www.cert-in.org.in
Logs to keep	One year (Rule 6(1)(e))	Rolling 180 days, within Indian jurisdiction, provided with any incident report (direction (iv))
Clock sync	Not prescribed	Connect ICT systems to NIC or NPL time servers, or servers traceable to them (direction (i))

The directions also say failure to furnish information or comply “may invite punitive action under sub-section (7) of the section 70B” of the IT Act. We don’t state the penalty amount here, because the IT Act’s text is not part of this page’s sources. Whether your company is a “body corporate” or another listed entity is a question under the IT Act. Check it with counsel once, and write the answer into the runbook.

One incident, by the numbers. An incident that is both a personal data breach and an Annexure I cyber incident can mean four separate outbound reports under three different deadlines: the CERT-In report within 6 hours of noticing it; the first intimations to each affected person and to the Board, without delay; and the detailed Board report within 72 hours of becoming aware. Of the five templates below, three carry the 16 content items Rule 7 requires; the other two use formats we chose, because the Rules prescribe none. Method: deadlines and recipients counted from Rule 7(1), 7(2)(a) and 7(2)(b) of G.S.R. 846(E) as corrected by G.S.R. 892(E), and from direction (ii) of CERT-In’s Directions No. 20(3)/2022-CERT-In of 28 April 2022. Content items: 5 in Rule 7(1)(a)–(e), 5 named in Rule 7(2)(a), 6 in Rule 7(2)(b)(i)–(vi). Annexure I types counted from items (i) to (xx). The intimations to people are counted as one report type, however many people receive them.

Templates

Template, not legal advice. Each template below is a starting point. Field references such as [7(1)(a)] tell you which part of Rule 7 the field answers. Delete them before sending. Replace everything in square brackets. Editable copies are in the DPDPA Engineering Kit’s templates folder, with the incident log as a JSON example.

Template (a): intimation to each affected Data Principal

Rule 7(1) requires it “in a concise, clear and plain manner and without delay”, through the person’s user account or a contact method they registered with you. Rule 2(1)(c) defines user account widely: it includes profiles, handles, email addresses and mobile numbers. Write for someone reading on a phone.

Subject: A personal data breach involving your [company/service] information

Dear [name],

What happened. On [date], we found that [plain description, e.g. “someone without permission accessed one of our customer databases”]. It involved your [list the data: name, email, phone number, order history]. It happened between [start date] and [end date, or “we are still confirming this”]. [7(1)(a)]

What this may mean for you. [The likely consequences for this person, e.g. “you may receive emails or calls pretending to be from us”]. [7(1)(b)]

What we have done. [Measures taken and being taken, e.g. “we closed the access, reset all staff passwords and brought in outside investigators”]. [7(1)(c)]

What you can do. [Specific steps, e.g. “change your password for our service and anywhere you used the same one; don’t share one-time passwords with anyone who calls”]. [7(1)(d)]

Who to contact. [Name or role], [business email], [business phone]. [7(1)(e)]

[Company name]

Template (b): first intimation to the Board, without delay

Rule 7(2)(a) asks for “a description of the breach, including its nature, extent, timing and location of occurrence and the likely impact”.

Field	Entry
Data Fiduciary: name, address, contact for this intimation
Aware time (T), with timezone
Nature of the breach [7(2)(a)]
Extent: data involved, number of people affected, known or estimated [7(2)(a)]
Timing of occurrence: when it started, when it was stopped if known [7(2)(a)]
Location of occurrence: systems, sites, processor, country [7(2)(a)]
Likely impact [7(2)(a)]
Not yet known, and when we expect to know it

Template (c): detailed Board report, within 72 hours

Due within 72 hours of becoming aware, or within a longer period the Board allows on a written request (Rule 7(2)(b)).

Heading	What to write
(i) Updated and detailed information on the first description	Everything from template (b), corrected and completed
(ii) Broad facts on the events, circumstances and reasons leading to the breach	The sequence of events and the root cause, as far as known
(iii) Measures implemented or proposed to mitigate risk	What was done, when, and what is planned
(iv) Findings about the person who caused the breach	What you know; “none yet” is an answer
(v) Remedial measures to prevent recurrence	Control changes, with owners and dates
(vi) Report on the intimations given to affected Data Principals	From the incident log: how many people, which channels, when, how many messages failed and were resent

Template (d): written request for a longer period

Rule 7(2)(b) allows a longer period only “as the Board may allow on a request made in writing in this behalf”. The Rules prescribe no format. Keep it to facts.

To: Data Protection Board of India

Subject: Request for a longer period for the detailed report: [our reference]

We gave the first intimation of this personal data breach on [date and time], reference [ref]. We became aware of the breach on [date and time].

Under Rule 7(2)(b) of the DPDP Rules, 2025, we request that the Board allow us until [date and time] to submit the detailed report.

Why we need it: [specific reason, e.g. “the forensic image of the affected server will be analysed by [date]”].

Ready now: [list the Rule 7(2)(b) items you can already give]. Still outstanding: [list the rest].

[Name], [role], for [company]. [Business email, phone].

Send it before the 72 hours end. Until the Board allows a longer period, assume the original deadline stands.

Template (e): internal incident log entry

Open one log per incident, with a header, then add one entry for every action, decision or message. Times in IST, to the minute. Keep a copy outside the affected systems.

Header field	Entry
Incident ID
N: first noticed (CERT-In clock)
T: aware of personal data breach (Rule 7 clocks)
Incident lead, and deputy
Decisions 1–6 (answer, time, who)

Entry field	Example
Time (IST)	2027-06-03 14:20
Who	[Name, role]
What happened or was done	Revoked API key for the billing integration
Decision, if any, and why	Treat as a personal data breach: customer emails exposed (S.2(u))
Evidence	Log export saved to [location], hash [value]
Message sent, if any	To: [Board / CERT-In / n people]; channel; reference
Next action and owner	[Action], [name], by [time]

Common mistakes

• One clock instead of three. CERT-In’s 6 hours, Rule 7’s “without delay” and the detailed Board report’s 72 hours are separate. Track each.
• Assuming the CERT-In report covers the Board. It goes to a different body under a different law. The Board and each affected person still need their intimations (S.8(6)).
• Waiting for the investigation. You intimate “to the best of its knowledge” (Rule 7(1)). Send what you know, and add detail in the detailed Board report.
• Leaving roles blank. At hour 0 nobody should be asking who signs.
• Letting the vendor set the pace. Your processor’s breach is your intimation (S.8(1)). Put its notice deadline in the contract.

Frequently asked questions

Who should lead the response in a 10-person company?

Usually the founder or CTO, with one other person checking every message before it is sent. The law doesn’t name a role. This breach runbook only asks that the names are written down before an incident.

Does the CERT-In 6-hour rule mean the DPDPA deadline is 6 hours?

No. The 6 hours comes from CERT-In’s directions under the IT Act, 2000. Rule 7 asks for a first intimation to people and the Board without delay, and a detailed Board report within 72 hours (Rule 7(2)(b)). Both can apply to the same incident.

If we report to CERT-In, do we still tell the Board and the people affected?

Yes. The DPDP Act adds to other laws, not replaces them (S.38(1)). A personal data breach needs its own Rule 7 intimations from 13 May 2027.

We run software for clients. Who sends the intimations if their data is breached on our systems?

The client, as Data Fiduciary (S.8(6)). Tell the client at once, as your contract requires, and give them what they need for the templates. A CERT-In report may still be yours if the incident is on the Annexure I list.

Do we have to use these templates?

No. Rule 7 sets the content, not the wording. Any format works if it carries the five items for people (Rule 7(1)(a)–(e)), the five for the Board’s first intimation (Rule 7(2)(a)) and the six for the detailed Board report (Rule 7(2)(b)). These are templates, not legal advice.

What if we can’t name the attacker by hour 72?

Say so. Rule 7(2)(b)(iv) asks for “any findings regarding the person who caused the breach”. If you have none yet, the report says that. If the rest of the report can’t be ready either, ask for more time in writing first.

---

Checked against the DPDP Act, 2023, the DPDP Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)) and CERT-In’s Directions No. 20(3)/2022-CERT-In of 28 April 2022 on 25 October 2026.

Want to see which other obligations are still open? The free DPDP Gap Identifier walks through all eleven. To rehearse this breach runbook with an engineer, get in touch.