CERT-In Incident Reporting: The Six-Hour Runbook

CERT-In incident reporting starts the moment someone notices a listed incident, not when you have confirmed it. Direction (ii) of the CERT-In Directions of 28 April 2022 requires reporting within 6 hours of noticing such incidents or being brought to notice about them — by email to incident@cert-in.org.in, by phone or by fax, with whatever you have. This runbook covers the execution: the clock, the types, the fields, the sender, and the logs that make your answers possible.

What actually starts the clock

The operative words in Direction (ii) are "within 6 hours of noticing such incidents or being brought to notice about such incidents". Two consequences teams get wrong under pressure:

Noticing is not confirming. No triage allowance is written into the text; the clock does not wait for forensics or a vendor. CERT-In's answer on long-undetected incidents keeps the window pinned to the moment of noticing and puts the burden of earlier detection on you (FAQ 24).

"Brought to notice" includes other people's evidence. A customer emailing screenshots of your data, a researcher's disclosure, a bank's fraud team calling — each starts the clock. Make it a standing rule that the timestamp is the earliest of the alert firing in a monitored system, the ticket being raised, or the inbound message arriving, recorded in writing at the time.

The duty does not move with the contract. It is statutory, overrides any confidentiality clause by virtue of section 81 of the IT Act, 2000 (FAQ 22), and applies to all entities in so far as reporting a cyber incident is concerned (FAQ 31). If your processor is breached, the duty to report is still yours. Do not spend the window arguing.

Which of the 20 Annexure I types are reportable

Annexure I lists twenty types of incident that must be reported; the May 2022 FAQs explain each. All twenty carry the six-hour clock under Direction (ii). The priority list further down is about what must go in the mail when facts are incomplete, not about which types are reportable; the column below is triage judgement only.

Two edges worth settling now:

• A vulnerability is not an incident. Reporting a vulnerability as a standalone, in isolation and unconnected with a cyber security incident, is not mandatory at present (FAQ 15). Test findings do not go to CERT-In; evidence someone exploited one does.
• Intermediaries carry more, not less. CERT-In expects them to report incident types not listed in the Directions or the 2013 Rules, considering nature, severity and impact (FAQ 10).

Where the call is close — is this a reportable data breach, which group company files — take it to counsel and default to reporting meanwhile.

Channels, and the form nobody tells you is optional

Direction (ii) names three channels: email to incident@cert-in.org.in, phone on 1800-11-4949, and fax on 1800-11-6969. CERT-In publishes an incident reporting form, and its own footnote settles a question that costs teams an hour: it is not mandatory to fill or sign the form, and incidents may be reported by providing the relevant information in the communication itself or in any readable form. Use the form's field list as your checklist and write it into the body of the mail.

One correction, because it is commonly misquoted: Annexure II is not the incident format. It is the Point of Contact format, sent to info@cert-in.org.in.

What to gather

The "yes" rows are inventory work, not incident work. If you are building an asset register at hour two, the window is lost.

Who submits, and what a named point of contact means in practice

Direction (iii) requires every service provider, intermediary, data centre, body corporate and Government organisation to designate a Point of Contact in the Annexure II format, and states that all CERT-In communications seeking information and providing directions shall be sent to it — including providers serving users in India without a physical presence here (FAQ 29). Operationally:

• The PoC is your inbound channel: use a monitored group mailbox alongside the named individual, so a direction cannot land in a departed employee's inbox.
• Nothing restricts submission to the PoC. Give two or three people standing authority to file; an approvals queue is the commonest reason a window is missed.

Hour five, and the facts are still unclear

CERT-In accommodates this: entities may provide information to the extent available at the time of reporting, and additional information may be reported later within reasonable time (FAQ 30). The same answer sets the priority list — what must go in regardless of completeness:

• severe-nature incidents such as DoS, DDoS, intrusion, or spread of a computer contaminant including ransomware, on any part of the public information infrastructure including backbone networks
• data breaches or data leaks
• large-scale or most frequent incidents, such as intrusion into computer resources or websites
• cyber incidents impacting the safety of human beings

