A personal data breach in India starts obligations under both the DPDP Rules and CERT-In's 2022 Directions — on different clocks, to different recipients, in different formats. Consiva tracks CERT-In's six-hour window independently of your DPDP Rule 7 obligations and pre-drafts a submission for each.
Most DPDP conversations are about consent, and most DPDP deadlines are in 2027. Breach is the exception on both counts.
CERT-In's Directions of April 2022 are already in force. They require reporting specified cybersecurity incidents within six hours of noticing them. That obligation exists today, independently of DPDP, and has for four years.
The DPDP breach obligations commence with Rule 7 on 13 May 2027. That is not a reason to wait. Breach response is the one privacy control you cannot build during the incident. Whatever is not designed, assigned and rehearsed beforehand does not happen at 07:42 on a Saturday.
So the honest framing: you have a live six-hour obligation now, and a structured multi-part obligation arriving in May 2027 that you should build against while there is no penalty exposure for getting the rehearsal wrong.
Nearly every platform in this market markets “72-hour breach notification”. Rule 7 contains three separate obligations, and seventy-two hours is the loosest of them.
| # | Obligation | Timing | To whom |
|---|---|---|---|
| 1 | Rule 7(1) — Intimate the breach in concise, clear and plain language, through her user account or a registered channel, covering: a description including nature, extent and timing; the consequences relevant to her; mitigation measures implemented and being implemented; the safety measures she may take; and the business contact information of a person able to respond to her queries. | Without delay | Each affected Data Principal |
| 2 | Rule 7(2)(a) — Intimate a description of the breach including its nature, extent, timing and location of occurrence, and the likely impact. | Without delay | The Data Protection Board |
| 3 | Rule 7(2)(b) — Provide the detail: updated and detailed description; the broad facts, circumstances and reasons leading to the breach; mitigation implemented or proposed; any findings regarding the person who caused it; remedial measures to prevent recurrence; and a report on the intimations given to affected Data Principals. | Within 72 hours of becoming aware, or a longer period the Board allows on written request | The Data Protection Board |
Three things follow that most vendors do not mention:
The tightest clock runs to the individual, not the regulator. Rule 7(1) is “without delay” and it is owed to every affected Data Principal. A platform built around a single 72-hour Board deadline has designed for the least urgent of the three obligations.
There are two Board intimations, not one. An immediate description under 7(2)(a) and a detailed follow-up under 7(2)(b). They are separate filings with different content.
The 72-hour filing must report on the individual notifications. Rule 7(2)(b)(vi) requires a report on the intimations given to affected Data Principals. If you did not notify individuals promptly under 7(1), the 72-hour filing is where that becomes visible to the Board in your own words.
CERT-In's obligation is not a DPDP obligation and does not run on DPDP's timing. Different statute, different recipient, different format, different clock — six hours, in force now.
One incident can therefore trigger both regimes simultaneously. Handling them as one workflow with one deadline is how organisations miss the shorter obligation while feeling on top of the longer one.
Also relevant: Rule 6 sets the minimum reasonable security safeguards a Data Fiduciary must have in place — including encryption, obfuscation, masking or tokenisation; access controls; logs, monitoring and review to enable detection of unauthorised access, its investigation and remediation; measures for continued processing such as backups; and retention of those logs and personal data for one year to enable that detection and investigation. You cannot report an incident you have no logs to detect, which is why Rule 6(1)(c) and (e) are effectively breach-response prerequisites.
Stated precisely, because this is a page about clocks and vagueness would be self-defeating — shown as a workflow before the detail below.
Available on: Pro (breach tracker) and Enterprise (full module with playbooks and notification workflows).
This is an open incident. Two countdowns run at the top and they are deliberately separate: CERT-In's six-hour window on the left, the DPDP Rule 7(2)(b) seventy-two-hour window on the right. They are not the same obligation and a single combined timer would hide the shorter one. Below, the incident record: what happened, the vector, how many records are affected, and containment status. Further down, the two drafts — a CERT-In report pre-filled and ready to submit at cert-in.org.in, and a Board notification queued for review. Consiva drafts; you submit. Every state change on this screen is timestamped into the incident file, including the moment the clocks started, which is the fact the whole record turns on.
Per incident: the time you became aware, which is the fact every clock and every filing depends on · the clock history for both windows · classification and affected-record count · containment actions with timestamps and actors · each regulatory filing as drafted and as sent · a record of intimations to affected Data Principals, with recipients and dispatch times · the escalation trail.
For the Rule 7(2)(b) filing specifically: the file assembles what that rule requires — updated description, broad facts and reasons, mitigation implemented or proposed, findings on the person who caused the breach, remedial measures, and the report on intimations to Data Principals. Assembled from the record rather than written from memory three days later.
Log retention. Rule 6(1)(e) requires logs and personal data to be retained for one year to enable detection, investigation, remediation and continued processing, unless another law requires otherwise. Incident records are retained accordingly.
A fintech notices anomalous access to an internal API at 09:14 on a Saturday. Approximately 2,400 customer records — email addresses and phone numbers — were exposed through a misconfigured endpoint.
Without a rehearsed process, the sequence is familiar: the on-call engineer contains the endpoint by 10:30, tells his manager, and the privacy team hears about it on Monday. The CERT-In six-hour window closed at 15:14 on Saturday. Nobody started a clock because nobody knew a clock existed.
With breach management in place, the engineer logs the incident at 09:20 with the awareness time. Both clocks start. The DPO and CISO are paged. The CERT-In report is pre-drafted from the incident record and submitted at 12:40, well inside six hours. Containment is confirmed and timestamped. The affected-principal intimation is assembled against Rule 7(1)'s five required elements and dispatched. Over the following two days the technical investigation feeds the Rule 7(2)(b) filing, which is submitted with a factual report of the intimations already given.
The difference is not the tooling. It is that a clock started at 09:20.
Illustrative. Not based on a named Consiva customer.
Breach response is the hardest privacy function to staff, because it is idle most of the time and then requires senior judgement in the first hour. Two engagements fit.
Managed Privacy Officer — Consiva operates the regulatory side of the response: assembling filings, coordinating the intimation to affected individuals, and maintaining the incident record. Your security team owns detection and containment.
Breach readiness engagement — before anything happens: designing the escalation path, assigning owners, populating the templates against your systems, and running a tabletop exercise so the first real incident is not the first time anyone has done this.
Your team retains all decision authority, including whether and when to file. Consiva does not submit to a regulator on your behalf.
Software that manages the regulatory response to a personal data breach: recording when you became aware, tracking each applicable notification clock, assembling the filings each regulator requires, managing the intimation to affected individuals, and keeping an incident record that can be produced afterwards. It is distinct from detection tooling — a SIEM or EDR tells you an incident happened; breach management software handles what you are then obliged to do about it.
There is no single timeline, which is the most common misunderstanding in this market. Rule 7 sets three obligations: intimate each affected Data Principal without delay under Rule 7(1); intimate the Board without delay with a description including nature, extent, timing, location and likely impact under Rule 7(2)(a); and file a detailed follow-up with the Board within seventy-two hours under Rule 7(2)(b), extendable on written request. Seventy-two hours is the loosest of the three, and it is the only one most platforms mention. Rule 7 commences on 13 May 2027.
CERT-In's Directions of April 2022 require reporting specified cybersecurity incidents within six hours of noticing them. It is a separate regime from DPDP — different statute, different recipient, different format, different clock — and it is already in force, whereas the DPDP breach obligations commence on 13 May 2027. One incident can trigger both. Consiva tracks the two independently rather than combining them into a single timer, because a combined timer hides the shorter obligation.
Sequencing depends on the facts and is a decision for your legal and privacy leads, not for software. What the rules make clear: CERT-In's window is six hours and is in force now; Rule 7(1) intimation to each affected Data Principal is "without delay" and is the tightest DPDP obligation; and the immediate Board description under Rule 7(2)(a) is also "without delay". The seventy-two-hour Board filing under Rule 7(2)(b) is the follow-up, not the first step. Design the sequence before an incident, not during one.
It starts a clock at the moment of awareness and does not lose it. It holds the content each rule requires so filings are assembled rather than composed under pressure. It escalates before a deadline rather than after. And it produces an incident record showing when you knew, what you did, and what you filed — which is the evidence that distinguishes a well-handled incident from a badly handled one, largely independent of how severe the breach itself was.
The Schedule to the Act sets the tiers. Breach of the Section 8(5) obligation to take reasonable security safeguards may extend to ₹250 crore. Breach of the Section 8(6) obligation to give the Board or affected Data Principals notice of a breach may extend to ₹200 crore. Two points that are usually omitted: the amounts are ceilings ("may extend to"), and a penalty can only be imposed where the Board determines after an inquiry that the breach is significant, and after giving an opportunity of being heard.
No. Consiva is not a SIEM, EDR or monitoring platform and will not tell you an incident has occurred. It manages the regulatory response once you know. Note that Rule 6(1)(c) requires visibility on the accessing of personal data through appropriate logs, monitoring and review to enable detection — so if detection is your gap, that is a genuine gap and a different purchase.
A tabletop walkthrough of your escalation path, owners and templates — before the first real incident.