DPDP Breach Notification: 72-Hour CERT-In + DPB Playbook

The DPDP Rules 2025, read with the CERT-In Directions of 28 April 2022, put every Indian Data Fiduciary on two simultaneous clocks the moment a personal data breach is confirmed: a 6-hour notification to CERT-In and a 72-hour intimation to the Data Protection Board (DPB) plus affected Data Principals. CERT-In's empanelled responder pool already absorbed over 15 lakh reported incidents in 2023, and the 2025 Rules finally operationalised Section 8(6) of the DPDP Act, 2023.

The problem is that most Indian incident-response runbooks were written for a single regulator and a softer clock. At hour two of a real breach, the security team is still triaging while legal asks for "a quick review window" that does not exist. Miss either clock and you are looking at a penalty of up to Rs 250 crore plus the regulator-led narrative that fills your silence.

This post is the hour-by-hour playbook your team needs before breach day. You will get the RACI, the evidence rules, the submission templates and the failure patterns we have seen across three SaaS incidents in 2024-25, so your team executes instead of improvising.

Indian incident response now answers to two regulators with overlapping, non-identical clocks. CERT-In, acting under Section 70B of the IT Act and its 28 April 2022 Directions, requires reporting of 20 categories of cyber incidents (data breaches, ransomware, unauthorised access to PII) within 6 hours of noticing. The reporting goes to [email protected] or the helpdesk portal in the prescribed format. The duty binds every "service provider, intermediary, data centre, body corporate and Government organisation" in India.

The DPDP Rules 2025, layered on top of Section 8(6) of the DPDP Act, require the Data Fiduciary to notify each affected Data Principal "without delay" and to intimate the Data Protection Board, with the detailed report (root cause, mitigations, identity of those responsible if known) submitted within 72 hours. The Board can extend on written request. The 72-hour clock starts from "becoming aware" of the breach, which mirrors GDPR Article 33 but adds a stricter Data Principal disclosure duty.

The two clocks do not start at the same moment in practice. CERT-In counts from when the security team "notices" the incident, typically the SOC alert or first credible IOC. The DPB clock counts from when the Data Fiduciary "becomes aware" that personal data is involved, which is usually several hours later after triage. If your runbook conflates the two, the 6-hour CERT-In window expires before the breach is even classified as personal.

In every retainer engagement, we treat the CERT-In clock as the binding outer constraint and back-plan from there. Everything downstream, including the DPB intimation, gets staged around hitting T+6.

Section 2(i) of the DPDP Act 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." The 2025 Rules clarify that this is a strict-liability trigger. There is no materiality threshold, no "risk of harm" carve-out and no minimum record count. A single misconfigured S3 bucket exposing one Data Principal's PAN counts.

This is materially broader than GDPR's "risk to rights and freedoms" gate and broader than US state breach laws, which typically require unencrypted PII plus a harm threshold.

In Indian SaaS and BFSI engagements, three categories cover roughly 90% of what triggers the dual clock: Confidentiality breaches - credential stuffing, IDOR exposing other tenants' records, leaked API keys, exposed backups. Most CERT-In-reported incidents in our 2024-25 engagements fell here. Integrity breaches - unauthorised modification of KYC records, tampered audit logs, ransomware encryption-with-exfiltration (treated as both an availability and confidentiality breach). Availability breaches - destructive ransomware, accidental deletion of production PII, loss of cryptographic keys rendering data unrecoverable. The DPB treats prolonged unavailability of Data Principal data as a notifiable breach.

The breach is notifiable whether the data was encrypted or not. Encryption is a mitigating factor the Board may consider when assessing penalty under the DPDP Schedule, but it does not switch off the notification duty. This is a deliberate departure from the HIPAA Safe Harbor approach under 45 CFR Section 164.402, and Indian DPOs migrating from US frameworks get it wrong on first reading.

Below is the operational timeline we deploy in DPDP incident-readiness retainers. Every cell has a named owner before breach day. Improvising the RACI at hour two is the single most common reason teams miss the 6-hour mark.

