The six-hour report: what actually gets sent, and who else you owe

Six hours is the number in the instrument, and your clock has probably already started.

The rule started as a phrase. Rule 12 of the CERT-In Rules 2013 has the listed incident types reported to CERT-In "as early as possible to leave scope for action" — CERT-In's own restatement of it, at FAQ Q 10 of May 2022, written in the present tense a month after the Directions issued. On 28 April 2022 the Directions put a number on it.

That number is what this page is about: what is due, what goes in it, who sends it, and which other regulator is waiting on a filing in the same window.

1. When your six hours started

Directions No. 20(3)/2022-CERT-In, 28 April 2022, Direction (ii), verbatim:

"Any service provider, intermediary, data centre, body corporate and Government organisation shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents. The incidents can be reported to CERT-In via email (incident@cert-in.org.in), Phone (1800-11-4949) and Fax (1800-11-6969). The details regarding methods and formats of reporting cyber security incidents is also published on the website of CERT-In www.cert-in.org.in and will be updated from time to time."

Read the trigger again. The clock starts at the earlier of two moments: noticing, or being brought to notice. Whichever of those two happened first is your zero.

A customer's email starts it. A vendor's disclosure starts it. A researcher's report starts it. Your own alert starts it. CERT-In restates the same trigger in FAQ Q 24: "The cyber incident needs to be reported to CERT-In within 6 hours of noticing the incident or being brought to notice about such incident."

So the first thing to write down, before anything else, is the time you found out.

That last row is live. Under the CERT-In Rules 2013, CERT-In functions on a 24-hour basis on all days of the year (Rule 5), and operates an Incident Response Help Desk on a 24-hour basis on all days including Government and other public holidays (Rule 12(1)). The 05:30 deadline stands.

The threshold sits inside the definition. Rule 2(h) of the same Rules defines the term, and CERT-In reproduces the definition in full at FAQ Q 3:

"Cyber Security Incident" means any real or suspected adverse event in relation to cyber security that violates an explicitly or implicitly applicable security policy resulting in unauthorised access, denial of service or disruption, unauthorised use of a computer resource for processing or storage of information or changes in data, information without authorisation.

Read the whole of it. The event has to violate an applicable security policy and produce one of the listed results — and it counts when it is suspected as readily as when it is established. Direction (ii) then starts the clock on being brought to notice as readily as on noticing. A suspected incident that somebody else told you about sits squarely within both clauses.

2. Whether you are covered

Direction (ii) names the classes: service providers, intermediaries, data centres, body corporate and Government organisations.

"Body corporate" is the widest of those, and CERT-In defines it by reference to s.43A of the IT Act 2000. FAQ Q 25 reproduces the explanation: "'body corporate' means any company and includes a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities." A single-person consultancy running a website sits inside that sentence.

FAQ Q 26 settles the cross-border question in one line: the Directions "are applicable to any entity whatsoever, in the matter of cyber incidents and cyber security incidents." FAQ Q 29 adds that service providers, intermediaries, data centres and body corporate offering services to users in the country shall designate a Point of Contact to liaise with CERT-In.

3. What is on the list

Direction (ii) attaches the six hours to a list, and it attaches them to the list entire: entities "shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours." Every item below sits inside that sentence.

Annexure I to the Directions 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 cross-refers to Rule 12(1)(a) of the CERT-In Rules 2013. Twenty types, verbatim:

CERT-In's own severity language. At FAQ Q 30 of May 2022, CERT-In names the kinds of incident it has in mind at the six-hour mark:

• "cyber incidents and cyber security incidents of severe nature (such as denial of service, distributed denial of service, intrusion, spread of computer contaminant including Ransomware) on any part of the public information infrastructure including backbone network infrastructure"
• "Data Breaches or Data Leaks"
• "large-scale or most frequent incidents such as intrusion into computer resource, websites etc."
• "cyber incidents impacting safety of human beings"

The incidents this page exists for are named in terms in both texts. Ransomware is Annexure I item (v), and CERT-In's own example of a severe-nature incident. Data breach and data leak are items (xi) and (xii), and a criterion of their own. Intrusion into a website is item (iv), and the third criterion. And the obligation itself is Direction (ii)'s: every type in Annexure I, to CERT-In, within six hours of the moment you found out.

4. What actually gets sent

