The 72-Hour Breach Clock: What DPDPA Actually Requires (And How Indian Startups Will Fail It)

At 11:47pm on a Tuesday, your database administrator notices unusual query patterns. By 2am, it's confirmed: 85,000 customer records — names, phone numbers, and purchase histories — have been accessed by an unauthorized party. The breach happened. The 72-hour clock just started.

Under the Digital Personal Data Protection Act 2023 and Rules 2025, you now have exactly 72 hours to notify the Data Protection Board of India. Not to investigate the breach fully. Not to fix the vulnerability. Not to consult your lawyers. To notify the Board — with specific, mandated information — within 72 hours of becoming aware.

What the Law Actually Says

Section 8(6) of the DPDPA places the breach notification obligation squarely on the Data Fiduciary: 'In the event of a personal data breach, the Data Fiduciary shall, as soon as possible, give the Board and each affected Data Principal, notice of such breach in such form and manner as may be prescribed.'

Rule 7 of the Digital Personal Data Protection Rules 2025 operationalises this. It specifies what the notification to the Board must contain:

1. 1A description of the personal data breach, including the nature of the breach
2. 2The categories and approximate number of Data Principals affected
3. 3The categories and approximate number of personal data records affected
4. 4The likely consequences of the personal data breach
5. 5The measures taken or proposed to be taken to address the breach, including to mitigate its possible adverse effects
6. 6Any findings regarding the person responsible for the breach
7. 7Remedial measures taken to prevent recurrence
8. 8A report regarding notifications given to affected Data Principals

This is not a brief email to an inbox. This is a structured, detailed document. And you need it ready — and submitted — within 72 hours of becoming aware of the breach.

When Does the 72-Hour Clock Start?

This is the question most businesses get wrong. The clock starts when you become aware of the breach — not when the breach occurred, not when your legal team confirms it, not when your incident response vendor completes their initial assessment.

What counts as 'becoming aware'? This is not yet defined by the Board through case law, but reading the Act conservatively: awareness begins when any person within your organisation — including a junior data analyst, a support agent, or an automated monitoring alert — has reasonable grounds to believe a breach has occurred.

The practical implication: your 72-hour notification does not need to be complete. Rule 7 implicitly allows for partial information in the initial notification, with a follow-up report submitted after the investigation is complete. Submit what you have. Update it as you learn more.

The 4 Operational Failures That Will Make Indian Startups Miss It

Having reviewed how breaches are typically handled at Indian startups and SMEs, these are the four failure modes that will cause organisations to miss the 72-hour window — not because they didn't know the rule, but because they didn't have the operational infrastructure to execute it.

Failure 1: Nobody Knows Who Owns Breach Response

In a 50-person startup, a breach detected by the infrastructure team at 2am typically triggers a chain of WhatsApp messages: ops pings CTO, CTO pings founder, founder says 'get the lawyer on the phone.' By the time anyone thinks about notifying the Board, 36 hours have passed in internal escalation alone.

What's needed: a documented incident response owner. One named person whose job it is to make the Board notification call, regardless of who else is involved in the technical response. This person needs a template, a Board contact endpoint, and authority to act without waiting for founder sign-off.

Failure 2: No Record of Detection Time

The Board will ask: when did you become aware of the breach? If your answer is 'sometime Tuesday night,' you have a problem. The Board needs a timestamped detection record to verify you met the 72-hour window. If your earliest documented record is a WhatsApp message that says 'something looks wrong with the DB,' that is your detection timestamp — not the incident ticket you created 18 hours later.

What's needed: any breach-related event must be logged with a timestamp the moment it is identified. The right system creates an immutable incident record at detection time, not retrospectively.

Failure 3: You Don't Know What Data Was Affected

Rule 7 requires you to specify the categories and approximate number of Data Principals affected. Most Indian startups cannot answer this question within 72 hours because they don't have a current data inventory. They don't know which tables hold what categories of personal data, which records belong to which user segment, or how many records were in the affected dataset.