Two patterns drive failure here. First, the IR team escalates to legal at T+3 hours expecting a "review window" that, by then, is one hour. Pre-approved submission templates with the General Counsel's standing sign-off compress that window. Second, organisations treat T+72 as a hard ceiling rather than a target. Set internal SLAs of T+4 hours to CERT-In and T+48 hours to the DPB so the buffer absorbs regulator clarification requests.

The DPDP Rules 2025 prescribe distinct content for the two audiences. The Data Principal notice under Rule 7 must be in plain language and contain: (a) a description of the breach including nature and extent, (b) timing and location of occurrence, (c) likely consequences relevant to that Data Principal, (d) measures implemented to mitigate risk, (e) safety measures the Data Principal should take, and (f) contact details of a person who can answer questions. It must be delivered through the same channel the Data Principal normally uses to interact with the Fiduciary. A buried banner on a status page does not satisfy the rule.

The DPB intimation requires materially more detail: facts and circumstances including the nature of personal data involved and the number of Data Principals affected; mitigation measures taken or proposed; findings on the cause; remedial measures to prevent recurrence; and a report on the intimations sent to Data Principals. The 72-hour intimation is followed by an updated detailed report once forensics conclude, typically 30 to 90 days later, depending on Board engagement.

Every claim in the DPB intimation must be traceable to a forensic artefact. Statements like "no exfiltration occurred" without DNS logs, egress NetFlow or EDR telemetry to support them get challenged. The discipline matters because the Board's Investigation Officers under Rule 22 have powers under Section 28 of the DPDP Act to summon evidence. Your initial report sets the credibility tone for the entire enforcement interaction. If your hour-72 submission overclaims and your hour-720 report walks it back, you are now arguing about candour, not technique.

The faster you reimage and restore, the more evidence you destroy. We see this trade-off mishandled in roughly half of Indian SaaS incidents. The CERT-In Directions explicitly require log retention for 180 days (Direction iv), and these logs are the first artefacts the Board's Investigation Officer requests. Wiping a compromised EC2 instance before disk imaging is a common, costly mistake.

The minimum evidence-preservation set we lock down inside the first hour: Volatile memory capture from affected hosts using a CERT-In-acceptable tool chain (Belkasoft RAM Capturer, FTK Imager Lite or Volatility-compatible dumpers). Memory contains ransomware decryption keys, lateral-movement evidence and credential traces that are gone on reboot. Full disk images of affected systems, hashed (SHA-256), stored on write-once media with documented chain of custody. This maps to ISO 27001:2022 Annex A.5.28 (collection of evidence) and SOC 2 CC7.3. 180-day log preservation of authentication, application, network flow, WAF and DNS logs as required by CERT-In Direction iv. Move them to immutable storage immediately; attackers often reach log infrastructure before defenders do. Cloud control-plane audit logs - AWS CloudTrail, Azure Activity Logs, GCP Audit Logs. The 90-day default retention sits below the CERT-In threshold; extend to 400+ days during the response.

Where you genuinely cannot preserve before remediating, for example a live ransomware encryption event, document the decision in the incident log with the named approver. The DPB has discretion under Section 33(2) to weigh "reasonable" actions, but only against a contemporaneous record. Our forensic playbooks align with NIST SP 800-61 Rev. 3 and map every step to OWASP, CWE and MITRE ATT&CK technique IDs in the technical report we deliver to the client and the regulator.

Consider a mid-stage Indian SaaS company, a B2B HR platform with 8 lakh end-user records spanning Aadhaar masked numbers, PAN, salary data and bank account suffixes. The company is a Data Fiduciary under DPDP and likely a Significant Data Fiduciary (SDF) by volume under Rule 12. At 02:14 IST on a Saturday, the SOC detects anomalous read traffic on a tenant-isolated PostgreSQL replica.

