DPDP Breach Notification: The 72-Hour Rule Explained

A security incident used to be an engineering problem. If you handle personal data of people in India, it's now a legal one too. Under the Digital Personal Data Protection Act, 2023 and the DPDP Rules notified in November 2025, a personal data breach starts a clock you cannot pause. So let's go through it step by step: what counts as a breach, who you have to tell, what the 72-hour report must contain under Rule 7, what it costs to get it wrong, and a runbook your engineers can actually follow at 2am.

This is general information for product and engineering teams, not legal advice. Confirm specifics with your own counsel and your Data Protection Officer.

What counts as a personal data breach

The DPDP Act defines a personal data breach broadly. It is any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data, that compromises the confidentiality, integrity, or availability of that data. You can read the Act text on the MeitY data protection framework page.

Two things in that definition trip teams up.

First, it's not only about leaks. Loss of access counts too. Ransomware locks a database of user records? A botched migration wipes account data with no recoverable backup? Both are breaches, even though nothing ever left your servers.

Second, there's no harm threshold and no minimum record count in the rule. A breach is a breach whether it hits one data principal or a million. There's no "too small to report" exemption. The Board can weigh severity later when it sets penalties, but that's a separate question from whether you have to notify.

Personal data here means any data about an identifiable individual: names, email addresses, phone numbers, device identifiers, location, and anything that identifies a person directly or in combination with other data. If your auth system stores it, it is in scope.

A quick test for your on-call engineer: did confidentiality, integrity, or availability of personal data get compromised by something unauthorised or accidental? If yes, treat it as a reportable breach and start the clock.

Notifying the Board vs notifying data principals

Rule 7 of the DPDP Rules creates two separate notification duties, and they have different audiences, content, and tone. Mixing them up is a common mistake.

For data principals, on becoming aware of a breach you must tell each affected person without delay, in concise and plain language, through their account in your product or any channel they registered with you (email, phone). That notice must describe the breach including its nature, extent, and timing; the likely consequences; the measures you have taken and are taking to limit harm; the steps the user can take to protect themselves; and business contact details of someone who can answer their questions.

For the Board, you also notify without delay with an initial description, then follow with the detailed 72-hour report below.

The 72-hour detailed report

The Board notification is a two-stage process, and this is the part most timelines get wrong.

Stage one is the initial intimation. On becoming aware of the breach, you tell the Board without delay. In practice this means hours, not days. This first message describes the breach: its nature, extent, timing, and location of occurrence, and the likely impact.

Stage two is the detailed report. Within 72 hours of becoming aware of the breach, you must give the Board updated and detailed information. The Board can allow a longer period only if you make a written request and it agrees. Do not assume an extension. Plan for 72 hours.

The phrase that controls everything is "becoming aware." The clock doesn't start when the breach happened. It starts when your organisation becomes aware of it. That gap matters more than it sounds. An attacker may have had access for weeks before your alerting fired. Your 72 hours run from awareness, which makes detection time, logging, and a clear escalation path the difference between a calm filing and a missed deadline.

Engineering implication: the moment an incident is confirmed as involving personal data, someone must record the awareness timestamp. That single timestamp anchors your entire legal timeline, so capture it in your incident tracker, not in a chat message that scrolls away.

Required contents under Rule 7

The 72-hour detailed report to the Board has to carry specific contents. Rule 7 expects the report to include:

• The broad facts: the events, circumstances, and reasons that led to the breach.
• The measures implemented or proposed to mitigate the risk to affected data principals.
• Your findings about the person or cause that triggered the breach, to the extent known.
• The remedial measures taken to prevent a recurrence.
• A report on the intimations you have given to affected data principals, including how and when you notified them.

You can read a clause-level walkthrough of Rule 7 on the DPDP Rules reference and a practical timeline summary in Medianama's coverage of the breach reporting timeline.

Notice the last item. The Board doesn't just want to know you had a breach. It wants evidence that you told the affected users. So those data-principal notifications aren't optional follow-up work to do later. They feed straight into the report you owe the Board. Run both tracks in parallel from hour zero.

A useful way to think about it: the Board report is a structured account of facts, cause, impact, fix, and notice. If your incident template already captures those five buckets as you investigate, the filing writes itself.

Penalties for getting it wrong

The DPDP Act puts real money behind these duties. The penalties are set out in the Schedule to the Act and are decided by the Data Protection Board after adjudication, so the figures below are maximums, not automatic fines.

Two points stand out for engineering leaders.

