DPDP Act Incident Response: Breach Management Playbook
A practical DPDP Act incident response playbook for Indian companies — breach detection, Board notification requirements, Data Principal communications, and post-incident review.
- Section 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals of a personal data breach in the prescribed form and manner.
- Failure to notify a breach can attract a penalty of up to ₹200 crore under Schedule 1 — separate from the up to ₹250 crore penalty for inadequate safeguards.
- Breach notification must be prompt — the Rules are expected to require notification within 72 hours of becoming aware of a breach.
- A written incident response plan, tested through tabletop exercises, is the foundation of DPDP incident response preparedness.
- Not every security incident is a notifiable breach — a documented assessment process determines whether notification is required.
In this guide
What Is a Personal Data Breach Under the DPDP Act?
A personal data breach under the DPDP Act 2023 is any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data. This is a broad definition that covers not just external attacks (hacking, ransomware) but also internal incidents (accidental exposure, unauthorised access by an employee), vendor incidents (a processor's breach that affects your users' data), and configuration errors (an S3 bucket left publicly accessible).
The breadth of this definition means companies should adopt an inclusive approach to breach classification: if an incident involves personal data and involves any of the above types of unauthorised or accidental activity, treat it as a potential breach until assessed. The assessment process determines whether it is notifiable, not the initial classification.
Loss of access to personal data — for example, a ransomware attack that encrypts your databases — is also a breach even if the data has not been exfiltrated. The unavailability of personal data can harm Data Principals who depend on the service (e.g., access to medical records, financial account data). Document loss-of-access incidents in your breach register even if no data was exfiltrated.
Section 8(6): The Notification Obligation
Section 8(6) requires a Data Fiduciary to notify the Data Protection Board and each affected Data Principal of a personal data breach in the form and manner prescribed. The Act does not specify a timeframe in the statute itself — this is left to the Rules. Based on the draft Rules and comparable international obligations (GDPR's 72-hour Board notification, India's own CERT-In 6-hour notification for critical infrastructure incidents), companies should plan for a short notification window.
The notification obligation runs to two parties: the Board (regulatory notification) and affected Data Principals (individual notification). These are separate obligations with potentially different content requirements. The Board notification may be more detailed (including technical analysis, scope assessment, and remediation steps); the Data Principal notification must be clear, plain-language, and focused on what happened, what data was affected, and what the Data Principal can do to protect themselves.
The penalty for failure to notify is up to ₹200 crore — a significant exposure that can compound with the up to ₹250 crore penalty for inadequate safeguards. A single major incident that involves both an inadequate security posture and a delayed or absent notification creates aggregate penalty exposure that could exceed the company's annual revenue. This financial reality should drive investment in incident preparedness.
Writing Your Incident Response Plan
An Incident Response Plan (IRP) is a documented playbook that specifies how your organisation will detect, respond to, contain, investigate, and recover from security incidents. Under the DPDP Act, an IRP that specifically addresses personal data breach response is essential — not just as a security best practice but as evidence of reasonable safeguards under Section 8(5).
Your IRP should cover: (1) Roles and responsibilities — who is on the incident response team, who is the incident commander, who contacts the Board, who drafts Data Principal notifications, who engages external forensics if needed? (2) Communication channels — how does the team coordinate during an incident (dedicated Slack channel, bridge line, incident management tool)? (3) Severity classification — how do you assess the severity of an incident and determine the applicable response level? (4) Timeline obligations — what are the internal milestones leading to Board notification within the required window?
The IRP should also address vendor-caused incidents: if a Data Processor notifies you of a breach, your IRP must specify who receives that notification, how quickly the incident response process is initiated, and how you assess whether your Data Principals were affected. Vendor breach clauses in your DPAs should require the vendor to notify you within 24-48 hours, giving you enough time to meet your own notification obligations to the Board.
Detection, Triage, and Severity Assessment
Effective breach management starts with effective detection. Implement a security monitoring stack that can detect potential breach indicators: SIEM (Security Information and Event Management) for log aggregation and correlation; anomaly detection for unusual data access patterns; DLP (Data Loss Prevention) for data exfiltration detection; endpoint detection and response (EDR) for malware detection; and web application firewall (WAF) alerting for injection attacks and credential stuffing.
When a potential incident is detected, the triage process determines: (1) Is personal data involved? (2) What is the nature of the incident (unauthorised access, accidental disclosure, ransomware, etc.)? (3) What is the scope — how many Data Principals are potentially affected? (4) Is the incident still ongoing or has it been contained? Triage should happen within 1-2 hours of detection for the incident clock to start accurately. Document the triage findings.
Severity classification guides the response intensity. A severity classification might look like: Critical (active breach, confirmed exfiltration of personal data for >10,000 Data Principals — requires immediate Board notification preparation); High (contained breach, personal data confirmed affected for any number of Data Principals — requires notification assessment within 24 hours); Medium (potential breach, investigation required to determine if personal data was affected — investigation to complete within 48 hours); Low (incident with no personal data involved — no DPDP notification required, handle as standard security incident).
Board Notification: What to Include
Board notification should include, at minimum: (1) The identity and contact details of the Data Fiduciary; (2) The name and contact details of the Data Protection Officer (for SDFs) or designated contact; (3) A description of the nature of the breach (what happened); (4) The categories and approximate number of Data Principals affected; (5) The categories and approximate volume of personal data involved; (6) The likely consequences of the breach; (7) The measures taken or proposed to address the breach and mitigate its effects.
Pre-draft your Board notification template. A template with placeholder fields for incident-specific details can be completed within 2-3 hours during an actual incident — far faster than drafting from scratch under pressure. Review and update the template annually. Ensure multiple people know where to find it and have authority to submit it.
Submit the notification even if your investigation is not yet complete. The Rules are expected to permit a staged notification approach (as GDPR does): submit an initial notification within the required timeframe with the information available, and supplement with additional details as the investigation progresses. Do not delay initial notification while waiting for forensic analysis — notify based on what you know and update the Board as you learn more.
Notifying Affected Data Principals
Data Principal notification should be: clear (written in plain, jargon-free language), specific (tell people what data was affected and what the likely consequences are), actionable (tell people what they can do to protect themselves — reset passwords, monitor bank accounts, place a fraud alert), and prompt (send as soon as you have confirmed the scope of affected Data Principals).
The notification channel should match the channel through which you normally communicate with Data Principals — email for email service users, in-app notification for mobile app users, SMS for contact lists. For large-scale breaches where individual notification is not feasible within the required timeframe, the Rules may permit a public disclosure (press release, website banner) as an alternative or supplement — design for this possibility.
Do not underestimate the reputational and relationship management dimensions of Data Principal notification. A well-drafted, empathetic notification that explains what happened, apologises for the impact, and provides concrete guidance can mitigate trust damage. A cold, legalistic notification that minimises the incident and provides no actionable guidance will generate press criticism and escalate the reputational harm. Involve your communications team in notification drafting.
Post-Incident Review and Remediation
Conduct a post-incident review within 2-4 weeks of containing a breach. The review should cover: the incident timeline (detection to containment to notification), root cause analysis (what vulnerability or control failure caused the breach), adequacy of the response (did the IRP work? What gaps were exposed?), and remediation actions (what controls need to be improved to prevent recurrence?).
Document the root cause and remediation actions in a post-incident report. This report serves two purposes: internal learning (feeding back into your security programme) and regulatory evidence (demonstrating to the Board that you investigated the breach and took corrective action). A company that suffers a breach, investigates thoroughly, and implements meaningful improvements is in a better regulatory position than one that suffers repeated similar breaches without learning.
Update your Incident Response Plan based on lessons learned. If the IRP gaps were exposed (missing contact information, unclear severity classifications, slow vendor notification), revise the plan before the next incident. Conduct a tabletop exercise 6 months after a significant incident to test the improved plan. Build incident response practice into your annual security review cycle.
Frequently Asked Questions
Does a ransomware attack that encrypts our database but has no confirmed data exfiltration require Board notification?
One of our Data Processors suffered a breach. Are we required to notify the Board?
What if we discover a historical breach — data that was exposed months ago but only discovered now?
Can we notify the Board and Data Principals simultaneously, or must we notify the Board first?
We accidentally sent an email with customer data to the wrong recipient. Is this a notifiable breach?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free