Unified incident reporting across RBI, SEBI, IRDAI, CERT-In, and DPBI — a 2026 reference

ControlForge free guide · 2026-05-24 · Synthesis of multi-regulator incident reporting obligations for Indian regulated entities

Quick reference

The problem in one line: a single cyber incident at an Indian regulated entity processing personal data can trigger four to six parallel regulatory notifications with different timelines, formats, and authorities — and missing any one is independently penalty-exposing.
The reporting clocks (most common combinations):
CERT-In: 6 hours from detection (IT Act + Direction 70B, April 2022).
RBI: 2–6 hours initial via CIMS; 21-day detailed root-cause report (banks, NBFCs, payment system operators).
SEBI: structured incident reporting for capital markets entities under CSCRF.
IRDAI: incident reporting under the 2023 Guidelines, strengthened by the March 2025 cyber-incident-preparedness amendments.
DPBI (from 13 May 2027): initial notification "without delay"; detailed report within 72 hours for personal-data breaches.
Data Principals (from 13 May 2027): notification "without delay" where the breach materially affects them.
Audience: CISOs, Heads of Incident Response, Heads of Compliance, DPOs, General Counsel, Crisis-management leads.
The structural insight: build one unified incident response process that triggers parallel notification workflows — not separate siloed processes per regulator. Pre-staged templates, pre-identified authority contacts, tested orchestration are the difference between routine compliance and headline failure.
ControlForge density: 30+ controls across cl-incident-response-execution, cl-ir-plan-prep, cl-ir-reporting, cl-incident-reporting-external, and cl-cyber-rehearsal; cross-walked across all five regulators plus global IR frameworks (NIST CSF, ISO 27035).

Why this is harder than any single-regulator IR

Most cybersecurity incident-response programmes are designed for the entity's primary regulator. A bank's IR runbook reflects RBI; a securities broker's runbook reflects SEBI; an insurer's reflects IRDAI. As long as the incident is purely a "cyber security incident" and personal data is not implicated, single-regulator routing largely works.

That pattern broke in three places between 2022 and 2026.

First, CERT-In Direction 70B (April 2022) created an 6-hour reporting requirement applicable to virtually any cyber security incident affecting any entity in India — not just sector-regulated ones. CERT-In's 20-category incident taxonomy covers ransomware, data breach, DDoS, supply chain compromise, identity theft, and many other patterns. Every Indian regulated entity now has CERT-In as a default regulator regardless of sector.

Second, sectoral regulators (RBI, SEBI, IRDAI) tightened their reporting expectations through 2023–25. RBI's CIMS submission discipline now requires 6-hour initial and 21-day detailed. SEBI's CSCRF master circular (August 2024) embedded incident reporting into the cyber-resilience framework. IRDAI's March 2025 amendments strengthened the cyber-crisis-preparedness provisions including reporting expectations.

Third, DPDPA + Rules 2025 (notified November 2025) added a fifth regulatory clock for personal-data breaches. From 13 May 2027, the DPBI is operational for breach notification: an initial notification without undue delay upon awareness, plus a detailed notification within 72 hours. Affected Data Principals must also be notified without delay where the breach materially affects them. The DPDPA notification regime is parallel to CERT-In and sectoral regulator notifications, not a replacement for them.

A typical RBI-regulated bank suffering a customer-data ransomware incident in 2027 would therefore face:

CERT-In: 6-hour initial via incident.cert-in.org.in portal.
RBI: 2–6-hour initial via CIMS; 21-day detailed root-cause report.
DPBI: initial without delay; detailed within 72 hours.
Data Principals: notification without delay where materially affected.
Other parties as triggered: CERT-Fin (financial sector CERT), payment-system stakeholders (NPCI for UPI), counterparties under contractual obligations.

Four or five separate authorities, each with its own format, content requirements, language, and timing. Missing any one is independently penalty-exposing — and the penalty exposures stack: under DPDPA, up to ₹200 crore for failure to notify of the breach; under sectoral regulations, additional supervisory penalties; under CERT-In, prosecutorial action under the IT Act for failure to report.

The five regulators — what each requires

CERT-In Direction 70B (28 April 2022)

Trigger: occurrence of any of the 20 categories of cyber security incidents in CERT-In's Annexure I (ransomware, data breach, DDoS, identity theft, defacement, malware, intrusion, etc.).

Timeline: report to CERT-In within 6 hours of noticing or being brought to notice about the incident.

Authority: CERT-In, via the incident reporting portal at https://www.cert-in.org.in or its incident-management portal at incident.cert-in.org.in.

