CERT-In 6 Hour Reporting: A Practical Incident-Response Guide

Introduction: India's CERT-In Directions and the 6-Hour Window

When a cyber incident hits an Indian organisation, the first few hours are chaotic — and the clock is already running. Under directions issued by CERT-In (the Indian Computer Emergency Response Team) in 2022, a wide range of entities must report specified cyber incidents to CERT-In within 6 hours of noticing them or being brought to notice about them. That is a tight window for any IT or security team, and it sits alongside obligations to maintain logs and to cooperate with directions. This article is a practical walkthrough of CERT-In 6 hour reporting — what is reportable, what to report, and why preserving evidence with e-Dex (formerly Hash Calculator) should happen before and while you report, not after. This is general information for practitioners, not legal advice.

Which Incidents Are Reportable

The CERT-In directions enumerate categories of mandatorily reportable cyber incidents. Broadly, these cover unauthorised access to computer systems or data; targeted scanning, probing or compromise of critical systems and information; attacks on critical infrastructure and supervisory systems; ransomware, malware and other malicious code infections; data breaches and data leaks; attacks on servers, network appliances and applications; identity theft, spoofing and phishing; denial-of-service and distributed denial-of-service attacks; and attacks affecting cloud, IoT, mobile, big-data and similar deployments. The list is deliberately broad, so the safe approach is to treat the directions as the authoritative source and check the current text rather than relying on any summary — including this one. When in doubt about whether something qualifies, escalate and document the decision either way.

What to Report, and the 6-Hour Clock

A useful report gives CERT-In enough to understand and act: what happened (the nature and category of the incident), when it was detected, the systems and services affected, the suspected vector or root cause if known, the current impact and scope, and the actions already taken to contain it. Crucially, the 6-hour clock generally starts from awareness — from when the incident is noticed or brought to notice — not from when the attacker first got in. That makes your detection and triage process the real starting gun: a clear on-call path, a single owner for the reporting decision, and a pre-drafted reporting template all buy back precious minutes. Treat the first report as the opening of a conversation; you can supplement it as understanding improves rather than waiting for a perfect picture.

Why You Must Preserve Evidence Before and While Reporting

The instinct under pressure is to contain first and document later — but containment is exactly what destroys evidence. Rebooting a host wipes volatile memory; re-imaging a server erases the disk state; verbose logging rolls over and overwrites itself; and a hurried cleanup can quietly alter the very artifacts an investigator will need. The discipline that protects you is simple: as early as possible, compute cryptographic hashes and record trusted timestamps for your logs, captures and other artifacts, so their exact state is frozen in a way you can later prove. A cryptographic hash is a fingerprint of the file's contents; change a single byte and it changes completely, so a matching hash demonstrates the artifact has not been touched since collection. Doing this during an active incident — when you may not trust the network — is why an offline tool matters.

Building a Defensible Incident Evidence Pack

A defensible incident evidence pack is the bundle you can hand to investigators, regulators or counsel months later and still stand behind. Practically, that means: collect the relevant logs, memory and disk captures, configuration snapshots and screenshots; hash each artifact with multiple algorithms (SHA-256, SHA-512 and BLAKE3 are the modern, collision-resistant choices); record who collected what, when, and from which system; and seal the whole set with an integrity certificate so anyone can re-verify it independently. e-Dex generates that certificate fully offline on a single Windows machine and prints an explicit MATCH / MISMATCH verdict, so re-verification later is unambiguous. For the wider how-and-why of building these packs, see our companion guide on the incident-response evidence certificate and the dedicated incident-response evidence page.

Log Retention Obligations

Reporting is only half the picture; the directions also expect covered entities to enable and securely maintain logs of their ICT systems for a rolling period (commonly cited as 180 days) within Indian jurisdiction, and to produce them to CERT-In when directed. The lesson for architecture is to design logging that survives an incident: centralise logs away from the systems that may be compromised, make them tamper-evident, time-synchronise your sources, and be able to export a slice with an integrity record attached. Hashing log exports as you retain them — not only after an incident — means the moment you do need to hand them over, you already have proof they are unaltered. Confirm the exact retention period and the precise scope of covered entities against the current directions, since these are general points rather than legal advice.

Frequently Asked Questions

What is the CERT-In 6 hour reporting requirement?
Under directions issued by CERT-In (the Indian Computer Emergency Response Team) in 2022, organisations are required to report specified cyber incidents to CERT-In within 6 hours of noticing the incident or being brought to notice about it. The clock generally starts from awareness, not from when the incident began, so detection and triage processes matter. This is general information and not legal advice; always read the current directions and seek professional guidance for your situation.

Which cyber incidents are reportable to CERT-In?
The CERT-In directions list categories of mandatorily reportable incidents, which broadly include unauthorised access to systems or data, targeted scanning or probing of critical systems, compromise of critical infrastructure, ransomware and malware infections, data breaches and data leaks, attacks on servers and network appliances, identity theft and phishing, denial-of-service attacks, and attacks affecting IoT, cloud, and similar systems. The authoritative list is in the directions themselves, so check the current text rather than relying on a summary.

Why should I preserve evidence before reporting an incident?
Once you start containment, remediation, and reporting, systems get rebooted, logs roll over, and disks get re-imaged, so volatile and on-disk evidence can degrade or vanish within hours. Computing cryptographic hashes and recording trusted timestamps for your logs and artifacts as early as possible captures their exact state, so you can later prove nothing changed after collection. e-Dex lets you hash and seal those artifacts fully offline so collection itself does not depend on a network you may not trust during an active incident.

What are the log retention obligations connected to incident reporting?
The CERT-In directions require covered entities to enable and securely maintain logs of their ICT systems for a rolling period (commonly cited as 180 days) within Indian jurisdiction, and to make them available to CERT-In when directed. In practice this means designing log collection so it survives an incident, is tamper-evident, and can be handed over with an integrity record. Confirm the exact retention period and scope against the current directions, as these are general points and not legal advice.

Does hashing evidence with e-Dex require an internet connection?
No. e-Dex runs fully offline on your own Windows machine, so you can hash logs, memory captures, disk images, and other artifacts during an active incident without sending anything over the network. The files never leave your computer. A connection is only needed if you choose to apply an RFC-3161 trusted timestamp from a Time-Stamping Authority for extra assurance on the time of collection.

Conclusion

CERT-In 6 hour reporting rewards teams that have decided, in advance, who reports, what they report, and how they preserve the evidence trail while the incident is still live. The reporting is a regulatory obligation; the hash-sealed evidence pack is what lets you defend your account of events long after the dust settles. Build the habit of hashing and time-stamping your logs and artifacts at the moment of collection — offline, on a single Windows machine — with e-Dex — the Digital Evidence Integrity Suite. Download it free and make sure your evidence is ready before you need it. This article is general information for IT and security teams and is not legal advice.