Nobody plans to have a data breach. But every company needs a plan for when it happens. And under the DPDP Act, not having a plan is not just irresponsible — it exposes you to penalties of up to 200 crore rupees for failing to notify the Board and affected individuals.
I have helped companies respond to actual breaches. The ones with a plan in place handled it in days. The ones without? Weeks of chaos, reputational damage, and significantly higher regulatory exposure.
Here is how to build a breach response plan that actually works.
What Counts as a Breach Under DPDP?
A personal data breach means any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data. This includes:
- A hacker accessing your customer database
- An employee accidentally emailing a customer list to the wrong person
- Ransomware encrypting your data (loss of access)
- A laptop with unencrypted customer data getting stolen
- A misconfigured cloud storage bucket exposing data publicly
- A vendor/processor experiencing a breach that affects your data
The scope is broad. If personal data was compromised in any way — confidentiality, integrity, or availability — it is a breach.
Your Breach Response Plan: 6 Phases
Phase 1: Detection and Initial Assessment (Hour 0-4)
Goal: Confirm the breach is real and understand its scope.
When a potential breach is reported, your first responder (usually IT or security) should:
- Verify that a breach actually occurred (not all alerts are real breaches)
- Determine what data was affected — what type, how much, whose data
- Identify the cause — external attack, insider, accident, vendor issue
- Assess whether the breach is ongoing or contained
Document everything from this point. Timestamps, actions taken, people involved. This becomes your evidence trail.
Phase 2: Containment (Hour 4-24)
Goal: Stop the breach from getting worse.
Actions depend on the type of breach:
- Compromised credentials: Force password resets, revoke access tokens
- Malware/ransomware: Isolate affected systems from the network
- Exposed database: Take the system offline or restrict access
- Email/accidental disclosure: Request the recipient to delete it, recall the email if possible
Do not destroy evidence during containment. Taking a system offline is fine. Wiping it clean is not — you need it for investigation.
Phase 3: Notification (Hour 24-72)
Goal: Notify the Data Protection Board and affected individuals.
The DPDP Act requires notification to:
- The Data Protection Board of India — in the prescribed form and manner. Include: nature of breach, categories of data affected, approximate number of individuals, measures taken, and your DPO/contact person details.
- Affected Data Principals — in clear, plain language. Tell them what happened, what data was affected, what you are doing about it, and what they should do (change passwords, monitor accounts, etc.).
The exact timeline will be specified in the rules, but prepare for a 72-hour window from discovery — that is the global standard and what most regulators expect.
Phase 4: Investigation (Day 3-14)
Goal: Understand exactly what happened and why.
A thorough investigation covers:
- Root cause analysis — what vulnerability was exploited?
- Full scope assessment — is the initial estimate accurate or was more data affected?
- Timeline reconstruction — when did the breach start, when was it detected, how long were systems exposed?
- Third-party involvement — was a vendor or processor involved?
Phase 5: Remediation (Day 14-30)
Goal: Fix the vulnerability and prevent recurrence.
Based on investigation findings:
- Patch the vulnerability that was exploited
- Strengthen access controls if credentials were compromised
- Update security configurations if misconfiguration was the cause
- Review and update vendor security requirements if a processor was involved
Phase 6: Post-Breach Review (Day 30-45)
Goal: Learn from the incident.
Conduct a post-incident review with all stakeholders:
- What worked well in the response?
- What could have been detected earlier?
- What process improvements are needed?
- Do any policies need updating?
Document the findings and update your breach response plan accordingly.
Roles and Responsibilities
Your plan should name specific people (or roles) for each function:
- Incident Commander: Owns the response. Usually CISO, CTO, or senior IT leader. Makes decisions on containment and notification.
- Technical Lead: Handles investigation and containment. Your most senior security/engineering person.
- Legal/Compliance Lead: Manages Board notification, assesses legal obligations, coordinates with external counsel.
- Communications Lead: Drafts notifications to affected individuals, handles media if needed, coordinates internal communications.
- Privacy Lead/DPO: Ensures data protection requirements are met throughout the response.
In a small company, one person might wear multiple hats. That is fine. What is not fine is having nobody assigned to any of these roles when a breach occurs.
Test Your Plan
A plan that lives in a document and has never been practised will fail under pressure. Run a tabletop exercise at least once a year. Pick a realistic scenario — "our customer database was accessed by an external attacker" — and walk through the entire response plan step by step.
You will find gaps. That is the point. Better to find them during a drill than during a real breach.