Write the first report as a notification, not a conclusion. A precise "unknown" beats an estimate you will retract.

What happens after you send it

Under Direction (iii), CERT-In may order you to take action, provide information or give assistance, in a format it specifies — up to and including near real-time — and within a timeframe that must be adhered to. A requisition for logs comes from an officer of CERT-In not below the rank of Deputy Secretary to the Government of India (FAQ 38).

Failure to provide information called for, or non-compliance with a direction under section 70B(6), is punishable under section 70B(7) with imprisonment up to one year or a fine up to one lakh rupees, or both — a power CERT-In says will be exercised reasonably, where non-compliance is deliberate (FAQ 23).

There is no second report to file today. A breach now is a CERT-In matter and only a CERT-In matter: the DPDP Act's breach-intimation duty, under which a Data Fiduciary must give the Data Protection Board and each affected Data Principal intimation in the prescribed form and manner (section 8(6)), is not yet in force.

The prescription arrived with the DPDP Rules, 2025. Both notifications are dated 13 November 2025 on their face, G.S.R. 843(E) for the Act's sections and G.S.R. 846(E) for the Rules; the Government's own backgrounder says 14 November (PIB), so read a one-day divergence into any date derived from it. Rule 1(2) to (4) of G.S.R. 846(E) sets two deferral tranches on top of what started immediately. Definitions, the Board provisions and the rule-making power started on publication. Consent Manager registration follows at twelve months. The substantive duties — Rule 7 on breach intimation, notice and consent, reasonable security safeguards, Data Principal rights, cross-border transfer — commence at eighteen months, which the same divergence puts at 13 or 14 May 2027. SecureRoot's compliance pages use the earlier reading: 13 May 2027.

DPDP is therefore a build, not a runbook. Until then, make the future duty cheap: know which systems hold personal data, hold the contact details you would need to notify, and record in every incident whether personal data was involved. Our DPDP Act compliance checklist covers the surrounding duties.

The logs and clocks that decide whether you can answer

Direction (iv) requires you to enable logs of all ICT systems and maintain them securely for a rolling 180 days within Indian jurisdiction, and to provide them with an incident report or when directed. The FAQs add nuance: logs may be stored outside India as long as the obligation to produce them is met in reasonable time (FAQ 35), while any provider serving users in the country must enable and maintain logs in Indian jurisdiction (FAQ 36). Where you sit between those is a question for counsel.

CERT-In's illustrative log list — firewall, IPS, SIEM, web, database, mail, FTP and proxy servers, event logs of critical systems and applications, ATM switches, SSH and VPN — is explicitly not exhaustive, and both successful and unsuccessful events must be recorded (FAQ 37).

Direction (i) requires all ICT system clocks to be synchronised with the NTP servers of NIC or NPL, or servers traceable to them. CERT-In lists samay1.nic.in and samay2.nic.in for NIC and time.nplindia.org for NPL, confirms clocks need not be set to IST, and requires time zone to be recorded alongside time (FAQ 40 and FAQ 43). Unsynchronised clocks are why a six-hour report reads as guesswork: if you cannot correlate a proxy log to a firewall log to an authentication event, you cannot answer the follow-ups.

Hours 0 to 6: the checklist

Sending at hour five rather than six leaves room for a mail failure.

Where SecureRoot fits, and where we do not

Plainly: SecureRoot is not CERT-In empanelled, and we do not file incident reports on a client's behalf. The report comes from the affected entity or someone it authorises, and the statutory duty sits with you.

What we do is the work that makes the six hours survivable. Our VAPT engagements are manual and exploit-driven, with a proof of concept for every finding and a retest included, so the exposure picture you need at hour one already exists; critical findings reach you within three hours. We hold ISO/IEC 27001:2022 certificate IN60432E and ISO 9001:2015, registered office in Kanpur and a branch in Greater Noida West. Our managed SOC services cover detection and retention, types of penetration testing is the starting point for scope, and our CERT-In Directions compliance guide covers the obligations in full. Not legal advice.

