Data Breach Reporting Under DPDP: Understanding the 72-Hour Clock

It is 2 AM on a Tuesday. Your security team gets an alert: someone has gained unauthorized access to your user database. Names, email addresses, phone numbers, and UPI-linked payment credentials for 300,000 customers are potentially exposed. What you do in the next 6 (six) hours and the next 72 (seventy two) hours will determine whether your business survives the regulatory response that follows.

Under India’s DPDP Act 2023 and the DPDP Rules 2025, a personal data breach triggers an immediate, mandatory obligation. You must notify the Data Protection Board of India and every affected user. Delay either, and your business faces penalties of up to ₹200 crore for breach reporting failure and potentially a further ₹250 crore for inadequate security safeguards that allowed the breach to occur in the first place. Both penalties can be imposed simultaneously from a single incident.

This is the fourth article in the DPDP compliance series at The Startup Zone. Earlier pieces covered the fundamentals of the DPDP Act, consent management under the DPDP Act (forthcoming in this series), and significant data fiduciary obligations.

This one is about what happens when your data protection measures fail and how the law expects you to respond.

What Counts as a “Personal Data Breach”?

The DPDP Act defines a personal data breach broadly: any unauthorized processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data. The definition is intentionally wide.

A hacker breaching your database is an obvious example. But so is an employee accidentally emailing a customer list to the wrong recipient. So is a misconfigured AWS S3 bucket exposing user records to anyone with the right URL.

Critically — if a third-party vendor you share data with suffers a breach involving your users’ data, that triggers your reporting obligations too. The breach does not need to happen on your own systems for your clock to start.

The DPDP Act does not work this way. There is no materiality threshold. There is no harm-probability filter. If personal data has been compromised, you report. Full stop. This is a deliberate policy choice: India’s law prioritizes transparency and user empowerment over regulatory efficiency. The compliance implication is significant;

You cannot apply a risk-triage model to decide whether to notify. Every qualifying breach triggers the obligation.

The Dual Reporting Timeline Under Rule 7

Rule 7 of the DPDP Rules 2025 establishes a two-stage notification structure with distinct obligations, recipients, and content requirements at each stage.

Stage 1

Rule 7(a): Without Delay

The moment you become aware of a breach, you must notify both the Data Protection Board of India and all affected Data Principals simultaneously, without delay. This initial notification must include:

A description of the breach – its nature, apparent extent, timing, and location

An assessment of the likely impact on affected individuals

The phrase “without delay” means what it says. You cannot wait for a forensic investigation to conclude. You report on a best-knowledge basis at the moment of awareness, explicitly flagging that a detailed report will follow.

Stage 2

Rule 7(b): The 72-Hour Detailed Report

Within 72 hours of becoming aware of the breach, you must submit a comprehensive, updated report to the Data Protection Board only. This must cover:

The broad facts, events, circumstances, and reasons leading to the breach (root cause, as established)

Remediation and mitigation measures already implemented

Findings regarding the person or entity responsible for the breach, if identified

Confirmation and evidence of the user notifications already dispatched under Rule 7(a), including the content of those communications

If a genuine forensic complexity makes the 72-hour window unworkable, Rule 7(b) permits you to submit a written request to the Board for an extension.

This is not an automatic right; the Board must grant it, and you must demonstrate why it is necessary.

Stage	Rule	Recipient	Deadline	Content
Initial intimation	Rule 7(a)	Board + all affected users	Without delay	Nature, extent, timing, location, likely impact
Detailed report	Rule 7(b)	Board only	Within 72 hours	Root cause, remediation, responsible party findings, user notification confirmation
Extension request	Rule 7(b) proviso	Board	Before 72-hour deadline	Written application; not automatic

CERT-In and DPDP Running in Parallel

This is the compliance complication and is operationally more demanding for your startup.

MeitY Notification No. 20(3)/2022-CERT-In, issued on 28 April 2022 and operative from 27 June 2022 under Section 70B(6) of the Information Technology Act 2000, requires all organizations to report cybersecurity incidents, including personal data breaches, to the Indian Computer Emergency Response Team (CERT-In) within 6 hours of discovery. This is an entirely separate obligation from the DPDP regime, owed to a separate regulator, with its own penalty framework.

