Skip to main content
Working document · Fill it in before, work it during

The India Incident
Reporting Pack

Six hours is the number in three instruments, and the three do not mean the same thing by it. Direction (ii) runs from noticing or being brought to notice; the RBI’s DAKSH paragraphs run from detection; SEBI’s Annexure-O runs from noticing, detecting or being brought to notice, and then carries a second clock to twenty-four hours. Three of the five due-time lines on the cover sheet can be different times on the same incident.

16
Sections in the pack
20
Types listed at Annexure I
7
Entity classes, each with its paragraph

The India Incident Reporting Pack

Enter your work email for the printable pack — the cover sheet and its two clocks, the cumulative table of which filings you owe, the divergence table, Annexure I's twenty types, the six-hour filing template, the Point of Contact form, the log annex, the DAKSH row by entity class and paragraph, and the SEBI post-incident calendar.

By downloading, you agree to receive relevant communications. We respect your privacy.

The three clocks

Three instruments carry six hours, and each names its own moment for it to start

For one entity they run at once. An organisation told about its own breach by a customer, a vendor or a researcher has started the CERT-In and SEBI clocks with that message, and the DAKSH clock is written against detection. Section 2 of the pack is where all three moments get written down at the start — the arithmetic is done once, before there are three clocks to hold at the same time.

CERT-In

6 hours Direction (ii) · No. 20(3)/2022-CERT-In, 28 April 2022

Runs from “noticing such incidents or being brought to notice about such incidents”

Direction (ii) requires any service provider, intermediary, data centre, body corporate or Government organisation to report cyber incidents as mentioned in Annexure I to CERT-In within six hours. Annexure I is headed “Types of cyber security incidents mandatorily to be reported by service providers, intermediaries, data centres, body corporate and Government organisations to CERT-In”, and lists twenty. The channels are [email protected], 1800-11-4949 and fax 1800-11-6969, and the Direction adds that the methods and formats are published on the CERT-In website and “will be updated from time to time”.

RBI

6 hours Six Directions of 31 July 2026 · ¶182 / 181 / 181 / 88 / 28 / 141 / 177

Runs from “of detection”