Format: structured form covering: type of incident, time of occurrence, time of detection, source and target, impact, technical details, contact details.

Follow-up: depending on the incident, CERT-In may request additional information; engage cooperatively.

Applies to: virtually any entity in India operating in the digital economy. Government, regulated entities, private companies, service providers, data centres, cloud service providers, VPN providers, intermediaries.

The 6-hour clock starts at detection, not at public disclosure. Internal awareness of the incident — by anyone in the entity with reasonable basis to recognise it — starts the clock.

RBI CIMS (Centralised Information Management System) + sectoral reporting

Trigger: significant cyber incidents affecting the RE's systems, customer data, or financial services delivery.

Timeline: initial report within 6 hours (some interpretations apply 2 hours for the most material incidents); detailed root-cause analysis report within 21 days.

Authority: RBI via the CIMS portal at https://cims.rbi.org.in. For payment system operators, additional notification to DPSS.

Format: structured form covering: incident classification, systems affected, customer impact, financial impact, initial root-cause indication, mitigation steps, remediation plan. Detailed report covers full forensic analysis, root cause, remediation completed, lessons learned, control improvements.

Applies to: scheduled commercial banks (excluding RRBs), SFBs, PBs, NBFCs (Middle / Upper / Top layers), CICs, AIFIs, UCBs (Tier 3/4), non-bank payment system operators.

Sectoral specifics: - Payment aggregators and gateways have additional reporting to DPSS for payment-system incidents. - Card networks and switches have additional reporting through the payment-system-operator chain. - Bank-payment-network incidents may trigger NPCI engagement parallel to RBI.

SEBI CSCRF incident reporting

Trigger: cyber incidents affecting SEBI-regulated entities' systems or investor data.

Timeline: prescribed timelines per CSCRF master circular; structured incident classification with severity-based notification windows.

Authority: SEBI via prescribed reporting channels; for MIIs, additional reporting to the relevant exchange / clearing corporation oversight.

Format: structured per CSCRF requirements; cross-references to the cyber resilience framework's containment / recovery / evolve goals.

Applies to: Market Infrastructure Institutions (exchanges, clearing corporations, depositories), depository participants, brokers, AMCs, AIFs, KRAs, custodians, debenture trustees, CRAs, foreign portfolio investor custodians, merchant bankers, and other SEBI-registered intermediaries.

IRDAI Information and Cyber Security Guidelines 2023 + March 2025 amendments

Trigger: cyber incidents affecting insurers, FRBs, or insurance intermediaries with potential policyholder impact.

Timeline: incident notification to IRDAI within prescribed timelines; the March 2025 amendments strengthened the crisis-preparedness expectations including reporting cadence.

Authority: IRDAI via prescribed reporting channels.

Format: structured per IRDAI Guidelines.

Applies to: insurers (life, general, health, standalone health, reinsurers), FRBs, insurance intermediaries (brokers, corporate agents, web aggregators, TPAs, IMFs, repositories, ISNPs, corporate surveyors, MISPs, CSCs, IIB).

DPBI breach notification (from 13 May 2027)

Trigger: personal-data breach as defined by DPDPA Section 2 — unauthorised processing, accidental disclosure, accidental acquisition, accidental sharing, accidental use, accidental alteration, accidental loss of access, accidental destruction, accidental loss of any personal data that compromises confidentiality, integrity, or availability.

Timeline: - Initial notification to DPBI: "without undue delay" upon becoming aware. - Detailed notification to DPBI: within 72 hours of awareness (longer if DPBI permits on written request). - Notification to affected Data Principals: "without delay" where the breach materially affects them.

Authority: Data Protection Board of India, headquartered in the National Capital Region.

Format: structured per Rule 7 covering: events and circumstances leading to the breach, measures taken or proposed to mitigate, findings on the persons responsible, remedial measures, intimation to Data Principals.

Applies to: all Data Fiduciaries from 13 May 2027.

Other regulators as triggered

Beyond the five primary, specific incident types may trigger:

NCIIPC for incidents affecting declared Protected Systems.
TRAI / DoT for telecom service disruptions.
CERT-Fin for financial sector specific reporting where established.
MeitY for incidents involving social media intermediaries under the IT Rules.
State-level cyber-crime cells where law enforcement engagement is appropriate.
CCPA / international regulators where the breach has international dimensions.

The 6-hour reality — what happens in the first 360 minutes

Recognising that the 6-hour CERT-In clock is the first to expire, and that RBI's CIMS clock often co-runs at 6 hours, the first 360 minutes from detection are the operational fulcrum.

