DPDP Act How-To
How to Report a Personal Data Breach Under the DPDP Act
A personal data breach has happened. Here is exactly what a Data Fiduciary must do under India's DPDP Act and the DPDP Rules, 2025 — who to notify, in what order, and by when.
Effective from 13 May 2027
Section 8(6) of the Act and Rule 7 of the DPDP Rules, 2025 are not yet in force. They commence eighteen months after the Rules were notified on 13 November 2025 — that is, on 13 May 2027. Build and rehearse your response now; the duties below apply from that date. See the full DPDP commencement timeline →
On this page
The three clocks
A personal data breach triggers three notification clocks
There is no single “72-hour DPDP breach deadline.” Rule 7 sets three separate obligations, and only one of them carries the 72-hour clock.
Affected Data Principals
- Nature, extent and timing
- Likely consequences for them
- Mitigation measures taken
- Safety steps they can take
- A contact point for questions
Data Protection Board — initial
- Nature
- Extent
- Timing
- Location
- Likely impact
Data Protection Board — detailed
- Updated, detailed information
- Facts, circumstances and causes
- Mitigation measures
- Findings on who caused it, if any
- Steps to prevent recurrence
- Report on the Data Principal notices
Quick answer
The Data Fiduciary reports. When a personal data breach occurs, the Data Fiduciary must notify each affected Data Principal without delay and give the Data Protection Board an initial intimation without delay. It must then give the Board detailed information within 72 hours of becoming aware of the breach, unless the Board grants more time on a written request. Rule 7 sets no materiality, severity, risk or affected-person threshold — every event meeting the statutory definition enters the notification framework, so do not import the GDPR's risk-based test. These duties take effect on 13 May 2027. A single incident may also be a CERT-In reportable cyber incident with a separate 6-hour clock — assess both regimes independently.
Breach happened? Start here.
- Confirm personal data is actually involved.
- Contain the incident and preserve evidence.
- Record the awareness time (this starts the 72-hour clock).
- Identify affected Data Principals and contact routes.
- Start both the DPDP and the CERT-In applicability assessments in parallel.
Scope
What counts as a personal data breach?
The law requires The Act defines a personal data breach as unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises its confidentiality, integrity or availability. That is broader than hacking or data theft: accidental events count, and so does loss of access (for example, ransomware that locks personal data).
- An exposed or exfiltrated customer database
- Ransomware that exposes, destroys or locks personal data
- A customer spreadsheet emailed to the wrong recipient
- A stolen laptop or phone with accessible personal data
- Unauthorised API access exposing user or account data
- A malicious insider extracting personal data
- A deployment that makes personal data publicly accessible
- A blocked phishing attempt
- Malware isolated before it reached personal data
- A system outage that did not affect personal data
- An attempted intrusion with no compromise
Roles
Who has the reporting duty?
The law requires Section 8(6) places the notification duty on the Data Fiduciary. A Data Processor does not replace the Fiduciary as the statutory notifier — and under Section 8(1) the Fiduciary remains responsible for compliance even where a Processor handles the data on its behalf.
Data Fiduciary
Notifies the Board and each affected Data Principal under Rule 7. Owns the awareness timestamp, the notices and the 72-hour submission.
Data Processor
No express general Rule 7 duty to notify the Board. Escalates to the Fiduciary and supports investigation and notification under its contract.
Processor contract provisions to consider:
- Immediate incident escalation to the Fiduciary
- Preservation of relevant logs and evidence
- Reporting of known facts, affected systems and impact
- Support for containment, remediation and communications
- Assistance with Board and Data Principal notifications
- Sub-processor coordination
The workflow
The 10-step breach-response workflow
Each step states what to do, who owns it, what evidence to retain, and its legal status — separating what the law requires from recommended practice.
Determine whether personal data is involved
Establish whether there has been unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises confidentiality, integrity or availability. Identify affected systems, the personal-data categories, likely affected Data Principals, and whether a Processor or CERT-In duty may also apply.
Security/IT lead technical triage; Privacy/Legal assess the statutory definition.
Detection alert, initial summary, affected-system list, preliminary data map.
Law requires: notify when there is a personal data breach.
Good practice: keep a data inventory and incident-classification matrix ready in advance.
Contain the incident and preserve evidence
Take proportionate steps to stop or limit the unauthorised processing: isolate affected systems, revoke compromised credentials, disable exposed keys or tokens, close misconfigured storage, and preserve forensic evidence.
Security/IT lead; Privacy/Legal kept informed where personal data may be involved.
Containment timeline, config/access changes, screenshots and logs, provider communications.
Law requires: reasonable security safeguards under Rule 6.
Implementation: isolation and credential revocation are reasonable methods of meeting those duties.
Establish the awareness timestamp
Record the date and time the organisation became aware of the breach. Rule 7(2)(b) measures the 72-hour clock from “becoming aware,” so document the source of the information, who received it, the facts known, why they were enough to trigger the response, and who authorised the timestamp.
Privacy/Legal own the legal clock; Security/IT provide detection and escalation timestamps.
Security-alert time, escalation record, war-room log, the authorised awareness note.
Identify affected Data Principals
Determine, as far as reasonably possible, who is affected and how they can be contacted: the affected population, the data categories, available contact channels, whether data was merely exposed or actually accessed, and the likely consequences. Do not wait for full forensic certainty — notification is due without delay.
Privacy/Legal coordinate; Security, customer ops, HR, product and data engineering assist.
Population and data-set analysis, contact-method analysis, assumptions and confidence levels.
Notify affected Data Principals — without delay
The law requires Rule 7(1) requires a concise, clear, plain-language intimation to each affected Data Principal, sent through their user account or a registered mode of communication.
Your affected-person notice should cover
- What happened (nature, extent, timing)
- The likely consequences for them
- What you have done to mitigate risk
- Safety steps they should take
- A contact point for questions
Illustrative structure — not a prescribed Government form.
Privacy/Legal draft and approve; customer/comms teams deliver.
Final notice copies, delivery and bounce records, helpdesk script.
Give the Board an initial intimation — without delay
The law requires Rule 7(2)(a) requires the Fiduciary to inform the Board without delay of the breach's nature, extent, timing and location, and its likely impact. This is distinct from the detailed 72-hour submission — you need not complete the investigation first.
Privacy/Legal lead; Security provide verified facts; approve under a delegation matrix.
Initial intimation copy and proof of delivery; note of facts still under investigation.
Prepare the 72-hour detailed Board submission
72-hour clock Rule 7(2)(b) requires, within 72 hours of becoming aware: updated detailed information; broad facts, circumstances and causes; mitigation measures; findings on the person responsible, if any; remedial steps to prevent recurrence; and a report on the intimations given to affected Data Principals.
Privacy/DPO map Rule 7; Security supply forensic facts; Legal review; run workstreams in parallel.
Investigation and root-cause report, the Board submission and delivery proof, Data Principal notice report.
| Initial Board intimation | Detailed Board submission | |
|---|---|---|
| Deadline | Without delay | Within 72 hours of awareness |
| Purpose | Alert the Board | Provide detailed breach information |
| Investigation complete? | No | More developed information expected |
| Core content | Nature, extent, timing, location, likely impact | Updated details, causes, mitigation, remediation, findings on the responsible party, Data Principal notice report |
| Basis | Rule 7(2)(a) | Rule 7(2)(b) |
Request more time if necessary
The law requires The Board may allow a longer period for the Rule 7(2)(b) information on a request made in writing.
- Incident reference and original awareness time
- The information that remains unavailable, and why
- Steps already completed and interim findings
- Expected delivery date for outstanding information
- The person authorised to correspond with the Board
Check CERT-In obligations — separately
A single incident can trigger both DPDP and CERT-In duties, but the tests, recipients, deadlines and scope differ. Assess CERT-In applicability immediately and in parallel — do not wait for a final DPDP conclusion. See the comparison below.
Security/IT lead CERT-In assessment; Privacy/Legal consulted.
Separate regime: CERT-In's 6-hour rule is under the IT Act, not DPDP.
Preserve evidence and close remediation
Preserve the full evidence set (below), complete remediation to prevent recurrence, and conduct a post-incident review covering root cause, control failures, lessons learned and process changes.
See the evidence checklist below. Note that Rule 6(1)(e) requires retaining security logs and personal data for one year, and Rule 8(3) separately requires one-year retention of personal data, associated traffic data and processing logs for Seventh-Schedule purposes — these are distinct duties.
Two regimes
DPDP Rule 7 and CERT-In are separate reporting regimes
CERT-In's directions under Section 70B(6) of the IT Act, 2000 (dated 28 April 2022) require covered entities to report listed cyber incidents within six hours of noticing them. That is independent of DPDP Rule 7.
← Scroll to compare →
| Issue | DPDP Rule 7 | CERT-In Directions |
|---|---|---|
| Trigger | A personal data breach (Act definition) | A listed cyber incident (Annexure I) |
| Reporter | Data Fiduciary | Covered service provider, intermediary, data centre, body corporate or Govt organisation |
| Recipient | Board + each affected Data Principal | CERT-In |
| First deadline | Without delay | 6 hours of noticing |
| Detailed deadline | 72 hours to the Board | Per CERT-In process |
| Scope | Personal-data compromise | Listed cyber-incident categories; may or may not involve personal data |
| Purpose | Data protection & individual notice | National cyber-incident response |
Decision flow
Breach decision flow
Worked example
Timeline example
An organisation becomes aware on Monday at 10:00 AM that unauthorised API access may have exposed customer account data.
Operating model
Recommended responsibility matrix
← Scroll to see all roles →
| Activity | Security / IT | Privacy / DPO | Legal | Business owner | Leadership |
|---|---|---|---|---|---|
| Detect & log incident | Lead | Informed | Informed | Informed | Informed |
| Contain technical incident | Lead | Consulted | Consulted | Consulted | Informed |
| Assess breach definition | Consulted | Lead | Lead | Consulted | Informed |
| Record awareness timestamp | Evidence | Lead | Review | Informed | Informed |
| Identify affected Data Principals | Support | Lead | Review | Support | Informed |
| Prepare individual notice | Support | Lead | Approve | Support | Informed |
| Board initial intimation | Facts | Lead | Approve | Support | Escalate |
| 72-hour detailed submission | Facts | Lead | Approve | Support | Oversight |
| CERT-In applicability | Lead | Consulted | Review | Consulted | Informed |
| Remediate & prevent recurrence | Lead | Monitor | Consulted | Support | Oversight |
| Preserve evidence & close | Lead (tech) | Lead (compliance) | Lead (legal) | Support | Approve closure |
Evidence
Evidence to retain to demonstrate compliance
- The Data Principal notifications and their Rule 7(1) content
- The initial Board intimation (Rule 7(2)(a))
- The detailed Board submission (Rule 7(2)(b))
- Any extension request and the Board's response
- Relevant Rule 6(1)(e) security logs/records, where applicable
- Awareness timestamp and supporting records
- Incident assessment and decision log
- Forensic report, timeline, affected-system inventory
- Impact analysis; processor/sub-processor communications
- Delivery/bounce records; remediation plan and approvals
- Post-incident review and control improvements
Pitfalls
Common mistakes
Treating 72 hours as the only deadline.
Waiting for full forensics before the initial Board notice.
Importing a GDPR materiality/risk threshold.
Forgetting the affected Data Principals.
Assuming a processor's email discharges the Fiduciary's duty.
Mixing CERT-In's 6-hour rule with DPDP Rule 7.
Failing to record when the organisation became aware.
Sending vague individual notices that omit Rule 7(1) content.
Treating internal SLAs as statutory deadlines.
Assuming an extension request pauses the clock.
Not preserving delivery/submission evidence.
Treating ₹200 crore as an automatic fine.
Legal risk
Penalty exposure
Failure to observe the Section 8(6) breach-intimation obligation may attract a financial penalty of up to ₹200 crore under the Schedule to the Act. This is a maximum ceiling, not an automatic fine: the Board must weigh the Section 33(2) factors — nature, gravity and duration, the data affected, whether the breach was repetitive, any gain or loss avoided, the timeliness of mitigation, proportionality, and the likely impact. Section 33 and the penalty framework commence on 13 May 2027.
Beyond DPDP
DPDP may not be your only reporting duty
FAQ
Frequently asked questions
What is the DPDP breach-reporting deadline?
There is no single deadline. Affected Data Principals must be notified without delay, and the Board must receive an initial intimation without delay. The detailed Board submission is due within 72 hours of becoming aware, unless the Board grants more time on a written request.
Is every personal data breach reportable?
Yes. Rule 7 sets no materiality, severity, risk, financial-harm or affected-person threshold. Every event meeting the statutory definition of a personal data breach enters the notification framework.
Who must notify the Data Protection Board?
The Data Fiduciary. Section 8(6) places the duty on the Fiduciary, which remains responsible even where a Processor handles the data on its behalf.
Does a Data Processor report directly to the Board?
Not under an express general Rule 7 duty. The Processor's role — rapid escalation, evidence preservation and investigation assistance — should be handled through the contract.
When does the 72-hour clock start?
From the Fiduciary “becoming aware” of the breach. The Rules do not define awareness, so document a defensible awareness timestamp based on the facts and your internal escalation record.
What does “without delay” mean?
The law does not fix a number of hours. It should not be presented as a statutory 24-hour or 48-hour deadline; it requires prompt action without unjustified delay, while giving the required information accurately.
Can the Board extend the 72-hour period?
Yes, but only where the Board grants a longer period on a written request. Extra time is not automatic, and sending a request alone does not stop the clock.
Must affected Data Principals always be notified?
Yes. Section 8(6) requires intimation to each affected Data Principal, and Rule 7(1) prescribes the content and delivery route. There is no general risk-based exemption from individual notification.
Is CERT-In reporting also required?
It may be. Where the entity and incident fall within the CERT-In Directions (Annexure I), reporting is due within six hours of noticing the incident. This is separate from Rule 7 — assess both.
When does Rule 7 become effective?
Rule 7 and Section 8(6) commence on 13 May 2027, eighteen months after the Rules were notified on 13 November 2025.
More DPDP Act How-To Guides
Sources
Sources
Primary Government of India sources. Confirm the operative text against the Gazette at the point of use.
Digital Personal Data Protection Act, 2023 (Act 22 of 2023) — Sections 2, 8, 33 and the Schedule.
DPDP Rules, 2025 (G.S.R. 846(E), 13 November 2025) — Rules 6 and 7 and the commencement provision.
Commencement notification (G.S.R. 843(E), 13 November 2025) — staged commencement of the Act.
Corrigendum (G.S.R. 892(E), 10 December 2025) — clerical corrections to the Rules.
CERT-In Directions under Section 70B(6), IT Act, 2000 (28 April 2022) — six-hour reporting and Annexure I.
CERT-In Directions page — official source for the 28 April 2022 directions.