For a covered Indian organisation, certain cyber incidents must be reported to CERT-In within six hours of noticing them or being informed of them. That is a reporting window, not a deadline to finish containment or establish the complete cause. Readiness means recognising a potentially reportable incident and reaching an authorised decision-maker while the investigation is still developing. CERT-In Directions, clause (ii)
CERT-In incident reporting and DPDP personal data breach notification are separate processes. Assess the incident against each applicable framework and its commencement provisions; submitting one report should not be treated as satisfying every notification obligation.
How quickly must an Indian company report a cyber incident?
Within six hours of noticing the incident, or of being brought to notice of it. The CERT-In incident reporting requirements are set out in a direction issued on 28 April 2022 under section 70B(6) of the Information Technology Act, in force since 27 June 2022. They are not new, and they are not a proposal.
Reports go to CERT-In by email at incident@cert-in.org.in, by phone on 1800-11-4949, or by fax on 1800-11-6969. The current reporting formats are published on the CERT-In website and change from time to time, so the template you keep on file is worth re-checking once a year.
The operational consequence is simple: six hours is too short for a process that starts by scheduling a meeting. Decide the escalation route in advance, including who can act outside normal working hours.
Waiting for certainty about the full scope can delay a required report. Escalate the facts available and distinguish confirmed information from what is still being investigated.
Which incidents actually have to be reported?
Annexure I lists reportable incident categories, including unauthorised access, malicious code, ransomware, data breaches and attacks involving critical systems. Use the actual list and FAQ guidance when making the reporting decision; the examples here are not an exhaustive replacement.
Assess incidents against the reportable categories and the accompanying CERT-In FAQs. Do not assume every routine scan has the same reporting treatment, or that absence of confirmed loss removes the need to assess an incident. Write the decision rule in advance and identify who can apply it promptly.
Is six hours the only clock?
No. Incident reporting sits alongside log retention and, for specified service providers, customer-record requirements. The reporting clock starts during an incident; evidence retention and access arrangements must already be working beforehand.
Where do the logs have to live?
The Directions require rolling 180-day ICT log retention and refer to Indian jurisdiction. FAQ 35 also permits overseas storage if logs can be produced to CERT-In within a reasonable time; FAQ 36 addresses providers serving users in India. Read these together when documenting storage, access and retrieval arrangements. CERT-In FAQs 35–37
A logging dashboard is not evidence that the organisation can retrieve every required record. Test an export covering a past incident window, check timestamps across systems and confirm that a deputy can obtain the same evidence when the primary administrator is unavailable.
Check the clock-synchronisation requirements and permitted traceable sources against the Directions and FAQs. Test timestamp consistency across the systems needed for an incident timeline.
Who does this apply to?
Check the covered categories in the Directions: service providers, intermediaries, data centres, body corporates and government organisations. Assess the actual entity and service rather than relying on a broad assumption about company size or location.
Clause (v) specifies customer-record duties for data centres, VPS, cloud and VPN service providers, including retention for five years or longer as required by law after cancellation or withdrawal of registration. Check the listed records and the FAQ’s distinction between covered VPN services and corporate VPNs.
Clause (vi) separately addresses KYC and financial-transaction records for virtual-asset service providers, exchanges and custodian wallet providers. It specifies five-year retention; do not apply the customer-registration cancellation trigger from clause (v) indiscriminately to these records.
Everyone in scope must also designate a point of contact for CERT-In, and keep those details current.
What does being ready actually look like?
Six things, and five of them are done long before anything happens.
A named reporting contact and deputy. Synchronised clocks. Documented log retention and retrieval arrangements. A written rule for assessing reportable categories without waiting for a committee. A reporting template that distinguishes confirmed facts from unknowns. And one rehearsal, because the first attempt should not happen during a real incident.
The detail, for whoever needs it
The linked Directions establish the duties, and the FAQs clarify their application. The preparation workflow is a practical recommendation.
- The direction — CERT-In direction No. 20(3)/2022-CERT-In, 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000. In force from 27 June 2022.
- The six-hour window, and the reporting channels — the direction, clause (ii).
- The list of reportable incident types — Annexure I to the direction, which refers to rule 12(1)(a) of the Information Technology (CERT-In and Manner of Performing Functions and Duties) Rules, 2013.
- Log retention and location — Directions clause (iv), read with FAQs 35–37.
- Clock synchronisation to NIC or NPL NTP servers — the direction.
- Provider customer records — clause (v); virtual-asset KYC and financial-transaction records — clause (vi). These are distinct provisions.
- Consequences of not complying — section 70B(7) of the Information Technology Act, 2000.
- CERT-In has also published FAQs on the direction. Where an obligation is unclear for your particular setup, that is the first place to look.
This article explains the direction in general terms. It is not legal advice, and it is not a substitute for counsel on your own position.
A reporting workflow to rehearse
- Detection owner: preserve the initial alert and record when the incident was noticed or brought to notice. Keep the evidence and time zone clear; the timestamp must not be silently replaced by the time an investigator later confirmed the full scope.
- Incident lead: assess the reportable category and available facts, initiate containment and identify unknowns. The reporting contact and deputy should have access to the current submission format and approved communication route.
- Authorised reporting contact: submit the available information within the applicable window and preserve the submission record. FAQ 30 permits follow-up information; the initial report need not wait for a completed forensic investigation.
- Follow-up owner: maintain a timeline of corrections, new findings and information supplied. Exercise the process outside office hours and measure handoff delays, not just the time the alert appeared in a dashboard.