The Commercial Banks Direction, RBI/DoS/2026-27/410 ¶182: “The bank shall report cyber incidents within six hours of detection on DAKSH platform (Reserve Bank’s Advanced Supervisory Monitoring System - https://daksh.rbi.org.in). The bank shall also pro-actively notify CERT-In regarding cyber incidents.” Six Directions were issued on the same day and the paragraph number differs in each. Section 11 of the pack sets out which paragraph governs which entity class, across seven rows.

SEBI

6 hours, then 24 CSCRF Annexure-O · SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024

Runs from “noticing/ detecting such incidents or being brought to notice about such incidents”

Annexure-O part A, clause 1 states SEBI’s own threshold: “Any incident stated under CERT-In Cybersecurity directions and meeting below criteria shall be mandatorily reported within 6 hours of noticing/ detecting such incidents or being brought to notice about such incidents”. Part B, clause 1 is the handling clause: the information goes to SEBI through [email protected] within six hours and to CERT-In in the same six, the details go on the SEBI Incident Reporting Portal within twenty-four, and a stock broker or depository participant reports to its stock exchange or depository inside the same six hours.

Both sectoral instruments carry CERT-In in their own text, and Direction (ii) puts the CERT-In filing on every body corporate in any event — so section 3 is built as a cumulative list rather than a decision tree. Start at the row that reaches every entity in its first column, add each further row that describes you, and write the owner and the due time beside each one you take.

The divergence table

Seven rows, three columns, and the clause behind every cell

Read down the “runs from” row first. The rest of the table is what a colleague asks for once the filing is out: which channel it went down, what each instrument reaches, what follows it, and where each regulator states the consequence of a filing that does not arrive.

Instrument

The citation you put in a policy, a filing or a board paper: the Direction and its date, the six RBI references and their paragraphs, and the circular number with the page.

Clock

Six hours in each column, and SEBI’s second clock at twenty-four hours on the Incident Reporting Portal.

Runs from

The row the pack exists for, and the one to read first. A customer’s email, a vendor’s disclosure or a researcher’s report starts the CERT-In and SEBI clocks; the DAKSH clock is written against detection. Record all three moments at section 2 rather than reconstructing them later.

Channel

The mailbox, the phone and the fax; DAKSH at daksh.rbi.org.in; the SEBI mailbox, the portal, and the exchange or depository for a broker or a DP.

What it reaches

Taken from each instrument separately: Annexure I’s twenty types for the CERT-In filing, your own Direction’s definitions paragraph for the DAKSH one, and SEBI’s listed incidents at six hours with any and all other cybersecurity incidents at twenty-four.

Follow-on

What follows the filing in each instrument: FAQ Q 30 provides that additional information “may be reported later within reasonable time”; the RBI Direction requires analysis of the incident for severity, impact and root cause; and SEBI’s dated calendar runs out to seventy-five days.

Non-compliance

Stated from each instrument’s own words: section 70B(7) as the CERT-In FAQ reproduces it, the statutory power each RBI Direction names in its own preamble, and SEBI’s sentence at Annexure-O B.1.

Established in advance

Five rows you can close today, on a day when nothing is happening

Sections 2, 3, 9, 10 and 13 are filled in before anything happens; sections 8 to 12 are worked during. The five below are the ones section 5 marks “Established in advance” — each is a pre-incident act, and each is settled by a decision rather than by an incident.

01

A designated Point of Contact

Direction (iii) requires the service providers, intermediaries, data centres, body corporate and Government organisations it names to designate a Point of Contact to interface with CERT-In, in the format specified at Annexure II, kept updated. Annexure II gives eight fields and one address. Section 9 is that form, and the duty is older than the Direction — Rule 17 of the CERT-In Rules 2013 carries it too.

02

The retention you actually hold

Direction (iv) puts three things in its mandatory limb: logs enabled across all ICT systems, held securely for a rolling 180 days, and maintained within the Indian jurisdiction. Section 10 tests that against thirteen system classes taken from CERT-In’s own non-exhaustive list at FAQ Q 37, with a column for where each is stored and who can produce it. Where a shared host or a managed platform sets the number, it is theirs, and today is when to ask.

03

A time source, and the record that it was checked

Direction (i) sits underneath every log row: clocks synchronised to the NTP servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them. FAQ Q 43 names samay1.nic.in, samay2.nic.in and time.nplindia.org. Record the date of the last verification, not the date of the setup.

04

Three names, written down

Who drafts the six-hour filing, who sends it and from which mailbox, and who is authorised to sign off outside working hours. CERT-In’s Help Desk runs on a 24-hour basis under Rules 5 and 12(1); the question section 2 asks is whether your approval path does.

05

The approval path, and the clause somebody will raise

Section 13 asks who inside the entity has to agree before a filing goes out and what each of them needs to see. It is the row that decides whether six hours is enough. Beside it: the contract clause somebody will raise, and where the answer lives — FAQ Q 22 puts the statutory obligation above a confidentiality clause by virtue of section 81 of the IT Act, 2000.

Section 5 gives six states to record an answer in, so the answer that is neither yes nor no has a word and an unexplained blank stops reading as a gap. “Drafted, not sent” is a different problem from “Owed, no owner”, and the second is the row that fails at 02:00.

Contents

Sixteen sections, eleven of them things you fill in

It is a working document, not a guide. Section 1 is the boundary you read before answering anything; sections 2 and 3 are filled in on a quiet afternoon; sections 8 to 12 are the ones open on the desk while the filings go out.

1. What this pack is for, and where it stops

Rule 12(1)(a) put the duty in words in 2014; Direction (ii) put a number on it in 2022; two sectoral regulators have since written their own clock on top. And FAQ Q 13, which is why the pack is addressed to you: the obligation is “neither transferrable nor indemnified or dispense with”.

2. Cover sheet, and the two clocks

Twelve lines filled in before anything happens, then the eight you fill in during. Three of the five due-time lines can be different times on the same incident — write all of them down at the start, because the arithmetic is done once, before there are three clocks to hold at the same time.

3. Which filings you owe

Seven cumulative rows. Start at the one that reaches every entity in the first column and add each further row that describes you, with the owner and the due time written beside each one you take.

4. The divergence table

The centrepiece: instrument, clock, runs from, channel, what it reaches, follow-on and non-compliance, across the three regimes, with the clause behind every cell.

5. How to record an answer

Six states, so the interesting answers have a word and an unexplained blank stops reading as a gap. “Owed, no owner” is the row that fails at 02:00; “Established in advance” is the one worth chasing today.

6. The twenty types Annexure I names

All twenty as a tick-list under Direction (ii), grouped four ways, each carrying its Annexure I numeral so it can be cited as CERT-In cites it. More than one row can describe a single incident, and the reporting form is built for that — its incident-type block carries all twenty as checkboxes, plus an “Other (Please Specify)” line.

7. For a SEBI RE: classify it

A separate and SEBI-specific job: SEBI’s four criteria at Annexure-O A.1 in its own words, the Table 35 severity classification, clause A.4 applied on top of it, and the IT Committee and HPSC-CS reviews that follow.

8. The six-hour filing: what goes in it

Seventeen fields in the order the CERT-In Incident Reporting Form asks for them and in its own words, with occurrence and detection times as the two separate fields the form collects.

9. The Point of Contact

Direction (iii) and the Annexure II format — eight fields and one address. Five minutes on a quiet afternoon, and section 9 also asks for the date the details were last sent.

10. The log annex, and the clocks underneath it

Direction (iv)’s mandatory limb, thirteen system classes from FAQ Q 37 with retention, storage location and who can produce them, and Direction (i)’s timestamps under all of it.

11. The RBI row: DAKSH, by entity class and paragraph

Seven entity classes across six Directions, one date, one clock and a different paragraph in each — including which chapter of the NBFC Direction your applicability paragraph puts you in.

12. The SEBI post-incident calendar

Table 36’s dated rows and the anchor they all run from, the reports the IT Committee reviews before submission, and the quarterly return, which is a standing return separate from any incident.

13. Confidentiality: what happens to what you report

Rule 13’s four sub-rules, cited whole the way FAQ Q 16 cites them, and FAQ Q 22 on the contract clause that runs the other way. Then two fields: the approval path, and where the answer to that clause lives.

14. Currency check: what has changed, and when

Five dated instruments, what each one did, and a column for the date your own policy, pack or tender was updated to match.

15. Sources

Eleven rows. Every reference in the pack with its date, the clauses used, and the sections that use them.

16. Working with Security Brigade on the filings

What we take ownership of during an incident, what arrives afterwards, and what sections 9 and 10 mean you can do today without us.

What starts when you file

For a SEBI RE, the six-hour filing starts a calendar

Every timeline in Table 36 runs “from the date of reporting the incident or being brought to notice about the incident”. Where a customer, a vendor or a researcher brought it to your notice, that moment is the anchor, and it can fall on the day before you file. Fix one anchor date on the day you file and set the rows from it. Section 12 is that calendar, with a due-date column and a state beside each row.

3 days

Interim Report

Table 36, row 1. Contents are specified as a minimum, including the time of occurrence, the affected processes, systems, networks or services, the severity, and the steps taken to initiate response and recovery.

7 days

Mitigation measure

Table 36, row 2.

30 days

Root Cause Analysis report

Table 36, row 3. The contents are specified as a minimum and include the exact cause, the chronology, and the corrective and preventive measures with timelines. Additional time may be provided on request, taking into account the complexity and nature of the incident, and the clause adds: “The same shall be an exception rather than the rule.”

45 days

Vulnerability Assessment and Penetration Testing for the incident, and its closure reports

Table 36, row 5. A dated retest obligation triggered by the incident itself, and forty-five days is shorter than it reads once scoping and remediation are inside it.

Max 75 days

The forensic report, at its outer limit

Annexure-O B, clauses 4.1 to 4.3. Clause 4.1 makes it mandatory for every incident classified High or Critical; clause 4.3 decides the timeline for both reports in discussion with all stakeholders, with a maximum of 75 days from the date of reporting for the forensic report.

15 days

The quarterly return

CSCRF RS.CO guidelines, p.124, item 4 — on cyber-attacks, threats, incidents and breaches and the measures taken, within 15 days from the quarter ended June, September, December and March. A standing return, separate from any incident.

Table 36’s deadlines run at every severity, from that one anchor. What the severity classification decides is which further report is owed: clause 3.5 has the RE classify the incident against Table 35, clause A.4 is applied on top of the table, and clause 4.1 makes the forensic report mandatory for every incident classified High or Critical. Clause 3.4 puts the RCA, forensic, VAPT and closure reports before your IT Committee before they go to SEBI — so the meeting is booked when the incident is reported, not when the report is drafted.

Where every row came from

Every clock, channel and paragraph number was read from the instrument itself

The CERT-In Directions of 28 April 2022 and the extension of 27 June 2022; the May 2022 FAQs; the Incident Reporting Form; the CERT-In Rules 2013; the six RBI Directions of 31 July 2026; and the CSCRF master circular with the SEBI extension and technical clarifications that have amended it since. Section 15 sets them out across eleven rows, each with its date, the clauses used and the sections of the pack that use them.

That is also why section 14 exists. Five dated instruments sit behind the rows, and a pack, a policy or a tender citing a superseded line propagates it into every response it receives — so the currency check names what each instrument did and leaves a column for the date your own documents were updated to match. Paragraph numbers differ across the six RBI Directions and one of them carries two, so work from your own copy of the one that governs you.

Where we fit

We take the filing. The obligation stays with you

Security Brigade takes full ownership of CERT-In six-hour incident notification as part of an incident response engagement, and handles the concurrent RBI and SEBI notifications where they apply. We respond 24/7, on +91 22 4164 2220. We are CERT-In empanelled and have been since 2008. We do the drafting, the assembly and the sending — and the statutory obligation remains your entity’s, because FAQ Q 13 puts it there in terms: “Any entity which notices the cyber security incident, shall report to CERT-In. The obligation of reporting of cyber incident is neither transferrable nor indemnified or dispense with.” Both halves are true at once, and it is worth knowing which is which before you need either.

We respond to incidents; we do not run your compliance programme, and this pack is worth more to you filled in beforehand than any conversation with us. If what you actually need is a Point of Contact designated and a retention setting changed, do that today without us — sections 9 and 10 are the whole of it.

Three filings due on the same incident?

Tell us which instruments name your entity and the moment you were brought to notice. Those two set every due time on the cover sheet, and they decide which of the filings are already running while you read this.

Describe the incident