Direction (ii) gives three channels: email to incident@cert-in.org.in, phone 1800-11-4949, fax 1800-11-6969. The same clause says the methods and formats are published on cert-in.org.in and "will be updated from time to time" — so check the live page rather than a saved copy. CERT-In's Incident Reporting Form is served at https://www.cert-in.org.in/PDF/certinirform.pdf, the URL CERT-In itself cites in FAQ Q 30. CERT-In accepts the relevant information in any readable form — the form's own note records that incidents may also be reported by providing relevant information in the communication itself or in any other readable form.

What the form collects. This is the gather list, and it is short enough to fill from a phone:

• Whether you are the affected entity, or reporting an incident affecting another entity
• Reporter: name and role, organisation, contact number, email, address
• Affected entity, where different from the reporting entity
• Incident type — the Annexure I types, abbreviated, as checkboxes, plus a free-text "Other (Please Specify)"
• Whether the affected system or network is critical to the organisation's mission, with brief details
• Basic information of the affected system: domain/URL, IP address, operating system, make/model/cloud details, affected application details, location of the affected system including city, region and country, and the network and name of the ISP. The form's own instruction on this block is "(Provide information that is readily available.)"
• A brief description of the incident
• Occurrence date and time, and detection date and time — two separate fields

That last pair is the one people collapse. Keep them apart: the form asks for both.

Send what you have. FAQ Q 30, verbatim: "The entities may provide information to the extent available at the time of reporting. Additional information may be reported later within reasonable time to CERT-In."

The clause allows the report to carry what is known at the time, with the rest following within reasonable time. At hour five, with half the fields still unknown, that is the whole answer: file, then keep filling it in.

The logs. Direction (iv), verbatim:

"All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction. These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In."

Note where the clause changes gear. Enabling the logs, holding them for a rolling 180 days and holding them within the Indian jurisdiction are "shall mandatorily". Producing them alongside a report is "should be provided". Read the mandatory half first: the 180 days is the obligation that decides, months before an incident, whether there is anything to produce at all.

FAQ Q 37 gives CERT-In's own non-exhaustive list of what that covers — firewall, intrusion prevention, SIEM, web, database, mail, FTP and proxy server logs, event logs of critical systems, application logs, ATM switch, SSH and VPN — and adds the line that decides most investigations: "From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded."

Pull those before anyone rebuilds anything. What that means in practice, and the four things that destroy them, is what to preserve before you rebuild.

Three further obligations sit in the same instrument, named here so you can find them: Direction (i), clock synchronisation to NIC or NPL time; Direction (v), subscriber registration by data centres, VPS, cloud and VPN service providers; and Direction (vi), KYC and transaction records for virtual asset service providers, exchange providers and custodian wallet providers.

5. Who sends it, and who carries the duty

Direction (iii) requires every covered entity to designate a Point of Contact to interface with CERT-In, notified in the Annexure II format and kept updated: "All communications from CERT-In seeking information and providing directions for compliance shall be sent to the said Point of Contact."

Annexure II is eight fields — name, designation, organisation name, office address, email ID, mobile number, office phone, office fax — sent to info@cert-in.org.in. Where yours is still to be designated, that is eight fields and one email address, and it can be done in the same hour as the report.

The duty stays with you. FAQ Q 13, verbatim: "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."

Read that alongside FAQ Q 22, which answers the question every hosting and MSP contract raises: the reporting obligation "is statutory in nature and overrides any confidentiality clause in any contract by virtue of the provisions of section 81 of the IT Act, 2000."

The obligation survives your customer contracts and your vendor agreements alike.

Where we sit in that. Security Brigade takes full ownership of CERT-In six-hour incident notification requirements — the drafting and the filing. The statutory obligation stays with your entity, because FAQ Q 13 says it does. Both sentences are true at the same time.

6. Who else is owed a filing in the same window

If your entity is regulated, a second clock is running on a different instrument. Each one below is taken from that regulator's own text.

RBI-regulated entities — six hours, from detection, on DAKSH

On 31 July 2026 the RBI Department of Supervision issued consolidated Directions by regulated-entity type. Each carries a six-hour cyber incident reporting obligation, and each routes it to a platform: DAKSH, the Reserve Bank's Advanced Supervisory Monitoring System at https://daksh.rbi.org.in.

Commercial Banks Direction, para 182, verbatim:

"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."

