I. Context

The maturation of India's data-governance architecture has produced an outcome that few incident-response frameworks were designed to handle: a single cyber event can now set multiple regulatory clocks running simultaneously, each measured from the same moment of awareness, each addressed to a different authority, and each carrying its own format, threshold, and penalty. The two obligations of broadest application are the cyber-incident reporting duty owed to the Indian Computer Emergency Response Team (CERT-In) under the Information Technology Act, 2000, and the personal-data-breach notification duty owed to the Data Protection Board of India and to affected Data Principals under the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025.

These regimes were enacted at different times, under different statutory authorities, and to serve different objectives. CERT-In's mandate is the protection of the integrity and resilience of India's information infrastructure; its concern is the cyber incident as a security event. The DPDP framework's mandate is the protection of the personal data of individuals; its concern is the breach as an event affecting Data Principals. Where a security incident involves personal data, both mandates are engaged, and the two regimes overlay one another on a single set of facts.

The practical consequence is that organisations cannot treat breach reporting as a single workflow. They must operate a layered response in which the same event is assessed, characterised, and reported against two separate legal standards on two separate timelines. This article maps that overlay and sets out the contractual and operational measures required to manage it.

II. The CERT-In Regime

CERT-In is constituted under Section 70B of the Information Technology Act, 2000, which designates it as the national nodal agency for responding to computer security incidents. On 28 April 2022, the Ministry of Electronics and Information Technology issued directions under Section 70B(6), bearing notification No. 20(3)/2022-CERT-In (the "CERT-In Directions"), which came into effect on 28 June 2022 following a transition period.

The defining feature of the CERT-In Directions is the reporting timeline. A covered entity must report a specified cyber incident to CERT-In within six hours of noticing the incident, or of the incident being brought to its notice. This is among the most compressed statutory reporting windows in any jurisdiction, and it is materially shorter than the seventy-two-hour window under the European Union's General Data Protection Regulation. The clock runs from awareness, not from confirmation; an organisation that waits to complete forensic verification before reporting will, in most cases, have already missed the deadline.

The categories of reportable incident are enumerated in Annexure I to the Directions, which lists twenty incident types, an expansion from the eleven previously specified under the Information Technology (CERT-In) Rules, 2013. The enumerated categories include, among others, unauthorised access to IT systems, data breaches, data leaks, attacks on critical infrastructure, malware and ransomware incidents, denial-of-service and distributed-denial-of-service attacks, website defacement, identity theft, and phishing. The breadth of the list, combined with the absence of a general materiality threshold for many categories, means that a wide range of events fall within the reporting obligation.

The Directions impose obligations beyond reporting. Covered entities must synchronise the clocks of all ICT systems to the Network Time Protocol server of the National Informatics Centre or the National Physical Laboratory. They must maintain logs of all ICT systems for a rolling period of one hundred and eighty days, stored within India. And they must respond to CERT-In's requests for information within the time specified in each request. Specified categories of entity, including virtual asset service providers, data centres, and cloud and VPN service providers, bear additional record-keeping and KYC obligations.

The class of covered entities is deliberately broad. The Directions apply to service providers, intermediaries, data centres, body corporates, and government organisations, and CERT-In has clarified that the obligation extends to entities located outside India that offer services to users in India. The operative presumption is inclusion: an organisation that operates digital infrastructure, processes data digitally, or runs internet-facing systems should assume it is covered unless it has a clear basis to conclude otherwise.

Non-compliance carries consequences under Section 70B(7) of the Information Technology Act, which provides for imprisonment of up to one year, a fine of up to one lakh rupees, or both. The criminal character of the liability distinguishes the CERT-In regime from the civil-penalty structure of the DPDP framework, and it has implications for the seniority and care with which reporting decisions are taken.

III. The DPDP Breach-Notification Regime

The DPDP breach-notification obligation originates in Section 8(6) of the Digital Personal Data Protection Act, 2023, which requires a Data Fiduciary, in the event of a personal data breach, to give intimation to the Data Protection Board and to each affected Data Principal. The operative detail is supplied by Rule 7 of the Digital Personal Data Protection Rules, 2025, which were notified on 13 November 2025.

Rule 7 establishes a two-stage notification structure. Upon becoming aware of a personal data breach, the Data Fiduciary must, without delay, inform the Board of the breach, including a description of its nature, extent, timing, and location of occurrence, and its likely impact. The Data Fiduciary must also, without delay, inform each affected Data Principal, in a manner that conveys a description of the breach, its likely consequences, the measures taken or proposed in response, the safeguards the Data Principal may take to protect their interests, and the contact details through which the Data Principal may seek further information.

The second stage is a detailed report to the Board, due within seventy-two hours of the Data Fiduciary becoming aware of the breach, or within such longer period as the Board may permit on written request. This report must set out the broad facts and circumstances of the breach and its causes, the measures implemented to mitigate risk, the findings regarding the person who caused the breach, the remedial measures taken to prevent recurrence, and a summary of the intimations given to affected Data Principals.

