CERT-In Directions vs DPDP Breach Rules: Two Clocks, One Incident

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

One cyber incident in India can start two regulatory clocks at once. The CERT-In Directions of 28 April 2022 require listed cyber incidents to be reported within 6 hours of noticing, while the DPDP Act, 2023 and DPDP Rules, 2025 require a personal data breach to be notified to affected data principals and the Data Protection Board without delay, with a detailed Board report within 72 hours. The regimes differ in trigger, recipient, content and penalty, and RBI, SEBI or IRDAI add a third layer for regulated entities. This article gives one timeline, one classification matrix and one runbook structure so your team is not reconciling clocks at 2 a.m.

CERT-In Directions 2022 and DPDP breach rules: what each regime actually requires

CERT-In, under section 70B of the IT Act, protects Indian cyberspace as a whole. The DPDP Act protects individuals whose personal data is exposed. Treating them as one obligation is the most common mistake we see in incident plans.

The CERT-In clock

The CERT-In Directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporates and government organisations, and expressly include cloud and VPN providers. Listed cyber incidents (unauthorised access, ransomware and malware, data breaches and leaks, defacement, phishing, attacks on cloud and payment systems, among others) must be reported within 6 hours of noticing. ICT logs must be kept for 180 days within India, clocks synchronised to NIC or NPL NTP servers, and VPN, cloud and data centre providers must retain subscriber KYC for 5 years.

The clock runs from “noticing”, not confirmation: a ransomware note found at 03:10 starts the clock at 03:10. CERT-In accepts a partial initial report; it does not accept silence.

The DPDP clock

Section 8 of the DPDP Act requires every data fiduciary to intimate a personal data breach to the Board and to each affected data principal. The DPDP Rules, 2025 (notified November 2025) set the mechanics: notify affected principals and the Board without delay, and file a detailed report with the Board within 72 hours. The principal notice must be in plain language and cover nature and extent, likely consequences, mitigation, steps the individual can take and a contact. Failure to notify carries a penalty of up to Rs 200 crore under section 33 and the Schedule, separate from up to Rs 250 crore for failure of security safeguards; see our penalties Schedule explainer.

Breach notification becomes enforceable 18 months after the Rules were notified, i.e. May 2027, while CERT-In has been enforceable since June 2022. Until May 2027 the DPDP clock is a rehearsal, but one to run now, because logging and evidence habits take a year to bed in. See our enforcement phases article.

Side-by-side

CERT-In vs Data Protection Board notification: how the triggers diverge

The practical question is not “which regulator do we call” but “which clocks has this incident started”. Four combinations exist.

CERT-In only. A DDoS attack takes your website down; no personal data is accessed. Report to CERT-In within 6 hours and record why DPDP was not triggered.

DPDP only. An employee emails 4,000 customer records to the wrong external address. In our reading this is a personal data breach, and arguably a “data leak” on the CERT-In list. Report to CERT-In when in doubt: over-reporting has no penalty, under-reporting does.

Both. Ransomware encrypts a customer database and exfiltrates records. CERT-In within 6 hours, principals and Board without delay, detailed Board report within 72 hours. Build the runbook around this scenario.

Neither. An encrypted laptop is stolen and the key is not compromised. Document the assessment and close the ticket.

The regimes also diverge on audience. CERT-In wants technical indicators. DPDP requires you to speak to affected individuals in plain language, so customer support and legal must be in the room, not just the SOC. The rights those individuals can then exercise are set out in Your DPDP Rights.

India breach notification timeline: one clock from T+0 to T+72h and beyond

Merge the regimes into one timeline and drill it. Times are from first noticing.

In our reading “without delay” is shorter than 72 hours; the 72-hour window is for the detailed report. Plan for principals to hear from you within 24 to 48 hours (indicative) once you know who is affected. The CERT-In window does not pause for weekends, so the on-call roster must include someone authorised to send the report.

For the DPDP-specific detail on the 72-hour window, including draft notice wording, see our 72-hour breach response guide and the companion breach notification 72-hour plan on our blog.

Sector overlays: RBI, SEBI and IRDAI on top of CERT-In and DPDP

Regulated entities carry a third clock. RBI-supervised entities report cyber incidents to RBI within 6 hours under the RBI cyber security framework for banks and related directions, with further expectations under the RBI Digital Lending Guidelines and the Account Aggregator framework. Market intermediaries report under SEBI’s cyber security and cyber resilience framework. Insurers report under the IRDAI information and cyber security guidelines.

A regulated entity may therefore file three reports on one incident. Do not write three runbooks. Write one, with a sector annex listing the extra recipient, format and deadline. Our banking sector post covers the RBI overlay.

Incident classification matrix: three questions in the first hour

Classify every incident against three questions within the first hour.