T+0:14 (02:28 IST) - IDOR confirmed via WAF logs; one external IP enumerated 47,000 records over six hours before detection. Affected workload isolated from the load balancer. CISO paged. T+1:30 (03:44 IST) - DPO confirms personal data is in scope (PAN, salary, account suffix). Breach classified as confidentiality, category C-1. Legal counsel briefed under privilege; standing CERT-In template populated. T+4:10 (06:24 IST) - CERT-In Form A submitted to [email protected] with acknowledgement reference logged. The report names the asset, the vulnerability class (BOLA / IDOR per OWASP API Security Top 10, API1:2023), affected record count estimate, containment actions and the responsible engineering owner. T+22:00 (00:14 IST Sunday) - First-wave Data Principal notifications dispatched via in-app banner, email and SMS, with a dedicated breach-response microsite hosting the FAQ, customer support number and toll-free Board complaint information. T+62:00 (16:14 IST Monday) - DPB intimation submitted with forensic timeline, exfiltration scope confirmed via egress NetFlow, mitigations (patched controller, rotated 11,200 API keys, forced password reset for 8 lakh users), and a 30-day remediation plan including a retest of the affected API surface. The Board acknowledges within 48 hours and requests two clarifications, answered in writing the same day.

This is roughly the pattern we executed in three SaaS incidents in 2024-25. The companies that pre-staged the RACI, templates and Board contact channel stayed on the right side of both clocks. The one that did not, a fintech that escalated to its DPO five hours into the incident, missed the CERT-In window by 80 minutes and now has an active Section 28 inquiry on file.

The work that determines whether you hit T+6 is done before the breach. Five artefacts every Data Fiduciary should have signed off in advance.

Pre-approved CERT-In Form A template with fields auto-populating from the SIEM and standing legal sign-off, so the CISO can submit without a fresh privilege review at 04:00 IST. DPB intimation template in two versions - short-form for the 72-hour initial intimation and long-form for the post-forensics detailed report. Both should map findings to ISO 27001:2022 Annex A.5.24-A.5.28 and SOC 2 CC7.1 / CC7.3 / CC8.1 so the same artefact feeds your annual audit. Data Principal notification copy in English, Hindi and the top three regional languages by user concentration, pre-cleared by Legal and Communications. Channel routing logic (in-app, email, SMS, IVR) tested in non-prod. Named RACI covering SOC, IR, DPO, CISO, CEO, General Counsel, Communications and external counsel, with weekend and PTO backups documented. Test it via tabletop twice a year minimum. Evidence preservation runbook with memory-capture and disk-imaging procedures pre-installed on golden images, chain-of-custody forms and an immutable log archive with at least 400-day retention.

For SDFs designated under Rule 12, add an annual Data Protection Impact Assessment, an annual audit and a published DPO contact channel. These are independent obligations but they reuse the same evidentiary substrate.

The DPDP Rules 2025 closed the gap between policy and execution that Indian privacy compliance has lived in since 2011. Whether your team can execute against the 6-hour and 72-hour clocks is now a board-level question, not a DPO-level question. The penalty under the DPDP Schedule reaches Rs 200 crore per breach instance for notification failures and Rs 250 crore for broader compliance breakdowns, applied per breach rather than capped annually.

Three checks worth running this quarter. First, time your last incident from detection to a hypothetical CERT-In submission. If the answer is over four hours, your templates and approval chain are the bottleneck, not your SOC. Second, ask your DPO when the 72-hour clock started in your most recent privacy incident and whether the answer is documented. If it is not, you cannot defend the timing in front of the Board. Third, check whether your log retention spans the 180-day CERT-In floor on the day a regulator requests them, not the day you configured the retention policy.

If you need to pressure-test your runbook or build one from the templates above, our DPDP compliance team runs tabletop drills against live SOC telemetry and delivers a CERT-In-empanelled-quality response stack. The existing public DPDP commentary stays at the "what is the law" level. We operate at the breach-hour level. Talk to us before breach day arrives, because every artefact in this playbook takes four to six weeks to stand up, and the clock starts on a Saturday at 02:14 IST whether you are ready or not.