Frequently asked questions

When exactly does the CERT-In six-hour clock start?

It starts when you notice the incident or when it is brought to your notice, not when you confirm it. Direction (ii) of the CERT-In Directions of 28 April 2022 uses that phrasing, and CERT-In's FAQ on incidents that stayed undetected for a long time keeps the window tied to the moment of noticing rather than the moment of compromise. Practically, take the earliest of three timestamps: the alert firing in a system a person actually monitors, the ticket being created, or an external party's message arriving. Write it down immediately, with the time zone, because it is the fact you will be asked to justify. Triage time is not deducted. If the classification is arguable, treat the event as reportable and start the timer; a supplementary note can narrow scope later, but a window spent debating cannot be recovered.

Do we have to use the CERT-In incident reporting form?

No. CERT-In's own reporting form carries a footnote stating that it is not mandatory to fill or sign it, and that incidents may be reported by providing the relevant information in the communication itself or in any other readable form. The reporting entity may also add information beyond the form's fields. So at hour five, an email to incident@cert-in.org.in containing the facts is a valid report; do not lose time hunting for a PDF editor or an approval signature. Treat the form's field list as your checklist instead and write those fields into the body of the mail: reporter and affected entity, incident type from Annexure I, whether the system is mission critical, domain or URL, IP, operating system, cloud details, location, ISP, a brief description, and the occurrence and detection timestamps. Keeping that list in the runbook rather than in someone's head is what turns hour five from a scramble into a paste.

What if we do not have the full picture within six hours?

That is the expected case, and CERT-In allows for it. Its FAQ on incomplete information states that entities may provide information to the extent available at the time of reporting, and that additional information may be reported later within reasonable time. The same answer sets a priority list of what must go inside the six hours regardless of completeness: severe-nature incidents such as DoS, DDoS, intrusion or ransomware on any part of public information infrastructure including backbone networks; data breaches and data leaks; large-scale or frequently recurring incidents such as intrusion into computer resources or websites; and incidents affecting the safety of human beings. Write the first submission as a notification, not a conclusion: detection timestamp, systems in scope so far, what you have contained, and a clear statement that root cause and full scope remain under investigation.

Who in the organisation is allowed to submit the report?

The Directions require you to designate a Point of Contact in the Annexure II format, and state that all CERT-In communications seeking information or giving directions for compliance will be sent to that Point of Contact. That governs what comes in; nothing in the text makes the PoC the only permitted sender. In practice, give two or three named people standing authority to file without an approval chain, because an approvals queue is the most common reason a six-hour window is missed. Keep the PoC record current — name, designation, organisation, office address, email, mobile, office phone and fax, sent to info@cert-in.org.in and updated as people change — and use a monitored group mailbox alongside the named individual, so a direction from CERT-In cannot land in a departed employee's inbox and sit there unread.

Is a finding from a penetration test reportable to CERT-In?

Generally no. CERT-In's FAQ states that reporting of a vulnerability as a standalone or in isolation, unconnected with a cyber security incident, is not mandatory at present. So a SQL injection or a broken access control that your testers found and you are fixing does not go to CERT-In. What changes the answer is evidence that someone already exploited it: unauthorised access, a data breach or leak, injected code on a live site, or a compromised system are all Annexure I types and start the clock. That is why a test report distinguishing exploited from merely exploitable is worth having, and why testers should flag indicators of prior compromise separately. Where the distinction is genuinely unclear — a web shell of unknown age found during testing, say — treat it as an incident, start the clock, and take the legal question to counsel afterwards rather than during.

Next step

If the honest answer to "could we have filled the gather table at hour one" is no, the gap is inventory and exposure, not paperwork. A scoped VAPT engagement gives you the exposure picture the six-hour window assumes you already have. Start with a 30–45 minute scoping call; you get a written scope, timeline and fixed price before anything begins.