Housing Finance Companies file with the National Housing Bank. The Note attached to para 141 of the NBFC Direction reads that in respect of Housing Finance Companies, cyber incidents shall continue to be reported to NHB.

These are in force now. The Commercial Banks Direction, para 2: "These Directions shall come into effect immediately upon issuance." The NBFC Direction, para 2: "These Directions shall come into force with immediate effect."

The trigger word is the whole point. RBI says "of detection". CERT-In says "of noticing such incidents or being brought to notice about such incidents". For a bank told about its own breach by a third party on Tuesday morning, those are two different starting moments, and they need to be recorded separately in your incident log.

And for NBFCs, the simplest true statement is the widest one: every NBFC, at every layer of the scale-based tiering, is a body corporate, and therefore owes CERT-In six hours under Direction (ii).

SEBI regulated entities — four filings inside the first 24 hours

The CSCRF, SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 of 20 August 2024, states the obligation twice: at RS.CO Guidelines item 1, page 123, applicability "All REs (Mandatory)", and in Annexure-O, part B, clause 1 at page 200.

Annexure-O B.1, verbatim:

"Any cyber-attack(s), cybersecurity incident(s) and breach(es) experienced by REs falling under CERT-In Cybersecurity directions shall be notified to SEBI and CERT-In within 6 hours of noticing/ detecting such incidents or being brought to notice about such incidents. This information shall be shared to SEBI through the email ID mkt_incidents@sebi.gov.in within 6 hours and SEBI Incident Reporting Portal within 24 hours. Stock Brokers/ Depository Participants shall also report the incident(s) to Stock Exchanges/ Depositories along with SEBI and CERT-In within 6 hours of noticing/ detecting such incidents or being brought to notice about such incidents. Any/ all other cybersecurity incident(s) shall be reported to SEBI, CERT-In and NCIIPC (as applicable) within 24 hours."

Count the filings for a stock broker who is told at 09:00 that its systems have been encrypted. By 15:00 it owes CERT-In, SEBI at mkt_incidents@sebi.gov.in, and its Stock Exchange or Depository. By 09:00 the next morning it owes the SEBI Incident Reporting Portal. An RE whose systems NCIIPC has identified as Critical Information Infrastructure or a protected system reports to NCIIPC as well (Annexure-O B.3.1).

CSCRF adopts CERT-In's trigger verbatim and footnotes the source: footnote 37 on page 200 points at CERT-In FAQ Q 30. The sectoral framework sits on top of the CERT-In obligation and routes the entity back to it.

Then the calendar starts. Annexure-O clause 3.3, Table 36, with timelines running "from the date of reporting the incident or being brought to notice about the incident":

Four details inside that table decide whether an RE meets it.

• The forensic report has its own clause and its own clock. Table 36 sends the reader to clause 3.4, and clause 3.4 is the IT Committee requirement below. The timing sits in part 4 of the same Annexure: clause 4.1 — "For all incidents classified as High or Critical, the RE shall submit a forensic audit/ investigation report" — and clause 4.3, which sets the outer limit: "the maximum period for the submission of forensic audit report shall be 75 days from date of reporting of incident." Table 35 lists a ransomware attack under Critical, which is what engages clause 4.1.
• Clause 3.4: the RCA, forensic audit, VAPT and closure reports "shall be reviewed by the respective IT Committee for REs before the reports are submitted to SEBI", and the Committee's review report goes to SEBI alongside them. Put the Committee's meeting date inside the 30- and 45-day windows when you plan them.
• Clause 3.6: where reports are found deficient or inaccurate — SEBI's examples are no identification or incorrect identification of root cause, and an inaccurate sequence of events — the RE "may be provided an additional time upto 15 days from the day of being notified of the deficiency/ inaccuracy". An inaccurate sequence of events is a timestamp problem, which is a log problem, which is decided in hour one.
• The interim report must contain, among other things, the time of occurrence, the affected processes, systems, networks and services, the severity, and the steps taken to start response and recovery.

One RS.CO.S2 line has been rewritten and is worth checking against your playbook. SEBI's technical clarifications of 28 August 2025, clause 6.4, state that the RS.CO.S2 communications guideline "shall now be read as under: REs shall take action as per their approved Cyber Crisis Management Plan (CCMP)." If your crisis runbook was drafted against the August 2024 text, that is the paragraph to re-read.

7. The three clocks, side by side

