India’s data protection law stopped being theoretical on November 13, 2025. That’s the day the DPDP Rules 2025 were officially notified, starting an 18-month enforcement clock that ends in May 2027.
For Data Fiduciaries, one obligation defines whether that deadline becomes a liability: DPDP breach notification. Get it right and you demonstrate to the Data Protection Board of India that your security programme works. Get it wrong and you’re exposed to penalties of up to ₹200 crore for failing to notify, stacked on top of up to ₹250 crore for the inadequate safeguards that caused the breach.
These aren’t separate incidents because the penalties can apply simultaneously.
What is breach notification under the DPDP Act?
Section 8(6) of the DPDP Act 2023 is the foundation. Every Data Fiduciary must notify the Data Protection Board of India (DPBI) and every affected Data Principal when a personal data breach occurs.
No exceptions. No minimum size threshold.
A breach affecting 10 records carries the same notification obligation as one affecting 10 million. This is where DPDP departs most sharply from GDPR. GDPR uses a risk-based threshold: individual notification is only required if a breach is likely to result in high risk to individuals. Organisations assess severity and decide. DPDP doesn’t offer that gate. The obligation is universal.
Rule 7 of the DPDP Rules 2025 operationalises Section 8(6) with the procedural specifics: the timelines, the two-stage structure, the required content, and the notification sequence. Rule 6, separately, governs the security safeguards Data Fiduciaries must maintain to prevent a notifiable breach. Both rules become fully enforceable in May 2027.
How the 72-hour DPDP breach notification clock works
The clock starts the moment you become aware of a breach, not when you finish investigating.
That distinction is operationally challenging. Awareness means your incident response team has confirmed a personal data breach occurred. You don’t need a complete forensic picture. You need enough to know personal data was compromised. From that point, the clock runs continuously: weekends, public holidays, and 2 AM on a Sunday all count.
Under Rule 7, the response follows two distinct stages.
Stage 1: Initial intimation to the DPBI (without delay): Send a brief preliminary report as soon as the incident is confirmed. Cover the nature of the breach, its approximate extent, when and where it occurred, and its likely impact. The purpose is to put the Board on notice. You’re not expected to have completed your investigation yet.
Stage 2: Full incident report to the DPBI (within 72 hours): This is the substantive filing. It must include an updated breach description, root cause analysis, measures taken to contain it, measures proposed to prevent recurrence, findings on who or what caused it, and a summary of Data Principal notifications sent.
After the Board notification goes out, affected Data Principals must be notified as soon as practicable. Their notification must be in plain language and should explain what happened, what data was exposed, what consequences they might face, what they should do, and a contact point for questions.
Before the 72-hour window closes, you should know:
- what data was affected,
- how many people were impacted,
- how the breach occurred,
- what remediation has been completed, and
- that both required notifications have been sent.
This is intentional. The rule is designed to encourage rapid incident response.
CERT-In vs DPBI: two separate clocks running from the same detection timestamp
This is the blind spot that is often overlooked by Indian enterprises.
DPDP breach notification doesn’t replace the existing CERT-In obligation. It stacks on top of it. CERT-In Directions (April 2022) require reporting cybersecurity incidents within 6 hours of detection to CERT-In, under the IT Act 2000. A single breach can trigger both obligations from the same timestamp.
The practical consequence is two parallel tracks:
CERT-In track: 6 hours from detection: Report the cybersecurity incident. The content is technical: incident category, affected systems, indicators of compromise, initial forensic findings. If your SOC detects a breach at 3 AM on a Tuesday, the CERT-In report is due by 9 AM.
DPDP track: 72 hours from awareness: Report to the DPBI in two stages, then notify affected Data Principals. The content is data-focused: which personal data, how many individuals, what consequences, what remediation.
CERT-In and DPBI are parallel obligations, not alternatives. Most real-world breaches qualify as both a cybersecurity incident and a personal data breach, so both clocks fire simultaneously. Your incident response plan needs two distinct tracks, two distinct templates, and two named owners, ready before any incident happens.
For regulated entities it gets more complex. Financial institutions face RBI and SEBI timelines typically within 6 hours. The CERT-In window sets the overall pace because it’s the tightest. Your detection-to-notification pipeline needs to produce a notification-ready summary in well under 6 hours.
What a DPDP breach notification must include
The DPBI full report under Rule 7 is a prescribed document, not a free-form incident summary.
For the DPBI report, Rule 7 requires: the nature, extent, timing, and location of the breach; the categories and approximate number of Data Principals affected; the likely consequences; root cause analysis; measures taken and proposed to address the breach; findings on who or what caused it; steps taken to prevent recurrence; and a summary of Data Principal notifications dispatched.
For the Data Principal notification, Rule 7 requires: a plain-language description of what happened, which categories of their personal data were involved, the likely consequences for them personally, specific protective steps they can take, and contact details for a named person at the organisation.
Two operational challenges make compliance significantly more difficult.
First, you need precision. Approximate numbers are acceptable, but vague figures invite regulator questions. Second, the Data Principal notification must be specific. Telling users “some information may have been accessed” when you know names and financial records were compromised doesn’t satisfy the obligation. The DPDP Rules explicitly require plain-language notices with actual facts, not damage-control language.
Accuracy under time pressure depends on one thing: knowing where your personal data lives before the incident starts. You can’t accurately describe which records were affected, which categories of data, how many individuals, if you’ve never mapped your data estate. Organisations that have continuous automated discovery running across cloud, SaaS, on-premises, and endpoints can scope a breach in hours. Organisations reconstructing their data map after the fact typically need days.
Matters.AI’s DSI what the industry calls DSPM layer runs continuous discovery and classification automatically, so when a breach is confirmed, the classification context and data inventory already exist. The 72-hour window is for notification work, not for finding your data.
What is the DPDP breach notification penalty
The penalty structure is designed to get board-level attention. These aren’t fines calibrated for IT teams.
The Schedule to the DPDP Act sets out two penalties that are directly relevant here: ₹250 crore for failure to implement reasonable security safeguards under Section 8(5), and ₹200 crore for failure to notify the Board or Data Principals under Section 8(6).
Both apply per violation. And they’re cumulative.
An organisation that experiences a breach, is found to have inadequate safeguards, and then fails to notify on time faces exposure across both penalty categories from the same incident. The DPBI also has independent investigative authority. A breach that becomes public before the Board receives formal notification will attract additional scrutiny. Regulators treat delayed notifications more harshly than early ones that acknowledge an ongoing investigation.
Beyond the financial penalties: DPBI investigations bring disclosure requirements, potential operational restrictions, and the reputational cost of a response that regulators found deficient. For Significant Data Fiduciaries, mandatory DPIAs, annual audits, and algorithmic risk governance layer on top of the standard breach notification requirements.
What security safeguards does DPDP require to prevent a notifiable breach
Rule 6 sets the minimum security controls every Data Fiduciary must have in place.
The requirements include: encryption, obfuscation, or masking of personal data; access controls over systems used to process it; visibility through logs and monitoring to detect unauthorised access and enable investigation; business continuity and disaster recovery measures; contractual security requirements for Data Processors; documented incident response processes; and an organisational security governance framework.
Two of these directly determine how fast you can file a compliant breach notification.
Visibility through logs and monitoring (Rule 6c): You need continuous monitoring of who is accessing personal data across your systems, not quarterly scans. An organisation that detects a breach 6 months after it began and produces only partial access logs will struggle to file a compliant DPBI report regardless of notification speed.
Documented incident response (Rule 6f): The DPBI will ask for this during an investigation. A documented, tested process is significantly more defensible than one assembled under pressure after the fact.
The logs, access records, classification context, and data lineage that Rule 6 requires are also the exact inputs that make a fast, accurate Rule 7 notification possible. They’re the same infrastructure, serving two purposes simultaneously.
Matters.ai builds both at once. The continuous data discovery and classification running under DSPM generates the data inventory Rule 6 requires. The DDR layer correlates access patterns, data movement, and behavioural signals to produce the detection capability Rule 6c mandates. When a breach is confirmed, the evidence for the DPBI report is already building in real time, pulled from one unified intelligence model rather than reconstructed from 4 fragmented tools at 2 AM.
How to build a DPDP-ready breach response before May 2027
The organisations that will meet enforcement with confidence are the ones building breach response capability now, not after their first incident.
Start with a current data inventory: You can’t scope a breach without knowing where your personal data lives. That means continuous automated discovery across every environment: cloud databases, SaaS platforms, development systems, analytics pipelines, endpoint devices. Annual data mapping exercises don’t cut it. The DPBI will ask you to specify what data was involved and how many Data Principals were affected. The inventory you had before the breach determines how fast and accurately you can answer.
Build pre-drafted notification templates: The DPBI report and Data Principal notification have required content. Writing these under incident pressure produces mistakes. Build the templates now: the CERT-In report, the DPBI initial intimation, the DPBI full report, and the Data Principal notification. Four documents, four different audiences, all legally reviewed before you need them.
Design a dual-track incident response plan: One track for the CERT-In 6-hour obligation, one for the DPDP 72-hour obligation. Each needs named owners, deputies for when people are unavailable, and documented handoffs between security, legal, and communications. The 6-hour CERT-In clock doesn’t pause while the IR team works out who owns the DPBI filing.
Build log infrastructure for fast querying: Rule 6c requires 1 year of log retention. But logs that aren’t structured for fast querying are still slow to produce under pressure. An analyst needs to navigate breach-relevant logs in hours, not days.
Run tabletop exercises, at minimum annually: A playbook that’s never been tested fails under incident pressure. Start the clock. Find the gaps before the DPBI does.
Build the data foundation, then the notification process
Every security team preparing for DPDP will spend time on notification templates, the IR playbook, and the dual CERT-In and DPBI process. Those matter. But the teams that miss the 72-hour window aren’t usually the ones who don’t know the process. They’re the ones who can’t answer, under pressure, the most basic question the DPBI will ask: what personal data was involved and how many people does that affect?
Answering that accurately in hours requires a continuously updated, classified inventory of your personal data estate before any incident occurs. It requires knowing where personal data lives across cloud, SaaS, on-premises, and endpoint environments. It requires data lineage that shows where data moved and whether it propagated to downstream systems before containment.
Ultimately, meeting the 72-hour notification requirement depends less on documentation and more on operational visibility. Organisations that know where their sensitive data resides can respond faster, produce more accurate reports, and demonstrate compliance with greater confidence. And it’s the same infrastructure that produces the audit trails Rule 6 requires, the classification context that DSPM depends on, and the behavioural detection signals that DDR uses to fire on real threats rather than noise.
Matters.ai is built DPDP-first. Continuous personal data discovery and classification across every environment, real-time DDR detection on access patterns and data movement, automated evidence generation that starts building the incident record the moment a breach is detected, all on one unified model so your DPBI notification isn’t assembled from 4 separate tools at 2 AM. See how it works at matters.ai
