Understanding Breach Notification Under the DPDP Act

The Digital Personal Data Protection Act, 2023 introduces a mandatory breach notification framework that will reshape how Indian enterprises respond to data incidents. For compliance leaders at banks, NBFCs, insurers, and healthcare organizations, the DPDP Act breach notification obligation is not merely a procedural addition. It is a structural requirement that demands documented processes, defined timelines, and coordination across legal, IT, and compliance functions well before an incident occurs.

The Act places the obligation squarely on Data Fiduciaries, a category that encompasses most regulated enterprises processing personal data of Indian residents. Unlike sector-specific guidelines that many organizations already follow, the DPDP framework creates a universal baseline, one that will operate alongside (and sometimes overlap with) existing CERT-In, RBI, and SEBI incident reporting mandates.

Breach Notification Obligations Under the DPDP Act

Section 8(6) of the DPDP Act, 2023 requires every Data Fiduciary to notify both the Data Protection Board of India (DPB) and each affected Data Principal in the event of a personal data breach. The Act does not create exceptions based on the size of the breach or the nature of the data involved. Any breach of personal data that the fiduciary processes triggers the obligation.

This represents a departure from many global frameworks that apply materiality thresholds or risk-based assessments before notification becomes mandatory. Under the DPDP Act, the obligation is absolute once a breach is confirmed. The only operational question is how quickly and in what format the notification must occur.

For regulated enterprises already managing Data Fiduciary obligations under the Act, breach notification is the compliance area most likely to be tested first, both by the regulator and by the affected individuals who will now have enforceable rights.

The Dual Notification Requirement

The Act mandates two separate notifications for every qualifying breach. First, the Data Fiduciary must inform the Data Protection Board. Second, it must inform each affected Data Principal whose personal data has been compromised. These are independent obligations. Notifying the Board does not discharge the duty to notify individuals, and vice versa.

This dual structure creates an operational challenge that many organizations underestimate. The Board notification is likely to require technical detail, root cause information, and remediation timelines. The Data Principal notification must be comprehensible to a layperson. These are fundamentally different communication exercises that require different teams, different approval workflows, and different content.

Notification to the Data Protection Board: Timeline and Format

The DPDP Act itself does not specify an exact timeline for notification to the DPB. Section 8(6) states that notification must happen “in such form and manner as may be prescribed.” This means the rules (yet to be finalized as of mid-2025) will define the exact window. However, based on the draft rules and the government’s public consultations, the expectation is that notification will need to occur “without unreasonable delay” or within a prescribed window that is likely to be 72 hours or shorter.

Consider the practical implications for a mid-sized NBFC. A breach is detected at 2 AM on a Saturday by the SOC team. The compliance function needs to be alerted, the breach needs to be assessed and confirmed, the legal team needs to review notification content, and a submission must reach the DPB, all within what could be a 72-hour window that includes a weekend.

The format of notification to the DPB is expected to include the following elements based on draft rule consultations:

Organizations that wait for the final rules to begin preparing will find themselves building these processes under pressure. The structural work, designating response teams, creating template notifications, establishing escalation paths, should happen now.

Notification to Affected Data Principals

The obligation to notify affected individuals is where the DPDP Act breach notification requirement becomes most operationally complex. The Act requires that each affected Data Principal be informed. This is not a public disclosure requirement. It is a direct, individual notification.

For a health insurer with 20 million policyholders whose database is compromised, this means reaching each affected individual through a verifiable channel. The mode of notification (email, SMS, in-app notification, registered post) will likely be prescribed in the rules. Regardless of mode, the enterprise must have the infrastructure to deliver notifications at scale, track delivery, and maintain evidence of compliance.

Content Requirements for Individual Notification

While the exact content requirements await final rules, the notification to Data Principals will almost certainly need to include what data was compromised, what the individual should do to protect themselves, and how to contact the Data Fiduciary for further information. The language must be clear and accessible, written in a manner that a non-technical person can understand and act upon.

This creates a content governance challenge. Legal teams will want precision and liability management. Communication teams will want clarity. Compliance teams will want regulatory alignment. Without a pre-approved template framework and a defined approval workflow, these competing priorities will delay notification past any prescribed timeline.

What Constitutes a “Personal Data Breach” Under the DPDP Act

Section 2(u) of the DPDP Act defines a personal data breach as “any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction of or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data.”

This is a notably broad definition. It covers not just external cyberattacks but also internal mishandling, accidental disclosures, unauthorized access by employees, loss of devices containing personal data, and system failures that render data inaccessible. A bank employee forwarding a customer’s KYC documents to a personal email account would qualify. A ransomware attack that encrypts patient records at a hospital would qualify. An accidental deletion of policyholder data without backup would also qualify.

Distinguishing Security Incidents from Personal Data Breaches

Not every security incident constitutes a personal data breach under the DPDP Act. A DDoS attack that takes down a website but does not compromise any personal data would not trigger notification obligations under the DPDP framework (though it would still require CERT-In reporting). The critical test is whether personal data was actually compromised in terms of confidentiality, integrity, or availability.

This distinction matters operationally because it determines which incidents enter your DPDP breach notification workflow and which remain within your broader security incident management process. Your triage framework must make this determination quickly and document the reasoning, because if the DPB later questions why a particular incident was not reported, you need an auditable record of your assessment.

Building a Breach Response Process That Meets DPDP Requirements

The organizations that will comply effectively with DPDP Act breach notification requirements are those that build the response architecture before an incident occurs. Response under time pressure, without pre-defined roles, templates, and escalation paths, is where compliance failures happen.

Phase 1: Detection and Triage

