Data Breach Notification Under DPDP: What You Must Do in 72 Hours

What is data breach notification under DPDP?

Section 8(6) of the Digital Personal Data Protection Act, 2023 requires a Data Fiduciary to intimate the Data Protection Board of India and each affected Data Principal when a personal data breach occurs, in the form and manner prescribed. Rule 7 of the DPDP Rules, 2025 prescribes it. The Act defines a personal data breach broadly: any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises its confidentiality, integrity or availability.

Two points catch teams out. First, the definition has no materiality threshold, so a small incident can still be reportable. Second, the 72-hour clock starts when you become aware of the breach, not when your investigation ends. For the full timeline of when each Rule applies, see our DPDP Rules 2025 timeline.

What does DPDP require, and by when?

Who you notify	When	What it must cover
Each affected Data Principal	Without delay, after you become aware	The nature, extent, timing and location of the breach; likely consequences; mitigation steps taken; safety steps the person can take; and business contact details of someone who can answer questions
The Data Protection Board (first intimation)	Without delay	A description of the breach, including its nature, extent, timing and location, and the likely impact
The Data Protection Board (detailed report)	Within 72 hours of becoming aware, or a longer period the Board allows on written request	Events and reasons leading to the breach, mitigation measures, findings about who caused it, remedial steps to prevent recurrence, and a report on the intimations sent to Data Principals

Check the exact wording against the Gazette text of Rule 7 before you build your templates, and confirm how the Board will accept intimations (portal, format and fields) once it is operational.

What should you do in the first 72 hours?

Rule 7 sets one fixed deadline, the 72-hour report. The schedule below is our suggested internal plan, not wording from the Rules. It is built so that the "without delay" notices go out early and the detailed report is mostly written by the time the deadline approaches.

Window	Goal	Actions
Hours 0 to 4	Detect and triage	Log the time you became aware; open an incident record; assign an incident lead; preserve logs and evidence; confirm whether personal data is involved
Hours 4 to 12	Contain and scope	Stop the exposure (revoke keys, isolate systems, close the bucket); identify affected systems, data types and Data Principals; check if a processor is involved; start the CERT-In clock if the incident is reportable there
Hours 12 to 24	Notify without delay	Legal confirms reportability; send the first intimation to the Board; send plain-language notices to affected Data Principals through their registered channel or account; stand up a contact point for questions
Hours 24 to 60	Investigate and remediate	Establish root cause and the responsible party; apply fixes; monitor for misuse; draft the detailed report as findings arrive
Hours 60 to 72	File	Compile the report, attach the record of Data Principal notices, have legal and the DPO or privacy lead sign off, file with the Board, and request an extension in writing if investigation is incomplete

Do not wait for a complete investigation before sending the first notices. Delay because "we are still investigating" is not a safe position, and the Rule expects supplementary updates as facts emerge.

What must the notice to affected Data Principals say?

Write it for a non-expert, in clear and plain language, and send it through the channel the person uses with you, such as their user account or registered email or mobile number. Include:

• • What happened: the nature of the breach, how much data, when and where it occurred.
• • Likely consequences for that person, such as phishing or fraud risk.
• • What you have done to mitigate the risk.
• • What they can do: change passwords, watch accounts, ignore suspicious calls, block cards.
• • Who to contact: business contact details of a person who can answer.

Avoid blame, jargon and legal hedging. A clear notice reduces complaints, and a vague one can generate them.

What must the 72-hour report to the Board include?

• • The broad facts: events, circumstances and reasons that led to the breach.
• • Measures implemented or proposed to mitigate the risk.
• • Findings about the person who caused the breach, where known.
• • Remedial measures taken to prevent recurrence.
• • A report on the intimations given to affected Data Principals.

The last item is easy to forget. You need a record of who was told, when, through which channel and with what text, which is why notification tooling should log its own activity.

Why do real-time audit trails and breach monitoring matter?

The Board will judge you on two things: whether you had reasonable security safeguards in place under Section 8(5), and whether you notified correctly. Both depend on evidence. Rule 6 expects logging, monitoring and review to detect unauthorised access, and retention of relevant logs and personal data for one year to support investigation.

That is why real-time audit trails and breach monitoring are practical requirements, not extras. They help in four ways:

• • Faster awareness. The sooner you detect unusual access, the more of the 72 hours you keep for investigation.
• • Accurate scoping. Time-stamped access records show which systems, records and Data Principals were touched, so your notices are specific.
• • Defensible reporting. The detailed report asks for causes, findings and remedial steps. Logs turn those from recollection into evidence.
• • Proof of timing. A tamper-evident record of when you became aware and when you notified answers the "without delay" question.

If audit logs are scattered across applications and retained for different periods, reconstruction takes days. A single, consistent trail takes hours.

Which mistakes make DPDP breach notification harder?

• • Treating 72 hours as the only deadline. The notices to Data Principals and the first intimation to the Board are due without delay.
• • No data inventory. If you do not know where personal data sits, you cannot say who is affected. See how to build a RoPA and automate PII discovery.
• • Weak processor contracts. You remain responsible for breaches at processors. Require prompt alerts, ideally within hours, and cooperation on facts.
• • Short log retention. Rule 6 expects one year. Check that every system, including SaaS tools, keeps logs that long.
• • No contact list or channel. If you cannot message affected people quickly, you cannot meet the duty.
• • Ignoring parallel rules. CERT-In's cyber incident directions have their own, shorter reporting window and run alongside DPDP. Sector regulators such as RBI may add duties.
• • Never rehearsing. The first time you write a Rule 7 notice should not be during a real incident.

What is the cost of getting it wrong?

Failing to notify the Board and affected Data Principals can attract a penalty of up to ₹200 crore, and failing to maintain reasonable security safeguards up to ₹250 crore. Penalties are caps, set by the Board after considering factors such as gravity, duration and mitigation. The full schedule is in our guide to DPDP Act penalties and breach notification.

A breach-readiness checklist

• • Named incident lead, legal decision-maker and DPO or privacy contact, reachable around the clock.
• • Pre-approved templates for the Data Principal notice, the first Board intimation and the 72-hour report.
• • Current inventory of systems, data categories and processors.
• • Logs retained for at least one year, with tamper-evident storage.
• • A channel to reach affected Data Principals at scale.
• • Processor contracts with breach-alert clauses.
• • A tabletop exercise in the last six months, with timings recorded.

How Pixl supports breach readiness

Pixl is an AI-powered DPDP compliance platform with Discover, De-ID and Consent engines, deployable on-premise or in the cloud. The Discover engine maintains the data inventory that lets you scope an incident, the De-ID engine masks and tokenises data so less is exposed if a breach occurs, and the Consent engine keeps a signed, tamper-proof ledger with a full audit trail. The operations layer adds audit and reporting, producing inspection-ready records. To see the controls against your own systems, book a demo.

Frequently asked questions

• • What is the data breach notification deadline under DPDP? You must notify affected Data Principals and the Board without delay, and file a detailed report with the Board within 72 hours of becoming aware of the breach, or within a longer period the Board allows on written request.
• • When does the 72-hour clock start? When you become aware of the breach, not when the investigation is complete or the cause is confirmed.
• • Do I have to report every personal data breach? The Act's definition has no materiality threshold, and the notification duty applies to a personal data breach. Build a process that reports promptly, and take legal advice on borderline cases.
• • Who must notify if a processor is breached? The Data Fiduciary stays responsible for processing done on its behalf, so it must ensure the Board and affected Data Principals are notified. Your processor contract should require prompt alerts and cooperation.

Use Pixl to expand your business opportunities

Ready to transform? Commence your Digital Transformation journey now!

Get Started