Minute 0 — Detection (the awareness event): - Whoever detects records the time. The "detection" timestamp is the legal anchor for both CERT-In and RBI clocks. - Detection can be human (SOC analyst, customer report, employee discovery) or automated (SIEM alert, EDR alert, IDS). - The clock cannot reset because of internal escalation delay; awareness by any reasonable employee starts it.

Minutes 0–60 — Triage and confirmation: - IR runbook activates. - IR team assembles (typically virtual war room). - Initial scoping: what systems, what data, what customers, what financial impact, what is contained. - Severity classification per the entity's IR framework. - Initial notifications start within the entity: CISO, Head of Risk, CCO, General Counsel, MD/CEO.

Minutes 60–180 — External preparation: - Pre-staged regulatory templates are pulled and populated with the incident-specific data. - Legal review of the regulatory submission for material accuracy. - Communications drafted (customer communication, Board communication, potentially public communication). - Forensics engagement triggered if applicable.

Minutes 180–360 — Submissions: - CERT-In submission via incident.cert-in.org.in within the 6-hour window. - RBI CIMS submission (where applicable) within the corresponding window. - Initial DPBI notification (from May 2027) if personal data is implicated. - Sectoral regulator notification (SEBI / IRDAI / others) as applicable. - Customer / Data Principal notification triggered where material impact identified.

Beyond minute 360: - Detailed reports follow (CERT-In follow-up; RBI 21-day detailed; DPBI 72-hour detailed). - Forensic investigation completes. - Remediation activities continue. - Post-incident review and CAPA execution.

The 6-hour window is tight by design. The entities that consistently meet it are those that have pre-staged: templates ready, contacts identified, runbooks tested, internal escalation paths exercised. Entities that meet the window by accident — usually because the incident happens to coincide with a SOC analyst's clean handover and a CISO who is reachable — get caught by the next incident that happens at 02:00 on a Saturday.

The orchestration pattern — what good looks like

A 2026-mature unified incident reporting capability has the following structural properties.

One IR programme, multiple notification workflows. The same incident detection and response feeds into multiple parallel notification workflows. The IR runbook documents the workflows and assigns ownership per workflow:

CERT-In workflow: owner, template, portal credentials, submission SLA.
RBI workflow: owner, CIMS portal credentials, template, submission SLA.
DPBI workflow (from May 2027): owner, template, submission SLA.
Sectoral regulator workflow: owner, channels, template, SLA.
Customer / Data Principal communication workflow: owner, channels, template, SLA.
Board / executive communication workflow: owner, distribution list, template.

Pre-staged templates per likely incident scenario. Pre-draft CERT-In, RBI, DPBI, and sectoral notification templates for the 3–5 most likely incident scenarios at the entity: - Ransomware - Data exfiltration - Account takeover at scale - DDoS impacting service availability - Supply chain compromise / vendor breach

Each template has placeholders for incident-specific data (timestamps, systems affected, scale) but the structural language is ready.

Authority contact register, mobile-reachable. The CERT-In nodal officer, RBI CISO contact, DPBI contact (from May 2027), sectoral regulator nodal officer, internal CISO, CCO, General Counsel, MD/CEO mobile numbers — registered, refreshed quarterly, distributed to the IR team.

Vendor incident flow-back SLA ≤2 hours. Vendor contracts include incident notification within 1–2 hours of the vendor's detection of any incident affecting the entity's data or services. This is essential: a vendor incident reaching the entity at hour 5 leaves only 1 hour to make the CERT-In window.

Tabletop exercises across regulators. At least two tabletop exercises per year: one ransomware scenario with end-to-end response through all applicable regulators; one data-leakage scenario emphasising DPDPA (from 2027). Document the gaps; close them.

Live testing in selected scenarios. For mature programmes, live (or live-fire) testing in non-production: actual CIMS / CERT-In dry-run submissions, simulated DPBI engagement, customer-communication dry-run. The friction surfaces in live testing that tabletops miss.

Awareness timestamp discipline. The clocks start at internal awareness. Operating discipline ensures the "awareness" timestamp is recorded objectively — not at the point of CISO notification, but at the earliest point where any employee or system recognised the incident.

Post-incident review and CAPA. Every incident, regardless of outcome, gets a structured post-incident review with documented lessons and CAPA. The CAPA feeds back into the runbook, templates, training, controls.

Common failure patterns observed in 2024–26

Five recurring failures driving regulatory action:

1. 6-hour window measured from disclosure, not from awareness. The most common single failure. Detection at hour 0, internal escalation through hour 5, CERT-In submission at hour 11. The 6-hour clock started at hour 0; the entity is 5 hours late.

