Most compliance leads can name the CERT-In deadline. Far fewer can name the point at which the clock starts, and that is the part that decides whether a report is filed late.
The distinction matters because the four Indian regulators that impose incident reporting obligations do not share a definition of an incident, a deadline, or a channel. A single event at a regulated entity can start three clocks at once, each measured from a different moment.
What each regulator actually requires
| Regulator | Deadline | Clock starts | Channel |
|---|---|---|---|
| CERT-In | 6 hours | On noticing the incident | incident@cert-in.org.in |
| RBI | 2–6 hours | On detection, per the applicable direction | Supervisory portal |
| SEBI | 6 hours | On becoming aware | SEBI SCORES / CSCRF channel |
| IRDAI | 48 hours | On detection | Cyber incident report format |
Building a process that meets the shortest clock
Meeting six hours reliably is a detection problem and an authorship problem. The reporting itself takes minutes; assembling the facts does not.
- 1Define “noticing” in writing
Name the roles who can notice, and the systems that count as noticing on their behalf. If an alert fires into a channel nobody watches overnight, decide now whether that starts the clock — because the regulator will decide it did.
- 2Pre-write the submission
The CERT-In format asks for facts you will not have time to gather under pressure: affected systems, entry vector, data classes, containment steps taken. Draft the skeleton once, in calm conditions.
- 3Rehearse against the shortest deadline
Run the drill against six hours, not against whichever deadline you think applies. Meet the shortest and you have met all four.
The deadline that matters is the shortest one you are subject to, not the one for the incident you think you are having.
Where the six hours usually goes
- Alert-to-human latency overnight and at weekends — usually the largest single block.
- Deciding whether the event qualifies, which teams often treat as a prerequisite rather than something to do in parallel.
- Locating an authorised signatory, at 3am, on a Sunday.
- Assembling the affected-systems list from an asset inventory nobody has maintained.
Only the last of those is a tooling problem. The other three are decisions that can be made in advance, and writing them down is most of the work.
CERT-In initial report — skeleton
1. Time noticed (IST, to the minute)
2. Nature of incident
3. Systems / networks affected
4. Data classes potentially involved
5. Containment actions taken so far
6. Point of contact + authorised signatoryOn noticing. Waiting for confirmation before starting the clock is the single most common reason reports are filed late. Report on what you know, and follow up as you learn more.
Often yes. A regulated entity subject to both RBI directions and the CERT-In directions reports to both, on each one's own timeline and in each one's own format.
CERT-In publishes a list of incident types, and it is broader than most teams assume — it includes unauthorised access attempts, not only successful breaches.
There is no penalty for reporting an event that turns out to be benign. There is one for failing to report an event that was not.
Incident reporting deadlines — one-page reference
All four regulators, their deadlines and their clock-start definitions, on a single printable page.
DownloadFacts last verified 28 Aug 2026
