Personal data breaches under DPDP: your 72-hour response playbook

A personal data breach is the moment a privacy programme is tested for real. Under the DPDP Act, failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore, and failing to notify a breach properly up to ₹200 crore. The difference between a contained incident and a regulatory crisis is usually decided in the first three days.

This playbook explains what counts as a breach, what the 2025 Rules require you to tell the Data Protection Board and affected individuals, and how to organise your response hour by hour.

What counts as a personal data breach

The Act defines a personal data breach broadly: any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises its confidentiality, integrity or availability.

That definition goes well beyond hackers. All of these qualify:

• A ransomware attack that encrypts your customer database — loss of availability.
• An employee emailing a spreadsheet of customer details to the wrong vendor — accidental disclosure.
• A misconfigured cloud storage bucket left publicly readable — unauthorised access.
• A bug that shows one user's order history to another — unauthorised disclosure.
• A database corrupted with no clean backup — destruction or loss of integrity.

There is no materiality threshold in the Act. Unlike GDPR, you cannot skip notification because a breach is "unlikely to result in a risk". Plan on the basis that every personal data breach is notifiable.

Your two notification duties

Section 8(6) of the Act requires a Data Fiduciary to inform the Data Protection Board and each affected Data Principal of a breach. The 2025 Rules set out how.

Notifying affected individuals — without delay

On becoming aware of a breach, you must inform each affected Data Principal, without delay, in a concise, clear and plain manner, through their user account or registered mode of communication. The message must cover:

1. a description of the breach, including its nature, extent, timing and location;
2. the consequences relevant to them that are likely to arise;
3. the measures you have taken or are taking to mitigate risk;
4. safety measures they can take to protect their interests;
5. contact details of a person who can answer their questions.

Notifying the Board — two stages

You must also inform the Board without delay with a description of the breach. Then, within 72 hours of becoming aware (or a longer period the Board allows on request), you must submit a detailed report including updated facts, the circumstances and reasons for the breach, mitigation measures, any findings about who caused it, remedial measures to prevent recurrence, and a report on the notices given to affected individuals.

The first 72 hours, hour by hour

Window	Priority	Key actions
0–2 hours	Detect and mobilise	Confirm the incident is real; open an incident log; convene the response team; preserve evidence
2–6 hours	Contain and report	Isolate affected systems, rotate credentials, block exfiltration; assess CERT-In reporting; send initial Board intimation
6–24 hours	Assess scope	Identify data categories, records and individuals affected; begin forensic analysis; involve processors
24–48 hours	Notify individuals	Draft and send clear notices to affected Data Principals; brief support teams; prepare FAQs
48–72 hours	Detailed Board report	Compile facts, causes, mitigation, remediation and record of notifications; submit or request extension

Notice the order: initial intimation to the Board goes early, before you have every answer. The Rules anticipate that facts will change — that is what the 72-hour detailed report is for.

Who should be on the response team

• Incident lead — owns decisions and the timeline.
• Security / IT — containment, forensics, restoration.
• Privacy or DPO function — scoping personal data impact, notification content.
• Legal — regulatory filings, contractual notices, privilege.
• Communications and customer support — individual notices, media, call-centre scripts.
• Key processors — cloud, SaaS and managed-service providers involved in the affected systems.

Name a deputy for every role. Breaches have a habit of happening on long weekends.

Processors and the chain of responsibility

The Act places the notification duty on the Data Fiduciary, even if the breach happened at a processor. Your contracts therefore need to require processors to:

• notify you of any breach involving your data promptly — ideally within hours, not days;
• cooperate with investigation and provide the information needed for your Board report;
• maintain logs and security safeguards consistent with the Rules;
• not notify regulators or individuals on your behalf without coordination.

The security safeguards that prevent breaches

The Rules list minimum reasonable security safeguards. They include:

• securing personal data through measures such as encryption, obfuscation, masking or virtual tokens;
• access controls over the computer resources used for processing;
• visibility into access through logs, monitoring and review, so unauthorised access can be detected and investigated;
• measures for continued processing if confidentiality, integrity or availability is compromised — for example, data backups;
• retention of logs and personal data for a year to support detection and investigation, unless the law requires otherwise;
• appropriate provisions in contracts with Data Processors;
• technical and organisational measures to ensure safeguards are observed.

Regular vulnerability scanning and penetration testing are the most direct way to find exposures before someone else does — and evidence of them helps demonstrate that your safeguards were "reasonable" if a breach does occur.

Prepare before you need it

• Write an incident response plan and a one-page "first hour" checklist.
• Pre-draft notification templates for the Board and for individuals, in the languages your users read.
• Maintain an up-to-date data inventory so you can scope impact in hours, not weeks.
• Run a tabletop exercise at least twice a year using a realistic scenario.
• Keep an out-of-band contact list — if email is compromised, you still need to reach the team.

The next article in this series covers one of the strictest parts of the Act: the rules for processing children's personal data.