DPDPA Rule 7: The 72-Hour Clock on Data Breach Notification

A data breach is chaos. DPDPA Rule 7 is the stopwatch that starts ticking the moment you realize it happened.

Rule 7 sets clear breach notification duties for Data Fiduciaries. It requires prompt, plain-language communication to affected individuals and rapid disclosure to the Board, with a defined content checklist and a strict timeline. If you process personal data in India, this rule dictates exactly what you say, to whom, and by when. It turns a bad day into a highly regulated sprint.

Scope and Trigger

The trigger is deceptively simple: becoming aware of any personal data breach.

Once aware, the Data Fiduciary must notify:

• Each affected Data Principal without delay.
• The Board without delay, followed by a detailed submission within 72 hours, unless the Board grants more time on written request.

These obligations apply to any personal data breach. Scale, cause, and medium do not matter.

Notification to Affected Data Principals

You cannot hide behind legalese. The notification to individuals must be concise, clear, and in plain language. It must be sent without delay through the Data Principal’s user account or any mode of communication they have registered with the Data Fiduciary.

The notice must include:

• Description of the breach, including its nature, extent, and the timing of occurrence.
• Likely consequences relevant to the individual.
• Measures implemented and being implemented by the Data Fiduciary to mitigate risk.
• Safety measures the individual can take to protect their interests.
• Business contact information for a person who can respond on behalf of the Data Fiduciary to any queries.

This is not a legal formality. It is an action-oriented alert that tells people what happened, what it means for them, what you are doing, and what they should do next,with a named contact for follow-ups.

Reporting to the Board

The Board expects facts, causation, mitigation, accountability, and proof that individuals were informed. You deliver this in two stages.

1) Initial intimation without delay:

• A description of the breach, including its nature, extent, timing, and location of occurrence, and the likely impact.
• Updated and detailed information on the description above.
• Broad facts about the events, circumstances, and reasons that led to the breach.
• Measures implemented or proposed to mitigate risk.
• Any findings regarding the person who caused the breach.
• Remedial measures taken to prevent recurrence.
• A report on the intimations sent to affected Data Principals.

Communication Channels and the “User Account”

A crisis is not the time to test a new email vendor. Notices to individuals must be sent through the user account or any communication mode registered by the individual, such as email or phone number.

“User account” is broad. It covers any online account the individual has registered with the Data Fiduciary, including profiles, handles, email addresses, or phone numbers used to access services. The purpose is reachability and speed. Pick channels that are already registered and reliable. Do not invent new contact methods while the house is on fire.

Timing Expectations and Extensions

• ”Without delay” means act as soon as you are aware and have enough information to communicate the required elements. Do not wait for full forensics to start notifications.
• The DPDP 72 hour notification clock is hard. It runs from the exact moment you become aware of the breach. If you cannot meet it, request an extension from the Board in writing, with reasons.
• Continue to update as facts evolve. The rule anticipates iterative detail in the Board follow-up.

What This Means in Practice

A breach response runbook that has not been tested is a theory, not a capability. Operationalize these duties before a breach occurs. At minimum:

• Maintain a breach response runbook with roles, decision criteria for awareness, escalation paths, and pre-approved templates that map to DPDPA Rule 7 content requirements.
• Establish reliable outbound channels tied to user accounts and registered contact points. Test deliverability and logging.
• Keep a live roster of contacts who can serve as the named responder in notices, with alternates for after-hours coverage.
• Instrument systems to timestamp detection, triage, and the exact time you became aware. These timestamps anchor the regulatory timeline.
• Prepare to notify in phases. If the affected population is not fully identified, inform those confirmed as affected and record the rationale for staged notifications.

Content Quality and Precision

Vague statements are a liability. Be specific about what data types are involved, time windows, and systems affected.

Tailor likely consequences to the individual’s context. If credential compromise is possible, say so and list the specific actions to take. Include mitigation steps you have implemented or are implementing, whether that is containment, password resets, fraud monitoring, or access revocation. Finally, ensure the contact person listed is briefed, available, and actually able to answer questions.

Documentation and Evidence

If it is not documented, it did not happen. Create an audit-ready record:

• The moment of awareness and who determined it.
• Copies of all notifications to individuals, including timing, channels used, and delivery status where available.
• The initial and 72-hour Board submissions, with supporting facts.
• The fact base for root cause, the person who caused the breach if identified, and preventive measures taken.
• A log of requests to the Board for any extension and the Board’s response.
• Version control for updates and corrections.

Common Pitfalls to Avoid

• Waiting for certainty before notifying. The rule expects speed with updates to follow.
• Mixing notices to unaffected individuals. Identify the affected population with care.
• Leaving out the named contact for queries. The rule requires business contact information of a responder.
• Ignoring the location of occurrence in the initial report to the Board.
• Missing the report on how and when Data Principals were intimated in the 72-hour submission.
• Failing to align outward communications across teams. Keep legal, security, support, and PR on the same page with approved language.

Minimal Checklist Mapped to Rule 7

When aware of a breach:

• Notify affected individuals without delay through user account or registered channel. Include description, likely consequences, your mitigation, safety measures for the individual, and contact info of a responder.
• Intimate the Board without delay with nature, extent, timing, location, and likely impact.
• Within 72 hours provide the Board with updated description, broad facts and reasons, mitigation measures, findings on the person who caused it if any, remedial steps to prevent recurrence, and a report on individual intimations.
• If needed, request more time from the Board in writing and document the reasons.
• Maintain complete records of all actions taken.

Getting DPDP Act breach notification right is not about writing good prose. It is about timing, substance, and proof of execution. Teams that rehearse this flow close investigations faster and reduce regulatory friction.

Translating a rule into a working runbook is where most programs stumble. Deadlines, templates, evidence tracking, and cross-functional coordination are easy to miss when the clock is ticking. At Regodit, we built a structured way to manage these moving parts. We align your policies, controls, and evidence so that when the stopwatch starts, your notifications meet Rule 7 requirements with operational discipline,not chaos.