Alastor InfoSec
← Back to Blog
Compliance

July 20, 2026 · Alastor InfoSec Team

DPDPA Breach Notification: The 72-Hour Rule Most Indian Businesses Are Not Ready For (2026)

When a data breach happens, Indian businesses now face two simultaneous, overlapping clocks. CERT-In's incident reporting mandate requires notification within six hours of detecting a qualifying cybersecurity incident. The DPDP Act's breach notification obligation — once the Data Protection Board operationalises that requirement fully in 2027 — sets a 72-hour window from the time you become aware of a personal data breach. Missing either deadline exposes your organisation to penalties that start at ₹200 crore and can stack per obligation category.

Most businesses are focused on November 2026's Consent Manager deadline and May 2027's full enforcement date. The breach notification requirements are getting far less attention — and that gap is exactly where enforcement actions are most likely to begin. Regulators globally have found breach notification non-compliance the easiest lever to pull because the failure is binary and the evidence is a timestamp.

What the DPDP Act Actually Requires on Breach Notification

Section 8(6) of the Digital Personal Data Protection Act, 2023 requires every Data Fiduciary to notify the Data Protection Board of India (DPBI) of any personal data breach in the manner and within the timeframe prescribed by the rules. The DPDP Rules, notified in April 2025, established that notification must reach the Board promptly — with the full operational framework including timelines becoming mandatory in Phase 3, commencing May 13, 2027.

That said, the 72-hour window has emerged as the working standard because it aligns with GDPR, the EU framework India consciously mirrored in key structural respects. Multiple law firm advisories, the Ministry of Electronics and Information Technology's own consultation documents, and the draft notification forms published by the DPBI all point to a 72-hour initial notification expectation. Organisations building incident response playbooks now should code 72 hours into their process even if the formal deadline shifts modestly.

The notification must cover three things: a description of the personal data that was breached, the likely consequences of the breach, and the measures being taken to mitigate harm. Critically, Data Fiduciaries must also notify affected data principals — the individuals whose data was compromised — if the breach is likely to cause them harm. This dual notification requirement (Board and individuals) is what trips most incident response plans, because most organisations have a process for notifying regulators but no mechanism for notifying hundreds of thousands of customers at machine scale.

CERT-In's 6-Hour Rule: The First Clock You Will Hit

Before you reach the DPDPA's 72-hour window, CERT-In's incident reporting mandate will already be counting. The Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013, as reinforced by CERT-In's April 2022 directions, require service providers, intermediaries, data centres, and corporate entities to report qualifying cyber incidents to CERT-In within six hours of noticing the incident.

In May 2026, CERT-In issued updated guidance sharpening the scope of covered incident types and explicitly confirming that AI-assisted attacks were triggering new categories of reportable incidents. The 6-hour window is short. In our experience on incident response engagements, most organisations spend the first six hours just figuring out what happened — not reporting it.

The practical implication: you need a detection-to-declaration workflow that runs in parallel with the technical investigation. The moment a credible indicator of a personal data breach exists, the reporting clock starts — not the moment you confirm every detail. Both CERT-In and the DPBI framework contemplate initial notifications followed by updated reports as more information becomes available.

The Gap Between Where Organisations Are and Where They Need to Be

Gartner's 2025 survey of APAC organisations found that 67% did not have a documented incident response plan tested against a breach scenario in the previous 12 months. For Indian organisations specifically, a compliance readiness survey by a major audit firm in early 2026 found that fewer than 20% had mapped personal data flows to the extent required to accurately scope a breach — meaning that even if they detect a breach, they cannot quickly determine which data principals were affected, what categories of personal data were involved, or whether sensitive personal data was compromised.

Without that data map, you cannot complete the DPBI notification form. You cannot identify affected individuals to notify them. And you cannot demonstrate to the Board that you took reasonable steps to mitigate harm. Each of those failures is a separate penalty exposure — and the DPDP Act explicitly allows penalties to stack across obligation categories.

The penalty framework makes this concrete: failure to notify the Board or affected individuals of a personal data breach carries a penalty of up to ₹200 crore (approximately $24 million USD). Failure to maintain reasonable security safeguards that would have prevented the breach is a separate category, carrying up to ₹250 crore. A single incident touching both categories creates cumulative exposure of up to ₹450 crore — before any other violations are counted.

What an DPDPA-Ready Incident Response Plan Looks Like

