3:07 am. Your security lead’s phone buzzes. A database dump with your customers’ names, phone numbers and loan details has turned up on a forum. Somebody says it’s from last week. Somebody else swears it’s three months old. And nobody’s quite sure whose job it is to wake up the legal head.
That’s the moment a breach plan is for. Not writing it, using it - half asleep, clock running, three people talking at once. Do it now while people are up and coffee is still available.
Dates before everything. Real work starts on 13 May 2027. Failure to inform the Board and the impacted users could be expensive, up to ₹200 crore. A security failure carries its own ceiling of ₹250 crore. On top of that, the Board would evaluate whether you were proactive in trying to fix your mistake, and whether the speed of your response was adequate.
First, what actually counts as a breach
It’s broader than a hack. Under the Act, a breach is any unauthorised processing of personal data, or any accidental disclosure, sharing, use, alteration, destruction or loss of access to it, that compromises its confidentiality, integrity or availability. So a laptop left in a taxi counts. So does an email sent to the wrong mailing list, or ransomware that locks you out of your own records. The text sets no minimum size or harm, so I wouldn’t bank on a “too small to report” exemption.
Three clocks, all running at once
Rule 7 holds the timing, and the starting gun is the moment you become aware of the breach. After that:
| Who | What | When |
|---|---|---|
| Each affected person | Plain-language notice via her account or registered contact | Without delay |
| The Data Protection Board | First description: nature, extent, timing, location, likely impact | Without delay |
| The Board | Updated, detailed report | Within 72 hours, or longer if it agrees to a written request |
| CERT-In | Report of the cyber incident | Within six hours of noticing |
| Your sector regulator | Whatever they require | Check yours |
Illustrative summary. Check it against Rule 7, the CERT-In Directions and your own sector’s rules.
People assume the 72 hours covers the lot. It doesn’t. That’s just the deadline for the detailed Board report. Customers and the Board’s first notice are “without delay,” which in a real breach means hours, not days.
Figure 1. The first 72 hours, and after: who gets told what, and when.
A DPDP data breach response plan, in order
Back to our 3:07 am forum dump. Roughly, the night should go like this.
First, the call. Somebody’s the incident lead, and that somebody has a named deputy. Legal or the DPO’s office is on it, so are IT and security, whoever does communications, and whoever manages the vendors. Each of them has a phone number that works at 3 am. If your plan says “the legal team” and nobody can name the person, it isn’t a plan, it’s a hope.
Then you contain it - stop the leak - but without wiping the logs on the way, because you’ll need them for the Board report, and Rule 6 wants logs and personal data kept for a year anyway. Write down the exact time somebody first became aware. That timestamp starts everything, and you’ll be asked for it.
Triage comes next, and fast. What data, whose, how many people, which system, is it still happening, and did it come from you or a vendor? Rough answers in the first hour beat perfect answers on day three.
Now somebody has to own CERT-In. Six hours is the tightest clock, and the report that belongs to nobody tends to be the one that doesn’t get filed. Then the Board’s first notice, without delay: what happened, how far it went, when and where, the likely impact. The detailed report follows within 72 hours and has to cover the broad facts and reasons behind the breach, what’s been done to mitigate risk, any findings about the person who caused it, steps to stop it happening again, and a report on the notices sent to affected people. Can’t finish in 72 hours? Ask the Board for longer, in writing.
Then the people affected. Rule 7 says the notice needs to say what occurred and when, what may happen, what you are doing to stop it, what she can do, and provide someone for her to contact. Write the notice and leave spaces. Do not write a notice that mostly says “we take privacy seriously.”
Correct it properly. Find the reason and fix it, update passwords, look for the same vulnerability in other parts of the system, and keep track of everything you did. Put it in the “remedial measures” part of your report to the Board to show you responded.
And a few weeks later, the review nobody enjoys: what we missed, what slowed us down, what changes. Blameless, or people will stop telling you things. Update the plan and keep the whole file.
When the breach isn’t yours (but is)
A vendor tells you on Thursday about something that happened on Monday. Whose breach is it? Yours, as far as the Act’s concerned. You’re responsible for processing done on your behalf irrespective of any agreement to the contrary, and your clock starts when you find out. So put a notice window into every vendor contract, measured in hours. Name the contact on both sides. And ask each vendor how they’d reach you at 3 am. If they can’t answer it means that is your answer.
Talking to customers and the press
One person speaks for the company. Just one. Get a short holding statement out early, even if all it says is that you’re looking into it and will update by a set time. Your support team needs a script too, since they’ll take the angry calls first. And ask everyone else to stay off LinkedIn for a bit. If the call centre says one thing and the CEO’s post says another, that’s your headline.
Where plans usually fall over
Mostly at the very start. People argue about whether it’s “really” a breach while the clock runs. Nobody wrote down when they became aware. Somebody’s waiting for certainty before telling anyone. The CERT-In report belongs to no one. The customer notice gets written from scratch at 4 am. None of that needs clever technology. It needs names, templates and a rehearsal.
Practise it
A DPDP data breach response plan nobody’s rehearsed is just a document. Run a tabletop twice a year. Pick a scenario (vendor leak, lost laptop, ransomware), get the real people in a room, and time how long it takes to decide who to tell. You’ll find the dead phone numbers and the missing templates fast, and far more cheaply than on the night.
Seven months is plenty to write a plan and test it. It isn’t if the first real incident is the first time anyone reads it.
If you’d like to see how DPDP data breach response works in a platform, with timers, templates and a log of every step, look at Consiva’s breach management page or talk to the team.
Frequently Asked Questions
Looks like it, yes. There’s no “small breach” cut-off anywhere in the Act or the Rules. A laptop forgotten in an auto, one email sent to the wrong group, either can qualify. Our honest advice? Assume it’s reportable and move. If your lawyer later says you didn’t need to, you’ve lost an afternoon. Arguing about it for two days costs a lot more.
Affected people and the Board’s first notice are due without delay, which in practice means hours. The detailed report to the Board is due within 72 hours, or later if the Board agrees to a written request. CERT-In runs its own six-hour window for cyber incidents, and your sector regulator may have a deadline of its own too.
Start with what went wrong and roughly when. Then the likely fallout for them, and what you’ve already done about it. The bit people actually read comes next: what they should do now. Change a password? Ignore calls asking for an OTP? Say so. Put a real name and email at the bottom. If the notice opens with “we value your privacy,” most readers stop right there.
Still you, unfortunately. Under the Act, the company that collected the data answers for whatever its processors do with it, and no contract can shift that. Your clock also starts the moment you hear about it, not when they found it. So get each vendor to agree to tell you within hours, and check someone there actually picks up the phone at 3 am.
An incident lead with a named deputy, someone from legal or the DPO’s office, IT and security, whoever handles communications, and whoever manages your vendors. Write down real names and phone numbers that work at night, not just job titles. If the plan only says “the legal team” and nobody can name the person, you’ll lose precious time.
We’d say every six months. Keep it realistic: your payroll vendor leaks a file, or ransomware hits on a Saturday night. Put the real people in a room, start a timer and see how long it takes just to agree who gets told. Someone’s number will be out of date, or the customer notice template won’t exist yet. Better to learn that on a Tuesday afternoon.