A defining characteristic of the DPDP regime is the absence of a materiality threshold. Unlike the GDPR, which requires notification only where a breach is likely to result in a risk to the rights and freedoms of natural persons, the DPDP framework as drafted requires notification of personal data breaches without an express risk filter. A breach affecting a single Data Principal attracts the same notification duty as a breach affecting a population of millions. This design choice has been the subject of practitioner concern, on the basis that it is likely to generate a high volume of notifications of limited individual significance, but as a matter of compliance it removes the discretion that would otherwise permit an organisation to assess a low-impact breach as non-reportable.

Failure to comply with the breach-notification and security-safeguard obligations attracts financial penalties under the Schedule to the Act, with the ceiling for failure to take reasonable security safeguards set at two hundred and fifty crore rupees. The penalty is civil in character and is imposed by the Board following inquiry.

One temporal qualification is essential. The DPDP Rules contemplate phased commencement, and the substantive obligations, including the breach-notification duty under Rule 7, are presently expected to become enforceable following an implementation window that points towards a commencement date in or around May 2027. The obligation is therefore imminent rather than presently in force, and the period before commencement is the window in which response capability must be built.

IV. Points of Divergence

The two regimes are not variants of a single obligation; they diverge across every operative dimension, and it is the divergences that generate compliance risk.

The trigger differs. CERT-In reporting is triggered by a cyber incident of a type enumerated in Annexure I, whether or not personal data is involved; a ransomware attack that encrypts systems but exposes no personal data is reportable to CERT-In. DPDP notification is triggered by a personal data breach, whether or not it results from a cyber incident; an inadvertent disclosure of personal data through human error, with no cyber-attack element, is reportable under DPDP but may fall outside CERT-In's enumerated categories. The two triggers overlap where a cyber incident compromises personal data, but neither is a subset of the other.

The timeline differs. CERT-In requires reporting within six hours; DPDP requires intimation to the Board and Data Principals without delay, followed by a detailed report within seventy-two hours. Both clocks run from awareness, and both run continuously without regard to weekends or public holidays. The consequence is that a single event compromising personal data sets a six-hour clock and a seventy-two-hour clock running from the same instant, with the six-hour CERT-In deadline almost always the binding constraint on the speed of initial response.

The recipient differs. CERT-In reporting is made to a single authority through its prescribed channel. DPDP notification is made both to the Board and, separately, to every affected Data Principal. The Data Principal notification has no analogue in the CERT-In regime and introduces a distinct workstream, requiring the organisation to identify affected individuals, compose individualised communications, and effect delivery, all without delay.

The threshold differs. The CERT-In Directions apply to enumerated incident categories, several of which carry an implicit severity element, particularly in relation to critical infrastructure. The DPDP regime applies to any personal data breach without a materiality filter. An organisation may therefore face a DPDP notification obligation for a low-impact personal-data event that does not rise to a reportable CERT-In incident, and conversely a CERT-In obligation for a security incident that involves no personal data.

The penalty differs in character. CERT-In non-compliance carries criminal liability under Section 70B(7), with the possibility of imprisonment. DPDP non-compliance carries civil financial penalties imposed by the Board. The difference is consequential for governance: the criminal exposure under the CERT-In regime warrants a level of individual accountability and documented decision-making that a purely civil-penalty regime might not.

The critical practical principle that follows from these divergences is that compliance with one regime does not discharge the other. Reporting a personal-data-compromising cyber incident to CERT-In within six hours does not satisfy the DPDP duty to notify the Board and Data Principals, and notifying under DPDP does not satisfy the CERT-In duty. The two obligations are independent and cumulative, and each must be discharged through its own channel, in its own format, on its own timeline.

V. The Sectoral Overlay

For regulated entities, the two-regime picture understates the complexity, because sector-specific incident-reporting obligations layer on top of both. Banks, non-banking financial companies, and payment-system operators report to the Reserve Bank of India under its cyber-security framework and master directions. Market intermediaries report to the Securities and Exchange Board of India under its Cybersecurity and Cyber Resilience Framework. Insurers report to the Insurance Regulatory and Development Authority of India under its applicable directions. Each of these sectoral obligations runs in parallel, from the same point of detection, with its own form, channel, and timeline.

A bank experiencing a cyber incident that compromises customer personal data may therefore face concurrent obligations to CERT-In, to the Reserve Bank, and to the Data Protection Board, with notification to affected Data Principals on top. Notification to one regulator does not satisfy the obligations owed to the others; each expects direct reporting through its specified channel and format. The DPDP framework expressly preserves obligations imposed under other laws, with the consequence that the horizontal DPDP duty and the sectoral duties coexist and must each be independently satisfied.

The result, for entities in regulated sectors, is a multi-regulator reporting matrix in which a single incident must be triaged against four or more distinct legal standards within the first hours of detection. The design of incident response for such entities cannot proceed regime by regime; it must begin from a unified assessment that maps the incident simultaneously against every applicable obligation.

VI. Contractual Allocation Across the Processing Chain

