How do I get a CERT-In compliant incident report?

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What makes an incident report CERT-In compliant?

Six elements, and the report is not compliant if any of them is missing. A precise timeline, with the time of occurrence and, separately, the time of detection, because the six-hour obligation is measured from the second. The affected systems and the data or services involved. The classification against CERT-In's Annexure I list of incident types, stating the closest match where it is not certain. The evidence examined and the findings derived from it, with the chain of custody recorded. The root cause, distinguishing the technical entry point from the control that failed to catch it. And the remediation, with the measures taken and those outstanding. The purpose of the document is not to allocate blame; it is to be a defensible record that the organisation identified, contained, reported and learned.

Why does the detection timestamp decide everything?

Because the six-hour clock is measured from when you noticed the incident or were brought to notice of it, not from when you understood it. That single distinction decides whether you are compliant, and it is why clock synchronisation and log retention are operational requirements rather than administrative ones. If your systems disagree about the time by more than a few minutes, or if the logs you need to prove detection were retained for only thirty days when CERT-In requires 180, you cannot demonstrate that you were in time, whatever the truth is. Keep NTP synchronised across the estate, and confirm that the authentication and endpoint logs covering the relevant window are both retained and readable.

What should I do in the first six hours?

Work in this order. Isolate the affected systems, and do not power them off, since volatile evidence is destroyed on shutdown. Preserve logs, memory and running processes, and take a hashed image if a forensic examination will follow. Secure the credentials, forcing resets, revoking sessions and re-issuing API, cloud and CI/CD tokens. Then file the CERT-In notification at incident@cert-in.org.in or 1800-11-4949 with what you know, identifying the system, the closest Annexure I category and the occurrence and detection timestamps. A report filed at hour four with partial facts is compliant. Waiting for certainty until hour thirty is not.

Do we need this report for anything other than CERT-In?

Frequently, yes. Auditors and clients ask for it during SOC 2 and ISO 27001 audits, because a mature incident response programme is a named control. Cyber insurers ask for the incident timeline and the forensic findings before they will consider a claim, and asking the insurer within the CERT-In six-hour window is usually a policy condition. Banks and payment partners ask for it when a breach touches transaction data. And for individuals whose money was stolen, the same factual record, with the timeline and the evidence, is what supports a complaint on cybercrime.gov.in, a call to 1930 and a compensation claim under RBI's June 2026 instructions effective 1 January 2027, which allow 85% of net loss or Rs 25,000, whichever is less, for a genuine individual victim with a gross loss up to Rs 50,000 reported within five calendar days.

What are the frequently asked questions?