Most organizations have a breach response plan somewhere. It is probably a PDF, it is probably from 2022, and it is probably never been tested. That is not a plan. That is a liability waiting to surface at the worst possible time.
This blog is about what a real breach response looks like under India's DPDP Act and Europe's GDPR. Not the theory. The actual steps, the actual roles, and the part nobody talks about: why your response is only as good as how well you know your own data.
The Stat That Should Keep You Up
Organizations without a tested incident response plan take an average of 277 days to identify and contain a breach. That is 277 days of exposure, regulatory liability, and silent damage to customer trust.
Why Most Breach Plans Fall Apart on Day One
Walk into most organizations and you will find three things: a written policy, no assigned roles, and zero practice. The policy checks the compliance box. But when an actual incident hits, the team freezes because nobody has ever walked through it together.
The second failure is more technical. A breach response requires you to answer very specific questions very quickly. What data was exposed? Whose data was it? How many records? What categories? Organizations that cannot answer those questions in hours spend days guessing. And every hour of guessing adds to their regulatory exposure.
You cannot notify regulators about data you cannot describe. If your sensitive data is scattered and unclassified across your systems, your breach response will be built on incomplete information at exactly the moment accuracy matters most.
What DPDP and GDPR Require When a Breach Occurs
Both laws impose real deadlines. Under GDPR, organizations must notify the relevant supervisory authority within 72 hours of becoming aware of a breach. Under India's DPDP Act, draft rules indicate a similar window for notifying the Data Protection Board. These clocks start the moment your organization becomes aware, not when your legal team is ready.
The notification cannot be vague. Regulators require the nature of the breach, the categories of personal data involved, the estimated number of individuals affected, the likely consequences, and the steps being taken. That level of specificity comes from preparation, not from scrambling under pressure.
One thing Indian companies with European customers often overlook: if your organization processes data of EU residents, GDPR applies to you alongside DPDP. That means two parallel notification processes within the same 72-hour window.
Five Phase Breach Response Framework That Holds Up Under Pressure
The First Hour Is About Clarity, Not Speed
The instinct in Phase 1 is to move fast. But moving fast without direction makes things worse. The first 60 minutes should be about getting the right people into a room, issuing an initial containment directive, and starting a timestamped incident log. Every action, every decision, every call made during a breach becomes part of your regulatory record.
Phase 2 Is Where Data Visibility Becomes Everything
Containment requires knowing what was on the compromised system. Notification requires knowing whose data was involved. You cannot produce either without having already done the work of mapping and classifying your sensitive data. Organizations that have done this work answer Phase 2 questions in hours. Organizations that have not spend days guessing and filing incomplete notifications.
The questions your team must answer in Phase 2 are straightforward on paper. What categories of personal data were stored in the affected system? Approximately how many individuals are affected? Was data encrypted? Is there evidence of actual exfiltration? If your data environment is uncharted, none of those questions have quick answers.
Notification Must Be Accurate, Not Just Fast
Both DPDP and GDPR require accurate notifications. An incomplete or misleading notification triggers additional scrutiny. In Phase 3 and 4, your legal and privacy teams should be drafting regulator notifications in parallel, not waiting for one to complete before starting the other. Individual notification under GDPR is required where the breach creates high risk to individuals. Under DPDP, similar obligations are expected in the final rules.
The Roles Every Response Plan Must Name in Advance
The most common structural gap in breach plans is the absence of named individuals. Plans assign roles to job titles, not people. Then a breach happens and the CISO is travelling, the DPO is in a different time zone, and nobody has clear authority to make a decision.
Your Readiness Checklist Before a Breach Ever Happens
Use this to audit where your organization actually stands. The gaps you find today are the risks you can close before a real incident forces the issue.
PLAN AND PRACTICE
Incident response plan reviewed and updated within the last 12 months
Named individuals assigned to every role, with backups listed
Tabletop exercise run with leadership at least once this year
Regulator contact details for DPDP Board and relevant GDPR authority confirmed
DATA FOUNDATION
Sensitive data discovery completed across databases, file servers, cloud storage and email archives
Data classification current and reflecting the actual state of your systems today
Data flows mapped so you know where personal data enters, moves and leaves your environment
NOTIFICATION READINESS
Notification templates pre-drafted for regulators and for affected individuals
72-hour clock protocol understood by your incident commander and DPO
Customer contact database accessible to your response team at any hour
Run a quick internal test this week. Ask your IT and privacy teams: if we discovered a breach right now, how long would it take to tell regulators what data was exposed and how many people were affected? The honest answer tells you exactly where to start.
You can read the complete detailed version of this article on the official EzSecure blog here:👉 72 Hours to Report a Breach Why Most Organizations Still Get It Wrong
A Breach Handled Well Can Actually Build Trust
Organizations that respond to breaches transparently, quickly, and with evidence of real data governance often come out of incidents with stronger stakeholder relationships than before. That is not wishful thinking. It is the observed pattern from how GDPR enforcement has played out in Europe over six years.
The foundation of that good response is knowing your data. Not assuming you know it. Knowing it with the tooling and processes in place to answer hard questions accurately under real pressure.
Most organizations are somewhere in the middle. They have partial visibility. They have a plan that is slightly out of date. They have good intentions and incomplete infrastructure. The question is whether you close those gaps before a breach, or during one.