The clock starts when the organization becomes aware of a breach. “Awareness” in regulatory terms is not when the CISO personally reviews an alert. It is when the organization, through any of its systems or personnel, has information sufficient to form a reasonable belief that a breach has occurred. This means your SOC team’s detection of anomalous data exfiltration at 3 AM constitutes organizational awareness, even if the compliance function is not informed until the next business day.

The triage phase must determine whether the incident involves personal data, whether it meets the DPDP definition of a breach, and what categories and volumes of data are affected. This assessment should follow a documented decision tree that produces an auditable output.

Phase 2: Containment and Assessment

While containment is primarily a technical security function, the compliance team needs real-time visibility into containment actions because these will form part of the DPB notification. The assessment phase must produce specific outputs: confirmed categories of data affected, estimated number of Data Principals impacted, initial root cause determination, and an assessment of potential harm to individuals.

Phase 3: Notification Execution

With assessment complete, the notification phase activates. DPB notification and Data Principal notification can proceed in parallel. The DPB notification should be submitted as soon as the prescribed information is available, even if the investigation is ongoing. Most frameworks allow for supplementary submissions as more information becomes available.

Data Principal notification requires activation of your communication infrastructure. For enterprises processing data of millions of individuals, this means pre-tested bulk notification systems with delivery tracking and evidence capture.

Phase 4: Documentation and Remediation

Every breach must result in a documented post-incident review, remediation actions with assigned owners and deadlines, and updates to your breach response process based on lessons learned. The DPB may request evidence of these activities during any subsequent inquiry. The penalty framework under the DPDP Act provides for fines up to INR 250 crore, and the Board’s assessment of penalty quantum will certainly consider whether the organization had adequate response processes in place.

Overlap with CERT-In Incident Reporting Requirements

For regulated enterprises, the DPDP Act breach notification obligation does not exist in isolation. It operates alongside CERT-In’s April 2022 directions that mandate reporting of cybersecurity incidents within six hours of detection. This creates a dual reporting obligation where a single breach event may trigger both CERT-In’s six-hour reporting window and the DPDP Board’s notification timeline simultaneously.

Consider a private sector bank that suffers a data breach through a compromised API endpoint. The incident involves unauthorized access to customer personal data, which means it triggers DPDP notification. It is also a cybersecurity incident involving unauthorized access to a computer system, which triggers CERT-In’s six-hour reporting mandate. The bank must notify CERT-In within six hours with technical incident details, notify the DPB within the prescribed DPDP timeline with data protection-specific information, and notify affected customers individually.

These are three distinct notifications with different content requirements, different recipients, and potentially different timelines. Add sector-specific obligations (RBI requires banks to report cybersecurity incidents to it as well, and SEBI-regulated entities have their own incident reporting frameworks), and a single breach event can trigger four or five separate notification obligations.

Consolidating Incident Response Across Regulatory Frameworks

The structural challenge this creates is one of coordination. Most organizations have separate teams handling CERT-In reporting (typically the CISO’s team), regulatory reporting to sectoral regulators (typically the compliance function), and customer communication (typically corporate communications or the business unit). Without a unified incident management workflow, these teams work in silos, potentially providing inconsistent information to different regulators about the same incident.

This is precisely where a consolidated GRC infrastructure becomes essential. Platforms like eQomply allow regulated enterprises to manage breach response workflows that account for all applicable notification obligations from a single incident record. When a breach is logged, the system can trigger parallel workflows for CERT-In, DPB, sectoral regulator, and Data Principal notifications, each with their own timelines, content templates, and approval chains, while maintaining a single source of truth about the incident itself.

What to Prepare Now

The final DPDP rules may not yet be published, but the structural requirements are clear enough to begin preparation. Organizations that wait for final rules will find themselves building response capacity under regulatory pressure, which invariably produces gaps.

Start by mapping your data processing activities to identify where personal data breaches are most likely to occur and what volume of Data Principals could be affected in each scenario. This feeds directly into your triage decision tree and your communication infrastructure requirements.

Establish a breach response team with defined roles, not just the CISO and legal counsel, but also the compliance function, the DPO (or designated person responsible for DPDP compliance), communications, and the relevant business unit head. Define escalation triggers and decision-making authority so that a 2 AM detection does not wait until 9 AM for action.

Build template notifications for both DPB and Data Principal communications. These templates should be pre-reviewed by legal and approved by relevant leadership, with blanks only for incident-specific details. In a live incident, you do not want to be drafting from scratch while the clock runs.

Finally, integrate your DPDP breach response workflow with your existing CERT-In and sectoral incident reporting processes. A single incident should trigger a unified response with parallel notification tracks, not disconnected processes that risk inconsistency.

Turning Compliance Architecture into Response Readiness

The DPDP Act breach notification framework will test organizational readiness in ways that policy documents alone cannot address. It requires operational infrastructure: detection systems that create regulatory awareness, triage frameworks that produce auditable decisions, communication systems that can reach millions of individuals with tracked delivery, and evidence management that survives regulatory scrutiny months or years after the incident.

For compliance leaders at regulated enterprises, the question is whether your current GRC infrastructure can support this level of coordinated, time-bound, multi-stakeholder response. If your breach response workflow currently lives in email threads, shared documents, and ad hoc coordination calls, the gap between that and what the DPDP Act demands is significant.

eQomply is built to address exactly this challenge for Indian regulated enterprises, providing the workflow infrastructure, evidence capture, and multi-regulatory coordination that DPDP breach notification demands alongside your existing CERT-In, RBI, SEBI, and IRDAI obligations. If you are building or upgrading your breach response framework ahead of full DPDP enforcement, a walkthrough of how this works in practice may be a useful next step.