One Incident, Many Clocks: A Breach-Notification Framework

Executive summary

A single ransomware night can oblige an Indian business to report to several recipients, each with its own deadline counted from a different moment. The Digital Personal Data Protection Act, 2023 (the DPDP Act) adds two audiences from 13 May 2027: the Data Protection Board of India (the Board) and every affected individual. This paper sets out one framework for all of them.

Five points matter most.

• The DPDP trigger is wide and has no threshold. A personal data breach includes accidental disclosure and "loss of access", not only theft. Rule 7 of the DPDP Rules, 2025 requires notice to each affected person and to the Board, however few people are involved. The only filter sits in the definition: the event must compromise the confidentiality, integrity or availability of personal data.
• Six hours is the norm; 72 hours is the outlier. CERT-In, the RBI, SEBI and DoT expect a first report within six hours. The DPDP Rules ask for intimation "without delay" and a detailed Board report within 72 hours.
• The clocks start at different moments. CERT-In counts from noticing, the RBI from detection, including detection by a bank's or NBFC's IT service provider, and the DPDP Rules from the fiduciary becoming aware. Contracts must define detection.
• Nothing in the DPDP Act lets the police pause the clock. In our view a short, documented deferral of individual notices at an investigator's written request is defensible; delaying the Board's intimation is not.
• Paying a ransom does not end the duty to notify. We have found no Indian statute that expressly bars payment, but the data has still been compromised.

Background

India has no single breach law. Reporting duties grew regulator by regulator: CERT-In's Directions of April 2022 across the economy, cyber directions from the RBI, SEBI's framework for securities markets and DoT's Telecom Cyber Security Rules of 2024. Each protects systems and markets. None generally requires a business to tell the people whose data was exposed.

The DPDP Act changes the audience. Section 8(6) and Rule 7 commence on 13 May 2027 with most of the Act. MeitY consulted in January 2026 on bringing that date forward; no notification had issued as of October 2026. Until then, CERT-In and the sector rules govern reporting, and s.43A of the Information Technology Act, 2000 (IT Act) governs compensation for negligent security until s.44(2) of the DPDP Act omits it.

Two gaps remain. A Lok Sabha answer of 12 August 2026 reported no appointments to the Board, and we have found no published form or channel for Rule 7 intimations. Playbooks should be built now, with the Board's channel added when it appears.

Trayambic's industry impact studies cover each sector's clocks, from banks and NBFCs to telecom, energy and cybersecurity providers. This paper is about running them together.

Legal framework

The DPDP Act and Rules

A data fiduciary decides why and how personal data is processed; a data processor processes it on the fiduciary's behalf; a data principal is the individual the data is about. Section 2(u) defines a personal data breach as:

"any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data"

• Security (s.8(5); Rule 6). Reasonable safeguards to prevent a breach, including for processing by processors. Rule 6 requires logs and monitoring able to detect unauthorised access, kept for at least a year.
• Intimation (s.8(6)). The fiduciary must give "the Board and each affected Data Principal" intimation of a breach in the prescribed form and manner.
• Individuals (Rule 7(1)). On becoming aware of a breach, the fiduciary informs each affected person, to the best of its knowledge, concisely, clearly and plainly, without delay, through her user account or any contact mode registered with it.
• The Board (Rule 7(2)). Without delay, a description of the breach covering its nature, extent, timing, location and likely impact. Then, within 72 hours of becoming aware, or a longer period the Board allows on a written request, a detailed report: updated facts, the circumstances and reasons, mitigation, any findings about the person who caused it, remedial measures to prevent recurrence, and a report on the intimations sent to individuals.
• The Board's powers (s.27(1)(a)). On receiving an intimation, the Board may direct urgent remedial or mitigation measures and inquire into the breach.
• Penalties. The Schedule sets maximums by obligation: up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to notify the Board or affected individuals.

Rule 7 contains no materiality threshold, no exception for small incidents and no provision for delay at the request of law enforcement. Section 38(1) makes the Act additional to other laws, so none of the regimes below displaces it.