Print the resulting code at the top of the incident record, for example “PD-Y / CI-Y / SEC-RBI”.

Two decision rules we apply in practice. First, “plausibly involved” starts the DPDP clock: if a server holding personal data was accessed and you cannot prove the data was untouched, treat it as involved. Second, processor incidents are your incidents. The fiduciary remains responsible regardless of the processor, so a breach at your payroll vendor or cloud host starts your clock when you become aware. Processor contracts must require notice within hours, not days; see our vendor remediation article.

A single runbook structure that satisfies both regimes

One document, six sections, reviewed quarterly.

1. Activation and roles. Who declares an incident, how the on-call reporter is reached at 03:00, and the RACI below.

2. Classification. The three-question matrix, with examples from your own CRM, HRMS and cloud tenancy rather than generic ones.

3. Reporting packs. Pre-filled templates for the CERT-In report, principal notice, Board intimation and 72-hour Board report, plus a sector annex. Pre-fill entity details and standard paragraphs so only incident specifics are typed under pressure.

4. Communications. Approved holding statements for customers, employees, media and the board; no external statement without legal and the incident commander signing.

5. Evidence and logging. What to preserve and where, with retention confirmed at 180 days for CERT-In and 1 year for DPDP.

6. Closure and learning. Root cause, remediation tracker, regulator follow-ups, insurance actions and a dated lessons-learned entry.

A word on Board mechanics. The exact form of the Rules notification, the Board’s portal and any acknowledgement process will be operationalised as the Board activates. Re-check them against our Data Protection Board explainer and the Act and Rules Explorer before relying on this page, and update your reporting packs when the Board publishes its formats.

RACI: who signs what during an Indian breach

Speed fails when signatures are ambiguous. Set the RACI before the incident.

Significant Data Fiduciaries must have a DPO in India under section 10, so for an SDF the Accountable role on DPDP deliverables belongs to the DPO. For everyone else, the section 8 grievance contact should sign principal notices. If you are unsure whether you are an SDF, the SDF Classifier in our tools gives a first view.

Evidence to preserve, and why the two regimes want different things

CERT-In wants indicators and attack chain. The Board wants to know what happened to personal data and how fast you acted. Preserve for both.

Technical evidence (CERT-In focus). Firewall, VPN, endpoint and identity logs for the affected window; disk and memory images taken before rebuild; malware hashes, attacker IPs and domains; NTP-synchronised timestamps.

Personal data evidence (DPDP focus). Inventory of records and fields exposed, mapped to the number of principals; access and query logs showing what was read or exported; copies of every principal notice with timestamps; Board submissions with proof of filing; the helpline log.

Decision evidence (both). A timestamped decision log recording when the incident was noticed, when each classification question was answered, who approved each report and why any report was not filed. In our experience regulators distinguish between organisations that acted imperfectly but visibly and those that cannot show what they did.

Retain all of it for at least one year under the DPDP Rules logging safeguard, and longer if litigation, insurance or a sector regulator requires.

Frequently Asked Questions

Does the CERT-In 6-hour rule apply to a small company with no security team?

Yes. The CERT-In Directions apply to all body corporates and service providers regardless of size, with no small business exemption. Designate one person with authority to send the initial report and keep the CERT-In form and contact details in the runbook. The report can be partial; the deadline cannot be missed.

If we report to CERT-In, have we satisfied the DPDP breach obligation?

No. CERT-In and the Data Protection Board are separate authorities with separate triggers and content requirements. A CERT-In report says nothing to affected individuals, who must be notified separately under section 8 and the DPDP Rules, 2025. Treat them as two filings on one timeline.

When does the DPDP 72-hour clock start?

The detailed report to the Board is due within 72 hours of the fiduciary becoming aware of the breach. In our reading awareness starts when someone in the organisation reasonably recognises a personal data breach, not when it is formally confirmed. The intimation to principals and the Board must be made without delay, which is earlier than the 72-hour report deadline.

Are DPDP breach penalties enforceable today?

Not yet. The breach notification duty becomes enforceable 18 months after the Rules were notified, i.e. May 2027. The CERT-In Directions have been enforceable since June 2022, so the 6-hour clock is live now. Build the DPDP process today so it is tested before penalties apply.

Do we notify principals before we know the full scope?

In practice, yes, once you know a group of principals is affected, even if the full list is still being built. The Rules require notification without delay, and notifying known principals first and updating as scope grows is more defensible than waiting for certainty. Record the basis for each stage in the decision log.

Related explainers

• DPDP Act vs IT Act SPDI Rules

• DPDP vs GDPR: key differences

Next step

Two clocks are manageable when the runbook, templates and RACI exist before the incident does. Download the breach runbook template, with the merged timeline, classification matrix and reporting packs, from our DPDP Starter Templates and adapt it this quarter.