First, the largest penalty, up to ₹250 crore, is for failing to implement reasonable security safeguards. Legal commentators point out this can bite even where no breach has happened yet, because the duty is simply to have the safeguards in place. There's more in Bar and Bench's view on the DPDP penalty regime. Encryption at rest, access controls, audit logging, credential rotation: under this Act, those aren't nice-to-haves. They're the legal baseline.

Second, the notification failure penalty, up to ₹200 crore, is separate. You can be penalised for the breach and again for handling the disclosure badly. Good incident hygiene is its own line of defence.

For how this fits the wider obligation set, see our DPDP audit trail requirements for engineers and the DPDP compliance checklist for SaaS teams.

An engineering incident-response runbook

A legal timeline is only as good as the runbook behind it. Here is a sequence your on-call and security teams can adopt. The goal is simple: capture the awareness timestamp, preserve evidence, and run the Board and data-principal tracks in parallel.

# T+0  Confirm and timestamp awareness, this anchors the legal clock
INCIDENT_ID="inc-$(date +%Y%m%d-%H%M)"
AWARE_AT="$(date -u +%FT%TZ)"     # store in UTC, immutably
echo "incident=$INCIDENT_ID aware_at=$AWARE_AT" >> /var/log/incidents.log
 
# T+0  Page the responders: security lead, DPO, on-call eng
# T+0  Preserve evidence BEFORE remediating, snapshot logs, DB, access records

Run these tracks at the same time, not in sequence:

1. Contain and preserve. Stop the bleeding, but snapshot logs and access records first. You will need them for the cause analysis in the Rule 7 report.
2. Scope the data. Determine which data principals and which fields are affected. An append-only event log makes this fast, because you can replay exactly what was accessed and when.
3. File the initial Board intimation. Without delay, send the first description: nature, extent, timing, location, likely impact.
4. Notify affected users. Through their account or registered contact, in plain language, with consequences and protective steps.
5. Assemble the 72-hour report. Facts, mitigation, cause findings, remedial measures, and a record of the user notifications.
6. File and follow up. Submit within 72 hours of awareness. If you genuinely need longer, make the written request before the deadline, not after.

This is where your identity layer either helps or hurts. NamoID is built so that the data you need at step 2 already exists. Every state change appends an immutable event, which gives you a DPDP-grade audit trail without bolting on extra logging. NamoID's design also keeps the blast radius small: provider tokens are encrypted at rest with AES-256-GCM, refresh tokens rotate and self-revoke the whole chain on reuse, and only the public signing key is ever exposed via the JWKS endpoint. For India verification, Aadhaar offline e-KYC is processed in memory and never persisted; NamoID stores only the last four digits, a name-hash, and the signature-verification result. Less sensitive data at rest means a smaller breach to report if the worst happens.

If you are mapping who is responsible for the notification when a vendor is involved, read data fiduciary vs data processor before an incident, not during one.

FAQ

When does the 72-hour clock start under DPDP?

It starts when your organisation becomes aware of the breach, not when the breach occurred. That makes detection speed and a clear escalation path critical, because an attacker may have had access long before your alerting noticed. Record the awareness timestamp immediately so your legal timeline has a fixed anchor.

Do I have to notify users even for a small breach?

Yes. Rule 7 has no minimum record count and no harm threshold for the notification duty. On becoming aware of a personal data breach you must intimate each affected data principal without delay, in plain language. The Board can weigh severity when deciding penalties, but that is separate from whether you must notify.

What is the difference between the initial intimation and the 72-hour report?

The initial intimation goes to the Board without delay and gives a first description of the breach: nature, extent, timing, location, and likely impact. The detailed report follows within 72 hours and adds the cause, mitigation measures, findings on who or what caused it, remedial steps, and a record of the user notifications you sent.

What are the penalties for failing to report a breach?

The Schedule to the DPDP Act sets a maximum of up to ₹200 crore for failing to notify the Board or affected data principals, and up to ₹250 crore for failing to implement reasonable security safeguards. These are maximums decided by the Data Protection Board after adjudication, not automatic fines.

Bring your auth layer to the table

Breach response is faster when your identity provider already keeps a clean, append-only record of every access and state change, and stores as little sensitive data as possible. NamoID is built to do exactly that for India-first products: one OIDC issuer, India verification rails, and a DPDP-grade audit trail under the same roof. See how the pieces fit in one OIDC issuer for auth, India rails, and DPDP.

Want to walk through your incident runbook with us? Book a 30-minute demo at calendly.com/polymindslabs/30min or reach the team at hello@namoid.in.