RBI Cyber Incident Reporting: The 2-6 Hour Playbook

Last updated: April 26, 2026

RBI requires regulated entities to report cyber incidents within 2-6 hours of detection. The reporting window starts at detection, not analysis-completion. Without a pre-built playbook, the window passes before draft notification is ready. This article covers the practitioner playbook — templates, decision tree, and the multi-regulator coordination required.

The reporting matrix

The pre-drafted email template

To: [email protected] (or CERT-In [email protected])
Subject: [URGENT - Cyber Incident Notification] [Entity Name] - [Incident Type] - [Date]

1. Reporting entity:
   - Name: [Entity legal name]
   - RBI license type: [Bank / NBFC / PA / etc.]
   - License number: [...]
   - Contact: [Name / designation / phone / email]

2. Incident summary (one paragraph):
   [Plain English description: what was detected, when, by whom, current scope]

3. Time of detection: [DD-MMM-YYYY HH:MM IST]
4. Time of reporting: [DD-MMM-YYYY HH:MM IST]
5. Incident category (per CERT-In Annexure I):
   [Choose from: data breach, ransomware, DDoS, etc.]

6. Affected systems:
   - System name(s): [...]
   - Function: [customer-facing / internal / regulatory reporting / etc.]
   - Data type(s): [PII / payment data / transaction data]
   - Approximate customer impact: [number / scope]

7. Initial response actions:
   - Containment: [actions taken]
   - Investigation: [in progress / steps taken]
   - Customer communication: [planned / sent]

8. Likely cause (preliminary): [if known]
9. Anticipated public disclosure: [Yes / No / TBD]
10. Subsequent updates: We will provide hourly updates for the first 24 hours.

[Authorised signatory: CISO or designated officer]
[CC: Internal CTO / GC / Head of Risk / Head of Audit]

The decision tree

Incident Detected (Time = T)
├── Is it cyber-related?
│   └── No → standard IR (no regulator notification)
│   └── Yes → continue
├── Affects customer data / financial systems?
│   └── Continue
├── Within 2 hours of T:
│   ├── Engage CISO + on-call IR team
│   ├── Confirm category (data breach, ransomware, DDoS, etc.)
│   └── Begin containment
├── Within 4 hours of T:
│   ├── Draft notification using template
│   ├── Internal review (CISO, CTO, GC, Head of Risk)
│   └── Authorised signatory approval
├── At 6 hours from T (or earlier):
│   └── Send to RBI + CERT-In + (if applicable) NPCI / sectoral CERT
├── Within 24 hours:
│   └── Hourly update emails to RBI
├── Within 72 hours (if personal data involved):
│   └── DPDP Board notification (when Board operationalised)
└── Public disclosure decision separately tracked

Pre-incident preparation

• Authorised signatories list — CISO + 2 backups, with contact at all hours
• Email aliases set up ([email protected] routing to multiple recipients)
• Pre-approved templates by GC / external counsel
• Internal escalation matrix — who needs to know within 1 hour, 4 hours, 24 hours
• Customer-facing templates for public-facing disclosure if customer-impacting
• Quarterly tabletop exercising the entire flow

Common mistakes

• Waiting for full root-cause before reporting (the clock runs from detection)
• Reporting only to RBI, missing CERT-In
• Underestimating customer impact in initial report (then revising upward)
• Communicating to media before regulator (regulator-first is the norm)
• Not maintaining contemporaneous records (notes, decisions, communications)

The takeaway

Cyber-incident reporting timelines under RBI are tight. Pre-built playbooks turn a 4-hour panic into a 30-minute checklist. Run a tabletop within the next 30 days; identify and fix gaps before a real incident finds them.