Two things follow from the table. The filings stack — a regulated entity works through every row that applies to it. And the clocks start at different moments, so your incident log needs a separate timestamp for each trigger if it is going to evidence both.

8. What non-compliance carries

The Directions close with it: "The failure to furnish the information or non-compliance with the ibid. directions, may invite punitive action under sub-section (7) of the section 70B of the IT Act, 2000 and other laws as applicable."

CERT-In sets out sub-section (7) in the introduction to its own May 2022 FAQ, at paragraph 4, quoting the Act:

"Any service provider, intermediaries, data centres, body corporate or person who fails to provide the information called for or comply with the direction under sub-section (6), shall be punishable with imprisonment for a term which may extend to one year or with fine which may extend to one lakh rupees or with both."

Under Rule 20 of the CERT-In Rules 2013, a complaint under sub-section (8) of section 70B is filed before the court by an officer of CERT-In whom the Director General has authorised, on the non-compliance report made under Rule 16 and the direction of the Review Committee under Rule 19.

CERT-In states its own posture at FAQ Q 23: "This power will be exercised reasonably and on occasions when the non-compliance is deliberate."

On the SEBI side, Annexure-O B.1 closes: "in case any RE does not report a cybersecurity incident to SEBI (when the RE is/ was aware of the incident) in a manner as laid down in the applicable cybersecurity framework, appropriate regulatory action may be taken by SEBI as deemed fit depending on the nature of the incident."

9. The objection you are about to hear internally

Somebody in the room will say that reporting makes this public.

Disclosure by CERT-In is governed by Rule 13 of the CERT-In Rules 2013. That is the answer CERT-In itself gives at FAQ Q 16, in terms: the disclosure of information by CERT-In "is governed by provisions of Rule 13 of CERT-In Rules, 2013 subject to applicable law."

Read Rule 13 as a whole, because it has four sub-rules and they do different work.

• 13(1) commits CERT-In to follow applicable legal restrictions, the orders of competent Indian courts and ethical practices in disclosing information, and to keep reasonable controls and internal checks to maintain confidentiality.
• 13(2) holds information that may identify the individuals, groups or organisations affected by a cyber security incident in confidence, releasing it on their explicit written consent or on the orders of an Indian competent court — and it protects the identity of the entity that reported, on the same terms.
• 13(3) permits CERT-In to share the general trends of incidents and breaches freely, to help the public resolve and prevent them.
• 13(4) is the limb to know before you quote 13(2) to your board. Beyond sub-rules (1), (2) and (3), it provides for CERT-In to disclose all relevant information to stakeholders where it is necessary or expedient in the interest of the sovereignty or integrity of India, the defence of India, the security of the State, friendly relations with foreign States, public order, preventing incitement to a cognizable offence, or enhancing cyber security in the country.

So the statutory answer to the objection is 13(2), and the honest version of it carries 13(1) and 13(4) with it. Take all four into the meeting.

10. After the filing

For a SEBI regulated entity, the incident becomes a set of dated assessment obligations: a VAPT for the incident and its closure reports at 45 days under Table 36, and a forensic audit report for any incident classified High or Critical (clause 4.1) with a maximum of 75 days from the date of reporting (clause 4.3) — both reviewed by the IT Committee before they reach SEBI.

A further post-incident obligation names who carries it out. The CSCRF's response-and-analysis guidelines, at page 126, item 5, applicability "All REs (Mandatory)", read: "REs shall conduct a compromise assessment through CERT-In empanelled IS auditing organizations."

Security Brigade has been CERT-In empanelled since 2008. What that empanelment covers, and how a CERT-In audit for websites and networks is scoped, sits on the parent site: CERT-In security audit and compliance.

11. The pack

The India incident reporting pack — CERT-In, RBI and SEBI. The divergence table above, in full, with every clause reference. The twenty Annexure I types as a tick-list. A field-by-field six-hour filing template with occurrence and detection times kept separate. The Annexure II Point of Contact form. The 180-day log production self-test against FAQ Q 37's system list. The RBI paragraph rows by entity class. The SEBI post-incident calendar with the IT Committee review points marked.

→ [Download the reporting pack]

If it is happening now

Write down the time you found out. Then work the sequence in the first hour, and the first seventy-two, and pull your logs before anyone rebuilds anything.

24/7 incident response · +91 22 4164 2220