The DPDP Act introduces mandatory breach notification obligations for Data Fiduciaries. This is a significant shift for Indian companies, many of whom have historically had no structured breach response process. If a breach occurs on your watch, you now have legal obligations -and the clock starts the moment you become aware.
This guide covers what counts as a breach, who must be notified, what the notice must say, and the four-phase response plan that lets you meet the timeline reliably. For where this fits in the wider compliance programme, see Step 9 of our 90-day DPDP roadmap.
1. What Counts as a Personal Data Breach
A personal data breach is any unauthorised processing, loss, destruction, alteration, disclosure, or access to personal data held by a Data Fiduciary or Data Processor. The definition is broad -it covers far more than just hacking.
- A ransomware attack that encrypts customer data
- An employee accidentally emailing a database to an external party
- A misconfigured cloud storage bucket exposing user records
- A third-party vendor breach that compromises data you shared with them
- Lost or stolen laptop containing customer data, even if encrypted
- Insider abuse -an employee accessing data outside their authorised purpose
If your Data Processor suffers a breach involving your data, you must still notify as the Fiduciary. Your DPA with the vendor should require them to notify you immediately; the chain then runs from vendor to you to Board within the regulatory timeline.
2. Who Must You Notify
The Data Protection Board of India
The Data Fiduciary must notify the Data Protection Board as soon as the breach is identified. The Board will prescribe the format and timeline through rules; prepare to notify within 72 hours, consistent with global best practice.
Affected Data Principals
In addition to notifying the Board, the Data Fiduciary must notify each affected data principal directly. Notification must be in clear, plain language -not legalised boilerplate. The data principal is your customer or user; the message they receive will likely become public, so accuracy and tone matter.
3. What the Notification Must Contain
Notification to the Board
- Nature of the breach -what happened, how it was identified
- Categories and approximate volume of data affected
- Likely consequences of the breach
- Measures taken or proposed to address the breach
- Contact information for follow-up
Notification to Data Principals
- What happened and when
- What specific data was affected
- What steps you have taken in response
- What the data principal should do to protect themselves (e.g., password reset, monitor for fraud)
- Contact for further questions
Draft breach notification templates before you need them. A pre-approved template signed off by legal will save critical hours during an incident. Two templates: one for the Board, one for data principals. Test them in your tabletop exercises.
4. Building Your Breach Response Plan
Stop the bleeding
The moment a potential breach is identified, activate your incident response team. The priority is containment, not investigation.
- Isolate the affected systems to prevent further exposure
- Preserve logs and forensic evidence -do not wipe systems
- Classify the breach -what data, how many records, what risk
- Notify your CISO/leadership immediately
- Open an internal incident record with timestamp and ID
Determine the full scope
Now investigate. What was actually compromised?
- Which data categories were exposed?
- How many data principals are affected?
- Was the data encrypted? (Encryption with intact keys reduces the practical risk; the Board may still require notification but the harm calculus changes)
- Is there ongoing risk of exposure?
- Document everything -your response record will be required by the Board
Notify the Board and data principals
Notify the Data Protection Board using the prescribed form. Prepare and dispatch individual notifications for affected data principals. If the investigation is still ongoing, send an initial notification with the facts you know and supplement as the picture becomes clearer -better to notify with partial information than to miss the timeline.
Fix the cause, learn from it
After containment, root-cause the breach and fix the underlying vulnerability. Conduct a post-incident review and update your security controls and procedures. Update the breach response plan based on what worked and what did not. The post-incident report is part of your evidence for the Board.
5. What Happens If You Do Not Report
Failure to notify the Data Protection Board of a breach can attract penalties up to ₹250 crore. Beyond the fine, non-disclosure signals bad faith -which makes the Board's subsequent investigation far more consequential. Reported breaches that were handled well can result in lower penalties or even no penalty at all in some cases; unreported breaches that later surface tend to result in much higher penalties because the Board now has two findings instead of one.
Companies discovered to have hidden a breach face penalties for both the breach itself and the failure to report. They also lose any goodwill or mitigation credit they might have earned by acting transparently. Always notify.
6. Notification Checklist
Have you done all of these?
- Internal breach log created with timestamp and incident ID
- Affected systems isolated
- Forensic evidence preserved
- Data categories and volumes assessed
- Board notified within prescribed timeline using the prescribed form
- Affected data principals notified individually with the required content
- Remediation steps documented
- Post-incident review completed
- Root cause identified and fixed
- Response plan updated based on learnings
The companies that navigate breaches best are those that prepared before they needed to. A breach is not a matter of if -it is when. Build your response plan now, run a tabletop exercise on it, and update it regularly.
Need a breach response plan that works under pressure?
SecComply builds DPDP-aligned incident response plans, including breach notification templates, tabletop exercises, and 24/7 incident support if you need it. Tested in real incidents before you need it tested in yours.
Book an incident response review →FAQ
The DPDP Act requires notification "as soon as possible" after the breach is identified. The Data Protection Board is expected to prescribe a specific timeline through rules -commonly anticipated as 72 hours, consistent with global best practice. Until rules are notified, the safe assumption is to act within 72 hours of becoming aware of the breach.
The DPDP Act does not yet provide a "risk of harm" threshold below which notification is optional. Until rules clarify, the prudent posture is to notify the Board of any confirmed unauthorised processing of personal data -including near-misses that resulted in actual exposure even if briefly. Internal incident classification can guide whether notification to affected data principals is also warranted.
You are still liable to notify. As the Data Fiduciary, you remain responsible for the data even when it sits with a Data Processor. Your vendor must notify you under your Data Processing Agreement, and you must notify the Board and affected data principals. The notification can attribute the source of the breach to the vendor, but the obligation to notify is yours.
Up to ₹250 crore per breach under the DPDP Act, per the schedule of penalties. The Board has discretion to set the actual penalty within that ceiling based on factors including the nature and gravity of the breach, the duration of the non-compliance, and the action taken to mitigate. Failure to notify materially increases the likely penalty.
Yes. Run a tabletop exercise at least annually -walk through a simulated breach scenario with the incident response team, classify it, draft the notifications, run the timeline. Tabletops are the fastest way to find gaps in your plan before a real incident does.