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

Under the DPDP Rules 2025 read with the CERT-In directions of 28 April 2022, every Data Fiduciary in India now runs two 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. This playbook gives you the hour-by-hour workflow, RACI, evidence rules and submission templates so your team executes — not improvises — on breach day.

The dual-clock problem is not theoretical. CERT-In's empanelled responder pool handled over 15 lakh reported incidents in 2023, and the DPDP Rules notified in early 2025 finally operationalised the notification duty under Section 8(6) of the DPDP Act, 2023. The cost of missing either clock is not just a fine of up to ₹250 crore — it is the regulator-led narrative that fills the silence.

Indian incident response now has two regulators with overlapping, non-identical clocks. CERT-In under Section 70B of the IT Act and its 28 April 2022 Directions requires reporting of 20 categories of cyber incidents — including data breaches, ransomware and unauthorised access to PII — within 6 hours of noticing. The reporting is to be done in the prescribed format to [email protected] or via the helpdesk portal, and applies to 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 "without delay" notify each affected Data Principal of the breach and to intimate the Data Protection Board, with the detailed report — root cause, mitigations, identity of those responsible if known — submitted within 72 hours (extendable on written request to the Board). The 72-hour clock starts from "becoming aware" of the breach, which mirrors GDPR Article 33 but with a stricter Indian Data Principal disclosure duty.

The two clocks do not start from 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 — typically several hours later, after triage. If your runbook conflates the two, your 6-hour CERT-In window often expires before the breach is even classified as personal. We treat the CERT-In clock as the binding outer constraint and back-plan everything from there.

The DPDP Act, Section 2(i), 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 the US state breach laws which typically require unencrypted PII plus a harm threshold. In practice, three categories cover 90% of what triggers the dual clock in Indian SaaS and BFSI engagements:

• 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.

Crucially, the breach is notifiable whether the data was encrypted or not. Encryption is a mitigating factor the Board may consider when assessing the penalty under Schedule of the DPDP Act, but it does not switch off the notification duty. This is a deliberate departure from the HIPAA "Safe Harbor" approach under 45 CFR §164.402, and Indian DPOs frequently get this 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 how organisations miss the 6-hour mark.

Clock	Action	Owner (R)	Accountable (A)
T+0 to T+30 min	SOC confirms IOC, opens P1 incident, isolates affected workload, preserves volatile memory	SOC Lead	CISO
T+30 to T+90 min	Triage: is personal data in scope? Classify category (confidentiality / integrity / availability). Notify DPO and Legal.	IR Lead	DPO
T+90 to T+240 min	Draft CERT-In Form A in the prescribed format. Approve through CISO + General Counsel.	IR Lead	CISO
T+4 to T+6 hours	Submit to CERT-In via [email protected] or portal. Log acknowledgement reference.	CISO	CEO
T+6 to T+24 hours	Stand up war room. Begin forensics under legal privilege. Draft Data Principal notice. Identify Board contact channel.	DPO	CEO
T+24 to T+48 hours	Confirm scope of affected Data Principals. Issue first-wave Data Principal notifications (email/SMS/in-app).	DPO	CEO
T+48 to T+72 hours	Submit DPB intimation with root cause, mitigations, contact of responsible person if known, and remediation timeline.	DPO	CEO

Two patterns drive failure here. First, the IR team escalates to legal at T+3 hours expecting a "review window" — by then you have one hour left to draft, approve and submit to CERT-In. 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 — we recommend internal SLAs of T+4 hours to CERT-In and T+48 hours to the DPB to absorb regulator clarification requests.

The DPDP Rules 2025 prescribe distinct content for the two audiences. The Data Principal notice under Rule 7 must be in clear plain language and contain: (a) description of the breach including its 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 — buried banners on a status page do not satisfy the rule.

The DPB intimation requires materially more detail: facts and circumstances of the breach, including the nature of the 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.

One discipline we enforce in incident response engagements: 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 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.

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 will request. Wiping a compromised EC2 instance before disk imaging is a common, costly mistake.

The minimum evidence preservation set we lock down within the first hour:

1. 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 the ransomware decryption keys, lateral movement evidence and credential traces that are gone on reboot.
2. Full disk images of affected systems, hashed (SHA-256), stored on write-once media with a documented chain of custody. This is mapped to ISO 27001:2022 Annex A.5.28 (collection of evidence) and SOC 2 CC7.3.
3. 180-day log preservation of authentication logs, application logs, network flow logs, WAF logs and DNS logs as required by CERT-In Direction iv. Move them to immutable storage immediately — attackers often reach log infrastructure before defenders do.
4. Cloud control-plane audit logs — AWS CloudTrail, Azure Activity Logs, GCP Audit Logs. The 90-day default retention is 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 the NIST SP 800-61 Rev. 3 guidance and map every step to OWASP, CWE and MITRE ATT&CK technique IDs in the technical report we deliver to the client and to the regulator.

Consider a mid-stage Indian SaaS company — say, 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. The CISO is 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 is briefed under privilege; the standing CERT-In template is populated.

T+4:10 (06:24 IST) — CERT-In Form A submitted to [email protected] with acknowledgement reference logged. The report names the asset, 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, the customer support number and the toll-free Board complaint information. Channel choice mirrors how the SaaS normally interacts with end users.

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, force 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, which are 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, ideally within the next quarter:

• 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 controls 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. We typically deliver this whole stack as a four-to-six week engagement, ending in a live tabletop drill against the client's actual SOC alerts. The output is a binder, a Confluence space and a measured T+6 capability — not a slide deck.

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. 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. Talk to us before the breach day arrives — every existing DPDP article stays at the "what is the law" level; we operate at the breach-hour level.