DPDP Breach Notification: The 72-Hour Rule Explained
Prepare the DPDP Rule 7 breach workflow, distinguish initial notices from the 72-hour report, and check staged commencement before applying deadlines.
Plan DPDP breach response as two notification tracks. Rule 7 describes notice to affected people and notice to the Data Protection Board. Its detailed Board report has a 72-hour period tied to awareness, subject to the rule's extension mechanism.
Check commencement separately. The notified Rules place Rule 7 in the group that commences eighteen months after Gazette publication. On 12 November 2026, that rule is not yet in force under that schedule. Existing duties under other applicable laws can still require action. Final DPDP Rules, Rules 1 and 7.
Separate preparation from an effective legal deadline
Use the current notification and any applicable later changes to establish the actual legal schedule. Prepare the incident process now. Do not describe a future Rule 7 obligation as a currently active deadline for every organization.
Your response owner must assess the laws, regulator instructions and contractual duties that apply to the incident. The DPDP track does not replace them. Use the DPDP commencement guide alongside the legal review.
Keep both notification tracks visible
| Track under Rule 7 | Timing described by the rule | Preparation needed |
|---|---|---|
| Affected data principals | Without delay after awareness | Clear notice, protective steps and a contact route |
| Initial Board intimation | Without delay after awareness | Known nature, extent, timing, location and likely impact |
| Detailed Board information | Within 72 hours after awareness, subject to permitted extension | Updated facts, mitigation, findings, remedial actions and notification evidence |
The 72-hour period is not permission to postpone the initial notices. Record the awareness time and uncertainties as the investigation develops. Avoid inventing a second clock that starts only after every detail is confirmed.
Define incident roles before an alert
Assign an incident lead, security responder, legal reviewer, communications owner and decision-maker for customer notices. Choose alternates who can act if the normal owner is unavailable.
Prepare a contact route that works during an identity-provider outage. Give responders the least access needed. Use the emergency administrator guide for controlled recovery access.
Preserve evidence while containing harm
Contain the incident and preserve relevant evidence through an agreed procedure. Evidence collection should not create an unprotected duplicate of the affected personal data.
Record which system, account and data category were involved. Keep investigation references, confidence levels and the basis for each decision. Application access logs, identity events and infrastructure evidence answer different questions.
An identity audit log alone may not show which patient record, customer export or business document an application exposed. Use application audit evidence to map those gaps.
Run a synthetic response exercise
- Create a fictional incident reference.
- Record an exercise awareness timestamp.
- Assign the notification and investigation owners.
- Identify the affected synthetic data categories.
- Draft the initial notices from known facts.
- Record unresolved facts and investigation owners.
- Prepare the detailed report and notice evidence.
- Review timing and communication failures.
Mark every exercise artifact as fictional. Do not send exercise notices to customers or regulators. The exercise tests preparation rather than establishing legal compliance.
Prepare a factual notification record
| Field | What the record should contain |
|---|---|
| Awareness | Time, source and responsible decision-maker |
| Scope | Affected systems, data categories and known people |
| Impact | Known consequences and current uncertainty |
| Mitigation | Actions completed and actions in progress |
| Communication | Recipient group, approved text, channel and dispatch evidence |
| Follow-up | Updated findings, corrections and responsible owners |
Separate verified facts from hypotheses. Keep a version history so later information can correct an earlier notice without erasing the decision record.
Review authentication incident readiness with NamoID
NamoID engineers can help review authentication events, session containment and integration evidence. Your organization owns incident assessment, application investigation and required notifications.
For an architecture discussion, share a synthetic scenario and your stack in Slack for an early response. Use the published security contact for an actual incident. Contact the NamoID team