A company with a proper Record of Processing Activities can cross-reference an affected database table against their inventory and know within an hour: '85,000 Data Principals, categories: name, phone, purchase history.' Without an RoPA, this becomes a multi-day investigation.

Failure 4: The Board Notification Needs to Be Drafted From Scratch

Rule 7 specifies 8 mandatory data points that must be in the Board notification. In the middle of an active breach response — engineers fixing the vulnerability, lawyers on calls, management in crisis mode — someone needs to sit down and draft this document from scratch in a format the Board will accept.

What's needed: a pre-built notification template with all 8 Rule 7 fields, pre-filled with your organisation's standard information, with blank fields for incident-specific details. The notification should take 30 minutes to complete, not 6 hours.

The Follow-Up Report Obligation

The 72-hour notification is the first document. Rule 7 also requires a follow-up report to be submitted to the Board after your investigation is complete. This report must include: the findings regarding the person responsible for the breach, the remedial measures taken to prevent recurrence, and a report on notifications sent to affected Data Principals.

There is no specified deadline for the follow-up report in the Rules — the requirement is that it be submitted after the investigation. However, leaving it indefinitely open is not advisable. Best practice is to target 30 days post-incident for the follow-up report, aligning with the rights request SLA as a reference point.

Notifying Affected Data Principals

Alongside the Board notification, you must notify each affected Data Principal 'as soon as possible.' The notification to principals must explain: what happened, the likely impact on them, and what steps they can take to protect themselves.

Unlike the Board notification, there is no specific 72-hour clock for principal notifications — the standard is 'without undue delay.' However, the follow-up report submitted to the Board includes details of principal notifications sent. If you notified the Board promptly but notified affected principals three weeks later with no explanation, expect that gap to be questioned.

What Counts as a 'Personal Data Breach'?

The DPDPA does not define personal data breach specifically, but the obligation under S.8(6) applies to any breach of the security safeguards required under S.8(5). Reading the Act holistically: a personal data breach includes any unauthorised access, disclosure, alteration, or destruction of personal data.

Critically: Rule 7 requires reporting 'in the event of a personal data breach' — there is no de minimis threshold in the current Rules. Unlike GDPR (which has a risk-based threshold for notification), DPDPA's current text does not say 'only if the breach is likely to result in harm.' The conservative reading is: all breaches require notification.

The Operational Checklist: What You Need Before a Breach Happens

Breach response capability cannot be built during a breach. It must exist before one occurs. Here is the minimum operational infrastructure every Indian business needs:

1. 1Named incident response owner with pre-delegated authority to submit Board notifications
2. 2Documented incident detection and logging process — every breach-related event timestamped at the moment of awareness
3. 3Current RoPA (Record of Processing Activities) so affected data categories can be identified within hours
4. 4Pre-built Board notification template with all 8 Rule 7 fields
5. 5Pre-built affected principal notification template
6. 6Board contact endpoint and submission process understood in advance
7. 7Follow-up report template for post-investigation submission

The Enforcement Reality in 2026

The Data Protection Board of India was constituted in November 2025. It is operational and accepting complaints. While the full enforcement provisions (Rules 3, 5-16) come into force 18 months after the Rules notification — May 2027 — breach notification under S.8(6) is not a provision that waits for the 18-month timeline. The Board is operational now.

Enforcement under the Board is complaint-driven. Any affected Data Principal can file a complaint. A 50-person fintech startup that suffers a breach and fails to notify the Board within 72 hours could face a ₹200 crore penalty from a complaint filed by a single affected user. This is not a theoretical risk — it is the architecture of the enforcement system.

What DPDPA Shield Does For You

DPDPA Shield's Breach Management module is built specifically around the 72-hour operational requirement. When you log an incident, the 72-hour countdown starts automatically with escalation alerts at 48, 60, and 68 hours. The platform generates a pre-filled Board notification draft using Rule 7's mandatory fields. Your incident data — detection time, affected categories, principal count — is pulled from your Data Inventory automatically.

The principal notification is drafted and can be sent directly from the platform. Every action is timestamped and immutably logged — producing the evidence trail the Board will want to see.