A data breach response plan template is just the written answer to a question you don’t want to be working out live: something has leaked, so who decides what, and by when? In India you’re running two deadlines, not one. Six hours to CERT-In, which is already law and has been for years. Then seventy-two hours to the Data Protection Board, which starts once section 8(6) of the Digital Personal Data Protection Act, 2023 and rule 7 of the DPDP Rules, 2025 commence in May 2027. Most templates you’ll find online were written for US law and carry neither.
Nearly all the work sits before anything goes wrong, because at two in the morning nobody’s deciding anything. You’re just doing what the page already says.
Worth knowing up front: the six-hour duty applies whether you’re a twenty-person firm or one person with a laptop, and nothing in it scales with headcount.
And here’s the thing about breach plans. The problem is almost never that a document doesn’t exist. It’s that nobody can act on it: no one’s allowed to declare an incident on their own, no contact has been registered with CERT-In, and there’s no agreement on whether the laptop gets wiped or copied first. Six hours goes very fast when you’re still working out who’s in charge.
NIST says the same thing, just more formally. Its April 2025 revision of SP 800-61 builds incident response on the six functions of the Cybersecurity Framework 2.0, and puts Govern, Identify and Protect below the response line, noting that “the preparation activities of Govern, Identify, and Protect are not part of the incident response itself.” They’re what makes a response possible. Skip them and your plan looks fine on a Tuesday and falls apart on the Friday.
Sections of a data breach response plan template
A data breach response plan template needs seven sections, and honestly, only two of them are about technology.
Start with what counts as a breach, because people argue about this while the clock runs. The DPDP Act settles it at section 2(u): “any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data.” Look at the loss-of-access part. If ransomware locks you out of data you still hold, that’s a breach, even though nothing walked out the door.
Second, the people. You want one incident lead who can declare an incident without calling a meeting, a point of contact for CERT-In, and, once the DPDP obligations start, the rule 9 person who answers questions from affected individuals. The CERT-In contact isn’t somebody you appoint on the night. Direction (iii) says those details go to CERT-In in advance, on the Annexure II fields: name, designation, organisation, office address, email, mobile, office phone and fax.
Third, severity, which is where most plans go woolly. CERT-In’s own FAQ document is more concrete than the templates are, listing incidents of severe nature such as denial of service, intrusion or ransomware on public information infrastructure, “Data Breaches or Data Leaks”, large-scale or frequent intrusions, and incidents affecting the safety of human beings.
Write your trigger so it’s a fact somebody can check, not a call somebody has to make. Something like: Sev-1 is any incident where personal data has left, or may have left, our control. The incident lead can declare it alone. The six-hour CERT-In clock runs from when the incident is noticed or brought to the organisation’s notice, not from internal declaration.
Fourth, evidence, and this is the one people wreck without meaning to. Direction (iv) wants logs of all ICT systems enabled and kept securely for a rolling 180 days, held inside Indian jurisdiction, and handed to CERT-In along with the report. Direction (i) wants your clocks synced to NIC or NPL time servers, which sounds like nothing until two of your servers disagree about when the intrusion started (the report asks for the occurrence time and the detection time separately, so both need to hold up). Rule 6(e) of the DPDP Rules adds a one-year retention of logs and personal data for detection and investigation once it commences.
Fifth, the notification pack, written while everything is calm. CERT-In publishes an incident reporting form, and its fields are basically your template: incident type, whether the affected system is mission critical, domain or URL, IP address, operating system, cloud details, affected application, where the system sits, the ISP, a brief description, and both the occurrence and detection timestamps. Worth flagging, because it takes the pressure off: the form says filling and signing it isn’t mandatory, and that incidents “may also be reported by providing relevant information in the communication itself.” Treat it as a checklist for what to write, not a hoop to jump through.
Sixth, your contracts, and this is the bit small Indian service firms tend to miss. Section 43A of the Information Technology Act, 2000 says reasonable security practices are the ones “specified in an agreement between the parties”, and only falls back to law when there’s no agreement. So your MSA or data processing addendum isn’t just commercial paperwork. It’s the standard you’ll be judged against, and it usually gives you less time than any regulator does.
Seventh, the review afterwards. NIST’s line is that lessons “should often be shared as soon as they are identified, not delayed until after recovery concludes”, which is pretty much the opposite of how these reports normally get written.
Does a twelve-person firm really need all seven? Yes, though four of them fit on one page. The two that take actual thinking are the severity trigger and the contract review.
Now picture the sections missing. A bookkeeper working with a US accounting firm has a laptop lifted from a cab in Pune, and there’s three months of payroll files on it. What usually happens? A call to the client, then a whole day of silence while everyone waits to hear whether it’s “really” a breach.
That day is the problem. If the theft gives rise to a reportable cyber incident, such as a suspected data breach or data leak, the six-hour CERT-In clock runs from when the incident is noticed or brought to the organisation’s notice, rather than from when the organisation completes its investigation.
With the sections written, the same night goes differently. The lead checks two things, whether the disk was encrypted and whether the account had live sessions, and declares Sev-1 on the second one. The report goes to CERT-In with whatever is known, and the client call happens after that, not instead of it.
A privacy impact assessment done months earlier would already say what that laptop was allowed to hold, which turns the encryption question into a five-minute answer. And if nobody in the business can run this at all, that’s a hiring gap rather than a paperwork one. It’s one reason remote cybersecurity roles keep opening up at firms with under fifty people.
Breach reporting deadlines in India
Two deadlines apply to a breach in India, and only one of them is live right now.
The live one is CERT-In’s. Direction (ii) of the directions of 28 April 2022 tells any service provider, intermediary, data centre, body corporate or government organisation to “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.” Annexure I runs to twenty incident types, and two of them are literally “Data Breach” and “Data Leak”. Unauthorised access, phishing, ransomware, attacks on cloud systems, someone getting into your social accounts, all on the same list.
The directions kicked in sixty days after they were issued, so this has been binding since mid-2022. And the scope is deliberately wide. Asked whether they apply only to Indian companies, CERT-In said they “are applicable to any entity whatsoever, in the matter of cyber incidents and cyber security incidents”, and gave the same answer when asked about data sitting in a third party’s systems. So an Indian firm handling a foreign client’s records is inside this, and so is the mess that happens in somebody else’s cloud.
What happens if you ignore it? Section 70B(7) of the IT Act makes failing to comply with a direction punishable “with imprisonment for a term which may extend to one year or with fine which may extend to one lakh rupees or with both”. CERT-In has said in its FAQ that the power “will be exercised reasonably and on occasions when the non-compliance is deliberate”. Reassuring about how it gets used, and it changes nothing about whether the duty applies to you.
The clock starts when you find out, not when it happened. Asked about an incident that sat undetected for months, CERT-In answered that it “needs to be reported to CERT-In within 6 hours of noticing the incident or being brought to notice about such incident”. A breach that started in March and surfaced on a Tuesday afternoon is a Tuesday afternoon report. And that second half matters just as much: if a client or a security researcher tells you about your own exposure, that starts the clock too.
The objection everyone has at this point is that six hours isn’t enough time to know anything useful. CERT-In has answered that head on: entities “may provide information to the extent available at the time of reporting”, with more to follow later within reasonable time. Frankly, that’s the most useful line in the whole document, because it kills the excuse that produces late reports.
Picture a Friday. Files start encrypting across two servers at 21:40, the founder’s on a flight, and your six hours run out at 03:40 on Saturday. Firms without a plan burn that window trying to reach somebody senior, then report on Monday with a complete forensic picture and a three-day delay.
Firms with a plan send something before midnight and fill in the rest later. Roughly this: At 21:40 IST on 12 September we detected file encryption across two servers holding client records. Systems are isolated, forensics has started, scope is not yet confirmed. Point of contact and logs attached, supplementary report to follow.
The second deadline is the DPDP one, and it isn’t switched on yet. Section 8(6) says a Data Fiduciary has to give the Board and each affected Data Principal intimation of a breach in the prescribed form. Rule 7(1) spells out the individual notice: without delay, concise, clear and plain, covering the breach and its nature, extent and timing, what it means for that person, what you’ve done to reduce the risk, what she should do herself, and a business contact who can answer her questions. Rule 7(2) does the regulator’s version in two parts, a description without delay, then within seventy-two hours the detailed account, the facts and reasons, mitigation measures, findings on who caused it, remedial steps and a report on the intimations you sent.
Commencement is where a lot of published guidance gets it wrong, so be careful what you copy. Plenty of Indian articles write about the seventy-two hour rule as though it binds today, and it doesn’t yet. Notification G.S.R. 843(E) of 13 November 2025 brings sections 7 to 10 into force eighteen months from publication, and rule 1(4) of the Rules puts rules 3 and 5 to 16 on the same schedule. The Gazette went out on 14 November 2025, so both land in May 2027.
But the Board itself was set up straight away, by G.S.R. 844(E) on the same day. The DPDP Act compliance checklist walks through that whole commencement picture if you want it in detail. For a response plan, the takeaway is simple: you get one drafting cycle, not two.
And the penalties are why that cycle is worth spending. The Schedule to the Act allows up to two hundred and fifty crore rupees for failing to take reasonable security safeguards, and up to two hundred crore rupees for failing to give the Board or the affected individual notice of a breach. Two separate entries. A badly handled incident can land on both.
to CERT-In
delay
to each affected
individual
to the Board
Running the data breach response plan template in a live incident
Running a data breach response plan template for real comes down to four decisions in order: contain, preserve, notify, then tell the client.
Containment and preservation pull against each other, and preservation usually loses. When a machine is compromised the instinct is to wipe it and rebuild, because that visibly ends the problem. It also wipes the logs you’re supposed to hand CERT-In with the report, plus the evidence for the only question anyone asks later, which is how much data actually moved. Image the disk, grab the access logs, then contain (twenty minutes, give or take) and your report becomes a description instead of a shrug.
Take the exposure nobody spots for months. A shared folder link got set to “anyone with the link” back in March, a contractor who left in April still has a live account, and somebody notices both in September. Is that even a breach? Under section 2(u) it certainly can be, because unauthorised processing covers access by someone who’s no longer entitled to it.
Don’t turn it into a debate about intent. Pull the access logs, list every download by that account and every external view of the link, and decide reportability against those events. But if your logging can’t answer that question, then the finding of this incident is that the logging was the incident.
Now the one that catches service businesses. Your cloud vendor gets breached and the exposed records belong to your client. Section 8(1) keeps the responsibility with the Data Fiduciary “irrespective of any agreement to the contrary”, including processing done on its behalf by a Data Processor, and rule 6(f) says the contract with that processor has to provide for reasonable security safeguards.
So the vendor’s incident turns into your notification, and the fix is contractual rather than technical. Put a notice window into the agreement that’s shorter than your own (twenty-four hours is the usual figure), name a human contact rather than a support queue, and keep a right to their logs. Firms that have been through a SOC 2 assessment usually have all three already, which is one of the quieter reasons buyers ask for the report.
Does any of this reach a freelancer with two clients and a laptop? It does, and the wording leaves no wiggle room. Section 43A defines “body corporate” as “any company and includes a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities”, and CERT-In quotes that same definition in its FAQ when answering the scope question.
So a one-person practice holding a foreign client’s customer data sits inside both regimes. Your plan is one page: the client’s contractual notice window, the CERT-In address and the contact details you already sent, where the logs live, and who you call first. If you’re building a compliance career rather than just protecting your own shop, you’ll recognise the same discipline from the ISO 27001 lead auditor path, where the evidence trail is the actual deliverable.
Then the hardest writing job of the lot, which is telling people something true while you still don’t know everything. Rule 7(1) asks for intimation “to the best of its knowledge” and without delay, so a partial notice is built into the rule.
Say what happened, when, what it means for them, and what you’re doing. Something like: On 12 September we found that files containing your name, email address and invoice history were accessible to an unauthorised account between 3 and 12 September. We have removed the access and are checking whether the files were downloaded. Change your account password, and treat any payment request quoting these invoices as suspect until you have called us on the number below.
No apology paragraph ahead of the facts, no guessing at causes, nothing a later forensic finding will contradict. The client version is shorter and firmer, because what a client wants is the timeline, the scope and the containment step, in that order.
The review closes the loop, and once the DPDP Rules commence it has a fixed target to aim at. Rule 6(1) lists the minimum safeguards a Data Fiduciary has to maintain: encryption, obfuscation, masking or virtual tokens for the data itself, access control over the computer resources, visibility over access through logs and monitoring, and backups good enough to keep processing if data gets destroyed or locked. Every incident either confirms one of those or exposes it. And that, rather than a long narrative nobody reads, is the review agenda we’d recommend.
Test the plan before an incident does it for you. NIST points to SP 800-84 for tabletop exercises, and a tabletop costs you almost nothing: an hour, the incident lead, whoever holds the logs, one scenario read out from the paragraphs above. What breaks in the room is nearly always authority (not tooling, not documentation). Someone says they’d call the founder first, the founder is unreachable, and there go your six hours.
Sort out the authority line and most of the rest holds up. A plan that names one person, one clock and one first message has already solved the thing that turns a contained incident into a reportable failure.
Frequently asked questions
Does a lost or stolen laptop count as a personal data breach?
It can. Section 2(u) covers accidental loss of access as well as unauthorised processing, so a stolen device holding personal data is a breach unless you can show the data stayed protected. Encryption is the best answer you’ve got, though live sessions and synced folders survive the theft.
Who reports to CERT-In if there is no security team?
Whoever you named. Every covered entity has to designate a point of contact and send those details in advance on the Annexure II fields, and CERT-In confirms that providers serving users in India must do this with or without a presence here. Reports go to [email protected].
Can the seventy-two hour report to the Data Protection Board be extended?
Rule 7(2)(b) allows a longer period “as the Board may allow on a request made in writing in this behalf”, so yes, if you ask before the deadline rather than after it. The first-stage intimation is due without delay and gets no such allowance. Neither binds until May 2027.
What if the affected people are in the UK or the EU?
A separate clock applies, alongside the Indian one. The Information Commissioner’s Office says a notifiable breach has to be reported to it “within 72 hours of becoming aware of the breach, where feasible”. Check the client contract too, because processor windows are often shorter than that.
References
- The Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology. Section 2(u), section 8(1), section 8(5), section 8(6) and the Schedule.
- Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025. Rule 1(4), rule 6, rule 7 and rule 9.
- Commencement notification G.S.R. 843(E), Ministry of Electronics and Information Technology, 13 November 2025.
- Notification G.S.R. 844(E) establishing the Data Protection Board of India, 13 November 2025.
- Cyber Security Directions under section 70B(6) of the IT Act, 2000, CERT-In, 28 April 2022. Directions (i) to (iv), Annexure I and Annexure II.
- FAQs on Cyber Security Directions of 28.04.2022, CERT-In, May 2022. Questions 23 to 31.
- CERT-In Incident Reporting Form, CERT-In.
- The Information Technology Act, 2000, India Code. Section 43A and section 70B(7).
- NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, National Institute of Standards and Technology, April 2025.
- Personal data breaches: a guide, Information Commissioner’s Office, United Kingdom.
This article is for informational and educational purposes only and does not constitute legal or professional advice. Breach obligations turn on the facts of the incident and on the contracts you have signed, so consult a qualified professional before acting.
Allow notifications