An incident response plan that satisfies both CERT-In and DPDPA requirements has six components. First, a data inventory that maps personal data by category, storage location, processing purpose, and which data principals it relates to. This is the foundation. Without it, you cannot scope a breach.

Second, a detection and triage protocol that defines what constitutes a "personal data breach" under the DPDP Act — not just a cybersecurity incident under CERT-In's taxonomy. A credential leak that doesn't touch personal data is reportable to CERT-In but may not trigger DPDPA notification. A misconfigured cloud bucket exposing customer records triggers both. The distinction matters and needs to be pre-decided, not adjudicated under time pressure.

Third, an internal escalation chain with decision authority clearly assigned. The person who can authorise a regulatory notification to the DPBI must be reachable within two hours of an incident being declared. In many organisations, this person is the Data Protection Officer — or, if one hasn't been designated yet, it defaults to the CISO or CEO. That person needs to be briefed, not consulted for the first time during an active incident.

Fourth, pre-drafted notification templates for both the Board and for affected data principals. The DPBI notification form requires specific fields that cannot be filled in improvisation. The data principal notification must be written in clear, simple language — and if your customer base spans multiple Indian languages, you need those templates ready in advance under Rule 3 of the DPDP Rules, which requires notices in languages listed in the Eighth Schedule to the Constitution where feasible.

Fifth, a dedicated incident response retainer or VAPT team that can support forensic investigation in parallel with regulatory reporting. The 72-hour clock does not pause for the technical investigation.

Sixth, post-incident documentation processes. The DPBI will ask for records of what you knew, when, and what you did about it. Organisations that document their incident response decisions contemporaneously — not reconstructed after the fact — are materially better positioned in enforcement proceedings.

How Continuous Monitoring Changes Breach Response

The biggest operational shift that DPDPA compliance requires is moving from periodic to continuous visibility over your data environment. An organisation that runs an annual VAPT and reviews logs quarterly will simply not detect most breaches within the timeframe required for compliant notification.

Continuous monitoring means real-time alerting on anomalous data access patterns, privilege escalation attempts, unusual API call volumes, and lateral movement indicators. It means having SIEM coverage across the systems that process personal data. And it means automated correlation — because the signal that a breach occurred is rarely a single loud event. It is usually a pattern of low-and-slow activity that only becomes visible when you correlate across log sources.

Alastor Shield provides continuous control monitoring mapped directly to DPDPA obligations, including breach notification workflows. When a potential personal data incident is detected, Shield flags the relevant data categories, the affected data principal scope, and the regulatory notification obligations — so your team spends the first six hours responding to the incident, not figuring out whether and to whom you need to report.

The Action Items You Need to Start This Week

If you are a Data Fiduciary under the DPDP Act — which covers virtually every organisation that processes the personal data of Indian individuals — three things need to happen before November 2026's Phase 2 deadline, and certainly before May 2027's full enforcement.

First, complete a personal data inventory if you have not already. This is not optional and it is not an IT task — it requires active involvement from legal, compliance, and every business function that handles customer or employee data.

Second, test your incident response plan against a tabletop exercise that specifically simulates a personal data breach. Run the clock. Find out whether your team can produce a draft Board notification within four hours of a declared incident. You will almost certainly find gaps. Better to find them in a drill than during a live breach.

Third, review your CERT-In compliance posture separately. The 6-hour reporting window requires dedicated tooling and pre-authorised notification pathways. If you have not formally registered with CERT-In's reporting portal and pre-assigned internal authority to submit notifications, the first 6 hours of a real incident will be consumed by logistics.

The DPDPA's breach notification requirements are designed to be demanding. Regulators globally have found that tight notification windows force organisations to invest in detection and data management capabilities they otherwise defer. India's regulator will be no different — and the penalty framework gives the DPBI meaningful leverage to enforce.

To assess your current breach notification readiness and build a DPDPA-compliant incident response plan, reach out to the Alastor InfoSec team at [email protected] or explore Alastor Shield for continuous compliance monitoring.

The 72-hour breach notification window under the DPDP Act is short enough to require preparation months in advance — organisations that treat incident response as a fire drill, not a fire, will be the ones that satisfy both CERT-In and the Data Protection Board when a breach actually happens.

We use cookies to keep the platform secure and understand how our site is used. See our Security & Data policy for details.