CERT-In

CERT-In's Directions No. 20(3)/2022-CERT-In of 28 April 2022 bind service providers, intermediaries, data centres, body corporates and government organisations. They must report the incident types in Annexure I within six hours of noticing them or being told of them, name a point of contact, and keep ICT system logs for a rolling 180 days within India. Annexure I lists 20 types, among them unauthorised access to IT systems or data, ransomware and other malicious code, phishing, attacks on cloud systems and, as separate items, "Data Breach" and "Data Leak". Non-compliance can be punished under s.70B(7) of the IT Act.

CERT-In's FAQs of May 2022 add four working rules. Any entity that notices an incident must report it, and cannot pass the duty on (Q13). The duty overrides contractual confidentiality (Q22). The six hours run from noticing or being told, not from when the incident occurred (Q24). And the first report may carry only what is known, with more sent later "within reasonable time" (Q30).

Sector regulators: the master clock

IRDAI's 2023 Information and Cyber Security Guidelines require insurers to follow CERT-In's directions on reporting (para 1.10); a 2025 IRDAI direction reportedly adds six-hour reporting to IRDAI itself. The Central Electricity Authority (Cyber Security in Power Sector) Regulations, 2026 were reported as notified in mid-2026, to apply from 1 April 2027 with six-hour incident reporting; we could not reach the official text.

Analysis

What makes an event a breach

Section 2(u) has three features that decide most cases.

1. 1.Two limbs. "Unauthorised processing" covers deliberate wrongs: an attacker, an employee browsing records without need, a vendor using data for its own ends. The accidental limb covers mistakes: a report e-mailed to the wrong person, a storage bucket left public, a database deleted without a backup.
2. 2.Availability counts. "Loss of access" that compromises availability is a breach even if nothing leaves the building. Ransomware that only encrypts is a personal data breach; so is a failed migration that leaves records unrecoverable.
3. 3.The compromise test is the only filter. Because Rule 7 has no threshold, the question is whether confidentiality, integrity or availability was actually compromised. In our view a lost laptop with full-disk encryption, a strong key kept separately and a current backup compromises none of the three and need not be notified, though the reasoning should be recorded. The same laptop unencrypted must be notified even if it held one person's data.

The regimes overlap but do not coincide.

Who notifies, and who only informs

Only the fiduciary owes Rule 7 notices. A processor's obligations reach it through its contract (s.8(2)), while s.8(1) keeps the fiduciary answerable for the processor's failures. The contract must therefore fix the processor's notice time in hours and the facts it supplies for the 72-hour report.

CERT-In works differently: any entity that notices an incident reports it, so a processor and its client may both file, and their facts should match. Trayambic's cybersecurity study covers this for managed security providers. Where two fiduciaries hold the same people's data, each owes notice for its own data. In our view one coordinated message can serve both if it carries each fiduciary's Rule 7(1) content and contact.

When does each clock start?

The instruments use different words: "noticing" (CERT-In), "detection" (RBI), "detection by the service provider" (RBI outsourcing) and "becoming aware" (DoT and DPDP). Four internal states, each timestamped, make them workable.

1. 1.Alert: an unexplained signal. No clock runs.
2. 2.Incident: an analyst confirms a security event. CERT-In's and the RBI's six hours start.
3. 3.Breach: personal data is affected, or reasonably likely to be. The DPDP clock starts.
4. 4.Scoped: the people and data fields are known. Individual notices can go.

In our view "becoming aware" under Rule 7 means a reasonable degree of certainty that personal data has been compromised: later than the first alert, but well before forensics end. A business that delays triage to delay awareness should expect the Board to count from when it ought to have known. In ransomware cases states 2 and 3 usually coincide, because encryption is itself a loss of access.

What the individual notice must say

Rule 7(1) prescribes five contents: what happened (nature, extent and timing), the consequences likely for her, the mitigation done or under way, the safety measures she can take, and a contact who can answer her questions. Four drafting rules follow.