2. CIMS / CERT-In portal access not pre-staged. Discovery mid-incident that the credentials are unavailable, the nodal officer doesn't have access, or the template doesn't load. The submission window expires while the entity figures out the portal.

3. Vendor-side incidents reach the entity late. The vendor detects the incident; flow-back through the customer-relationship channel takes 8 hours; the entity blows the CERT-In window for an incident it didn't cause but is responsible for reporting.

4. Sectoral and DPBI submissions deprioritised in favour of CERT-In. CERT-In is the most-known clock; teams focus there. RBI CIMS gets done late; from May 2027, DPBI gets done late or not at all.

5. Detailed reports filed without rigorous root-cause analysis. The 21-day RBI detailed report or the 72-hour DPBI detailed report submitted with shallow analysis to meet the deadline. Subsequent supervisory follow-up identifies the gap; the entity faces both incident penalty and inadequate-reporting penalty.

Two further patterns from 2026 specifically:

6. Multi-regulator stories diverge. The CERT-In submission says one thing; the RBI submission says something subtly different; the DPBI submission, when prepared, says a third thing. Regulators cross-reference. Inconsistency invites scrutiny.

7. Public communication outpaces or contradicts regulatory submission. Press release or customer notification with details not yet shared with regulators. Regulators read the same press as customers; inconsistencies surface.

8. Tabletops focus on cyber but skip the regulatory submission mechanics. Many tabletops exercise the technical response — containment, eradication, recovery — without exercising the regulatory submission paths in operational detail. The tabletop ends at "we'd notify CERT-In" without anyone actually opening the portal, attempting a submission, or testing the form-completion timing under simulated pressure.

How ControlForge supports this

The unified incident reporting area is one of the highest cross-reference densities in the KB. Relevant clusters:

cl-incident-response-execution — operational IR execution.
cl-ir-plan-prep — IR runbook preparation and testing.
cl-ir-reporting — the reporting layer.
cl-incident-reporting-external — external regulatory notification synthesis.
cl-cyber-rehearsal — tabletop and live testing.
cl-breach-notification-72h — DPDPA-specific 72-hour clock.
cl-gdpr-breach-notification — GDPR-aligned 72-hour clock (useful reference for multi-jurisdiction entities).

The synthesis surfaces the strictest-clause across CERT-In, RBI, SEBI, IRDAI, DPDPA, GDPR, and NIST CSF / ISO 27035 — allowing a single IR programme to satisfy multi-regulator obligations through consolidated evidence.

A 60-day unified IR uplift plan

For Indian regulated entities recognising the gap:

Days 1–15: Inventory and gap analysis. - Map the regulatory regimes touching the entity. - Inventory existing IR runbook coverage per regime. - Identify the gaps: which workflows are missing, which templates are absent, which authority contacts are stale.

Days 16–30: Template and contact preparation. - Draft pre-staged templates for the 3–5 most likely incident scenarios per regime. - Refresh the authority contact register with mobile numbers and out-of-hours channels. - Verify portal access for CERT-In, CIMS, and other portals. - Refresh vendor incident-notification SLA in critical-vendor contracts.

Days 31–45: Tabletop and live testing. - Conduct a ransomware tabletop exercising end-to-end response through all applicable regulators. - Identify gaps; close them. - Conduct a data-leakage tabletop with DPDPA workflow (anticipating May 2027 enforcement).

Days 46–60: Operationalisation and review. - Update the IR runbook with the gap closures. - Brief executives and Board on the uplift. - Establish the periodic tabletop cadence (minimum 2 per year). - Schedule the next live or live-fire test for Q2.

By day 60, the programme should be in operational state with the structural improvements in place. Continuous improvement extends from there.

Cross-references

Beyond the five regulators detailed above, related synthesis areas:

NIST CSF 2.0 Respond function — structural IR backbone aligned with Indian sectoral expectations.
ISO/IEC 27035-1, 27035-2, 27035-3 — incident management standards.
GDPR Article 33 (controller notification) — 72-hour clock that maps closely to DPDPA Rule 7 for international Data Fiduciaries.
EU NIS 2 Directive — comparable incident-reporting regime for entities with EU operations.

For Indian regulated entities with international footprints, the synthesis layer is essential — a single incident at a multinational bank or insurer can trigger CERT-In + RBI + DPBI + GDPR controller notification + sectoral EU notification + US state breach laws concurrently. Pre-staging the international layer alongside the Indian layer is part of mature 2026 incident response.