The CERT-In directions also clarify that if complete information is not available within 6 hours, a partial report may be submitted and supplemented with additional details within a reasonable period thereafter. This is similar in spirit to DPDP’s Rule 7(a) initial intimation, but the 6-hour hard deadline for the first filing to CERT-In is unambiguous.

For a personal data breach, you are therefore managing four parallel obligations simultaneously:

Obligation	Regulator	Deadline
CERT-In cybersecurity incident report	CERT-In	6 hours from discovery
Initial breach intimation	Data Protection Board + affected users	Without delay (Rule 7(a))
Detailed breach report	Data Protection Board	72 hours from awareness (Rule 7(b))
Ongoing user communication	Affected individuals	As new material information emerges

Example: A SaaS platform discovers at 10 AM on Monday that an API vulnerability has exposed customer records for two days. By 4 PM Monday, the CERT-In report must be filed. By the same time or sooner, initial intimations to the Board and affected users must go out under Rule 7(a). By 10 AM Thursday, the detailed 72-hour report under Rule 7(b) must be with the Board. None of this is achievable without pre-built templates and a rehearsed response team.

Building a Breach Response Plan

Pre-Incident Preparation

Designate a cross-functional incident response team: security lead, legal lead, communications lead, board-level escalation contact

Pre-draft notification templates for CERT-In, the Data Protection Board (Rule 7(a) and Rule 7(b) separately), and affected users

Confirm access credentials and submission processes for the CERT-In portal and the Data Protection Board’s digital notification system

Conduct tabletop breach simulation exercises at least twice a year

Detection and Containment (Hours 0–6)

Activate the response team immediately upon detection

Isolate affected systems without destroying forensic evidence

Begin a real-time incident log, everything to be time stamped from that moment

File the CERT-In report under Notification No. 20(3)/2022-CERT-In before the 6-hour mark

Initial Notification (Hours 0–12)

Confirm the known scope of exposed data categories

Dispatch Rule 7(a) initial intimation simultaneously to the Board and all affected users — based on available information, explicitly noting a detailed report will follow

Do not delay the initial notification waiting for complete forensic clarity

Detailed Reporting (Hours 12–72)

Complete root-cause analysis and remediation documentation

Prepare the Rule 7(b) detailed report: root cause, impact scope, remediation evidence, user notification confirmation

Submit to the Data Protection Board before the 72-hour mark

Post-Incident (Beyond 72 Hours)

Monitor for secondary impacts, credential stuffing, phishing campaigns using breached data

Issue further user communications if material new information emerges

Formally document lessons learned and update your response plan accordingly

SDF-Specific Considerations

If your organisation has been designated as a Significant Data Fiduciary, breach response carries additional weight. SDFs are subject to annual independent audits, and a breach will almost certainly be the focal point of the next audit cycle. An SDF with inadequate breach documentation faces the compounding risk of both breach-related (₹200 crore) and audit-related (₹150 crore) penalties. For the full picture of SDF obligations, see our guide to Significant Data Fiduciary compliance.

Breach Response Compliance Checklist

People and Roles

Incident response team designated: security, legal, communications, board escalation

CERT-In nodal officer appointed and registered with CERT-In portal

Roles, escalation paths, and decision authority documented

Templates and Systems

CERT-In notification template drafted and rehearsed (6-hour deadline)

Rule 7(a) initial intimation templates ready for Board and users (simultaneous dispatch)

Rule 7(b) 72-hour detailed report template structure prepared

User notification written in plain language, reviewed by legal

Real-time incident logging system in place with timestamp integrity

Infrastructure

Audit-ready access and processing logs maintained continuously

Anomaly detection and alerting systems operational

Forensic evidence preservation protocols established and tested

Third-party vendor Data Processing Agreements include breach notification obligations and timelines

Training and Testing

Tabletop breach simulation exercises conducted at least twice a year

Board-level awareness of dual-clock obligations (CERT-In + DPDP) confirmed

Post-incident formal review process documented

Need help building a breach response plan aligned with both CERT-In and DPDP requirements?

The Startup Zone can design a framework tailored to your technical stack and business model.

Next in series: Children’s Data Protection Under DPDP — Parental Consent, Age Verification, and What the Law Demands

Connect With Our Experts

Name*

Mobile*

Email*

Choose Your Services

Referrer URL

GCLID

Captcha validation failed. If you are not a robot then please try again.

Post View Counter

Post Views : Loading...

About The Author