• Make the consequences specific to the data. A leaked PAN invites loans taken in her name; a leaked test result invites embarrassment or discrimination; leaked passwords invite account takeover.
• Make the safety steps concrete. Change this password; expect no call from us asking for an OTP; check your free annual credit report from a credit bureau.
• Use the registered channel and no links. Rule 7 points to the user account or registered contact. Attackers send fake breach notices too, so the notice should never ask for credentials.
• Mind the notice itself. A text message about a psychiatric unit can disclose a diagnosis to whoever reads the phone; Trayambic's hospitals study discusses routing such notices through the treating team. The contact named should be the same person published under Rule 9, which Trayambic's blog on DPOs and contact persons explains.

Police, investigations and holds

Section 17(1)(c) disapplies most of Chapter II for processing "in the interest of prevention, detection, investigation or prosecution of any offence". It covers sharing logs and forensic images with investigators and keeping evidence past its normal erasure date; ss.8(1) and 8(5) still apply. Trayambic's cybersecurity study explains why private investigators can rely on it.

In our view it does not switch off s.8(6) for the breached data. That data was processed to run the business, not to investigate an offence, and the duty to notify attaches to it.

Nor does the Act have a law-enforcement delay clause. The GDPR's Recital 88 says notification rules should take into account "the legitimate interests of law-enforcement authorities where early disclosure could unnecessarily hamper the investigation"; the DPDP Act and Rules say nothing similar. Our view on a police request to hold notices:

1. 1.Never delay the Board. Its intimation is not public and cannot alert the attackers. Tell the Board about the request in that intimation.
2. 2.Get the request in writing, from the investigating officer, with its reason and length. An oral or open-ended request is not enough.
3. 3.Defer individual notices only briefly. "Without delay" demands promptness, not instant notice. A deferral of a day or two for a stated investigative reason is, in our view, defensible if the Board knows and the 72-hour report explains it.
4. 4.Do not defer where harm is immediate. If passwords or payment data are already circulating, people must be told. A real conflict can be put to the Board, which can direct measures under s.27(1)(a).

Evidence holds are simpler. Section 8(7) yields where retention is necessary for compliance with law, and s.17(1)(c) covers preservation for an investigation. The hold should end, and normal erasure resume, when the case closes.

Paying a ransom

We have found no Indian statute that expressly prohibits a victim from paying. Three points still apply.

• Payment changes nothing under Rule 7. The data was encrypted or copied; a promise to delete cannot be verified. In our view the payment belongs in the 72-hour report as part of the mitigation facts.
• US sanctions can reach Indian payers. The US Treasury's Office of Foreign Assets Control (OFAC) advisory of 21 September 2021 says civil penalties apply on strict liability, that a non-US person who causes a US person to violate is also caught, and that the US government "strongly discourages" payment; prompt reporting to law enforcement is a significant mitigating factor. A US parent, insurer, negotiator or bank in the chain brings this into play.
• It is a board decision. Record the options, legal advice, sanctions checks and police complaint.

Keeping a breach register

The DPDP Act does not expressly require a breach register. Several provisions make one necessary in practice: the 72-hour report needs dated facts, s.36 lets the Central Government call for information from any fiduciary, the Board can inquire under s.27, and Rule 6 and CERT-In require logs. A register should record, for each event: when it was noticed and by whom; systems and data categories; the s.2(u) assessment; every clock triggered and when each report went; regulators' acknowledgement numbers; notices sent, by channel and count; any law-enforcement request; root cause; and closure. It should also record events judged not to be breaches, with reasons, because that is the only evidence for the compromise test.

The 72-hour playbook

Worked example: ransomware at a diagnostics lab with financed patients

Facts are illustrative. A diagnostics company in a tier-2 city runs a central laboratory, 25 collection centres and a home-collection app, with about four lakh patients. For costly tests it offers instalments through a partner NBFC. Its front desks act as the NBFC's lending service provider and upload applications to the NBFC's portal, but staff also save PAN cards and sanction letters on the lab's billing server.