The breach-notification obligations sit at the level of the Data Fiduciary and the covered entity, but the events that trigger them frequently originate, or are first detected, within the systems of processors, cloud providers, and other vendors. The compressed timelines make the contractual allocation of detection-and-notification duties across the processing chain a decisive element of compliance.

The core difficulty is temporal. A Data Fiduciary's seventy-two-hour clock, and a covered entity's six-hour clock, run from the point at which the entity becomes aware of the breach. Where the breach occurs within a processor's environment, the Data Fiduciary's awareness is contingent on the processor's notification. If the processor's contractual obligation is to notify the Data Fiduciary within a period that itself approaches or exceeds the Data Fiduciary's regulatory deadline, the Data Fiduciary is placed in an impossible position. Processor contracts must therefore require notification to the Data Fiduciary on a timeline materially shorter than the regulatory deadline, so as to preserve a workable margin for the Data Fiduciary's own assessment and reporting.

Several contractual provisions warrant specific attention. Notification timelines imposed on the processor should be expressed in hours rather than days, and should be calibrated to leave the Data Fiduciary adequate margin against both the six-hour CERT-In window and the seventy-two-hour DPDP window. Information obligations should require the processor to furnish, with its notification, the categories of information the Data Fiduciary will need to populate its regulatory reports, including the nature and extent of the breach, the categories and approximate number of affected Data Principals, and the remedial measures taken. Cooperation obligations should require the processor to assist the Data Fiduciary in fulfilling its notification duties and to respond to regulatory information requests. Allocation of liability should address responsibility for penalties and losses arising from a processor-side breach or a processor's failure to notify in time, recognising that the Data Fiduciary's primary accountability to the Board cannot be contracted away but that indemnity may be structured between the parties.

Where the processing chain extends across multiple tiers, the difficulty compounds. A sub-processor's breach must propagate through the processor to the Data Fiduciary within a window that preserves the Data Fiduciary's ability to report on time. Back-to-back notification obligations through the chain, each tighter than the last, are necessary to make the regulatory timelines achievable, and the enforceability of these back-to-back obligations is a matter that should be addressed expressly rather than left to general contractual interpretation.

VII. Practical Recommendations

The structural features of the overlay translate into a set of operational and drafting priorities.

First, organisations should build a single point of detection feeding a unified triage. Because every applicable clock runs from the same moment of awareness, the determinative operational capability is the speed and accuracy of initial triage. An incident should, at the point of detection, be assessed simultaneously against the CERT-In categories, the DPDP breach definition, and any applicable sectoral obligation, so that all reporting workstreams begin in parallel rather than in sequence.

Second, organisations should pre-build reporting templates and decision trees for each regime. The six-hour CERT-In window does not permit the drafting of a report from a blank page; the prescribed format should be templated and ready to populate, with the reportable categories available as a structured selection. The DPDP Board report and Data Principal notification should likewise be templated against the Rule 7 content requirements.

Third, organisations should pre-designate decision rights and points of contact. The compressed timelines and the criminal character of CERT-In liability require that the authority to direct reporting, and the individuals responsible for effecting it, be identified in advance rather than determined during the incident. The CERT-In Directions require designation of a point of contact, and the DPDP framework requires a privacy point of contact or, for Significant Data Fiduciaries, a Data Protection Officer; these roles should be integrated into a single incident-response command structure.

Fourth, organisations should maintain the technical preconditions for compliance, including the NTP synchronisation and one-hundred-and-eighty-day India-stored logging mandated by the CERT-In Directions, and the data mapping required to identify affected Data Principals quickly under DPDP. Logging and data mapping are not merely security measures; they are the evidentiary and operational basis on which timely reporting depends.

Fifth, organisations should test the model through tabletop exercises. The viability of a two-clock, multi-regulator response cannot be assumed from the existence of a written plan; it must be demonstrated under simulated time pressure, with the detection-to-report interval measured and the decision rights exercised, so that the gaps are found in exercise rather than in incident.

VIII. Conclusion

The CERT-In Directions and the DPDP breach-notification regime address a single class of event, the security incident affecting personal data, from two distinct legal vantage points, and they impose obligations that diverge in trigger, timeline, threshold, recipient, and penalty. They are independent and cumulative: neither discharges the other, and for regulated entities both sit atop a further layer of sectoral reporting duties. The compressed timelines, measured from a common point of awareness, make the speed of initial triage and the quality of advance preparation the determinants of whether an organisation reports on time or in default.

The DPDP breach obligations are imminent rather than presently in force, and the period before their commencement is the window in which the unified detection, triage, and reporting capability, and the supporting processor contracts, must be built. Organisations that approach breach reporting as a single workflow, or that defer preparation until the obligations bind, will find that the first incident exposes the inadequacy of their response. Those that build a two-clock-aware response now, and allocate detection-and-notification duties across the processing chain by contract, will be positioned to satisfy both regimes from a single point of detection. In a framework where the clocks run continuously and the penalties span the civil and the criminal, that preparation is not a refinement but a precondition.

This article is provided for general information and does not constitute legal advice. Organisations should obtain advice tailored to their specific circumstances, sectoral status, and processing arrangements.