At 02:30 on a Saturday in June 2027, the on-call engineer confirms ransomware. The laboratory information system and the billing server are encrypted, and a note claims 300 GB was copied.

The clocks. Encryption is itself loss of access, so the lab's CERT-In and DPDP clocks start together at 02:30. It owes CERT-In by 08:30 and the Board a detailed report by 02:30 on Tuesday. For the loan files the NBFC is the fiduciary and the lab its processor. The lab's contract requires a call within two hours. In our view loan sourcing is an outsourced financial service, so para 28 of the NBFC outsourcing directions requires the NBFC to notify the RBI "immediately"; it files on DAKSH that morning. Having been told, the NBFC also sends CERT-In a short report citing the lab's.

Saturday. The lab files with CERT-In at 07:40, with partial facts. It files a police complaint in the afternoon; the investigating officer asks for a week's silence while the attackers' wallet is traced. The lab asks for the request in writing and receives it by e-mail. That evening it intimates the Board, mentioning the request, and agrees with the officer to hold patient notices for 48 hours.

Sunday. Forensics show the billing share was copied: about 38,000 patients' names, phone numbers, test names and results, and 2,100 instalment files with PAN and bank details. The laboratory system is restored from backups. When the attackers post 1,200 reports as a "sample", the lab notifies those patients at once, because the harm is no longer hypothetical.

Monday. Notices go by SMS and in the app to registered numbers. Sensitive results are handled by phone through referring doctors. Borrowers receive one joint notice from the lab and the NBFC, warning of loan fraud using their PAN and suggesting a credit report check.

The ransom. The board declines to pay: backups worked, deletion could not be verified, and the cyber insurer, part of a US group, would have required sanctions checks first.

Tuesday, 02:00. The 72-hour report goes to the Board: facts, cause (an unpatched remote-access appliance), mitigation, what is known about the attackers, remediation and a report on notices, including the 48-hour deferral and why.

Lessons. The billing share held PAN copies the lab did not need, and more than a lending service provider should keep (Trayambic's NBFC study covers the RBI limits). And without a map linking patients to systems, scoping took a day longer than it should have.

Compliance framework

Phased roadmap

• Now to December 2026: define incident states; list every applicable clock and channel; check CERT-In logs and points of contact. Watch for any notification bringing the DPDP dates forward.
• January to March 2027: amend processor and partner contracts; build the people-to-systems map; draft notice templates.
• April to 13 May 2027: Board templates, police and ransom protocol, register and a full tabletop exercise.
• From 13 May 2027: run Rule 7 alongside the existing clocks; add the Board's channel when published; review after every incident.

Recommendations

1. 1.Timestamp four states (alert, incident, breach, scoped) and drive every clock from that one timeline.
2. 2.Treat encryption by ransomware as a personal data breach from the moment it is confirmed.
3. 3.Write "detection" and notice times into every processor and partner contract.
4. 4.Use the compromise test honestly, and record every decision that an event was not a breach.
5. 5.Never delay the Board; defer individual notices only on a written, short and stated request.
6. 6.Map people to systems now, because scoping, not drafting, is what makes notices late.
7. 7.Keep a breach register that would satisfy an inquiry, not just an auditor.

Key takeaways

• A personal data breach under s.2(u) includes accidental disclosure and loss of access, so ransomware that only encrypts is notifiable; Rule 7 has no risk threshold.
• From 13 May 2027 each affected person and the Board must be told without delay, with a detailed Board report within 72 hours, on top of six-hour CERT-In and sector reports.
• CERT-In counts from noticing, the RBI from detection (including by an IT service provider), and the DPDP Rules from becoming aware: define each state and timestamp it.
• The DPDP Act has no law-enforcement delay clause; in our view never delay the Board, and defer individual notices only briefly on a written request.
• We have found no Indian law that expressly bars paying a ransom, but payment changes no notice duty and can raise US sanctions risk.