CERT-In's 6-hour incident reporting rule

On 28 April 2022, CERT-In — the Indian Computer Emergency Response Team, the national agency for responding to cyber incidents — issued Directions under section 70B(6) of the Information Technology Act, 2000. They came into force at the end of June 2022, and they set out how incidents must be reported and which records organisations must keep.

They apply to service providers, intermediaries, data centres, body corporates and government organisations. That wording is broad, and it is generally read as reaching ordinary businesses, not only large companies or technology firms. Whether it reaches yours is a question for your lawyer, but the preparation it asks for is ordinary good practice, so the sensible plan is to be ready either way.

Failing to comply with a direction issued under section 70B can be punished under section 70B(7) with imprisonment of up to one year, a fine, or both.

Not every alert is reportable. The Directions list specific types of incident in an annexure, and the list is wide. It includes targeted scanning or probing of critical systems, compromise of critical systems or information, unauthorised access to IT systems or data, defacement of or intrusion into a website, malicious code such as ransomware, attacks on servers such as database, mail and DNS servers, identity theft, spoofing and phishing, denial-of-service attacks, data breaches and data leaks, attacks on IoT devices, unauthorised access to social media accounts, and attacks on cloud systems.

A useful working rule: if someone who should not have access has touched your systems, your data or your accounts, treat it as reportable until someone qualified has decided otherwise. Deciding that it was probably nothing is how the six hours run out.

The clock starts when you notice the incident or when someone brings it to your notice — not when you have confirmed it, scoped it or understood it. An alert that arrives at eleven on a Friday night is still a six-hour alert.

That makes the deadline an organisational problem more than a technical one. Within six hours, someone has to recognise the incident as reportable, someone has to have the authority to send the report, and someone has to know how to send it. If any one of those three is being decided during the incident, the window is usually already gone.

The Directions also require you to designate a Point of Contact to interface with CERT-In, and to tell CERT-In who that is. The current reporting formats and contact details are published on cert-in.org.in. Keep a copy somewhere the person on call can reach without using the systems that might be compromised.

The Directions require logs of all your ICT systems to be enabled and kept securely for a rolling period of 180 days, within Indian jurisdiction, and to be handed to CERT-In when it asks for them. In practice that means firewall and VPN logs, web server and application logs, authentication logs, email logs, and the logs your cloud and hosting providers hold on your behalf.

Three gaps catch most small businesses. Default retention on many cloud and hosted services is shorter than 180 days, and nobody changed it. Logs are stored only on the server that gets compromised, so an attacker can delete them on the way out. And logs sit in a region outside India because that was the default when the account was created.

The fix is unglamorous: send logs to a central store that the servers themselves cannot delete from, located in an Indian region, with retention explicitly set to at least 180 days. Then check, once, that you can actually find a specific event from five months ago. Retention that has never been tested is a setting, not a capability.

All ICT system clocks must be synchronised with the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or with NTP servers traceable to them. Organisations whose infrastructure spans several countries may use another accurate, standard time source, provided it does not deviate from NIC and NPL.

This sounds like a formality and is not. An incident timeline is rebuilt by lining up events from many systems — a login here, a file change there, an outbound connection somewhere else. If those systems disagree about the time by even a few minutes, the sequence becomes guesswork, and so does any honest answer to the question of what was taken.

Name the Point of Contact and a deputy, and make sure CERT-In has been told who they are. One person is not a plan, because incidents do not wait for someone's leave to end.

Write a one-page rule for what counts as reportable, built from the list above, with a default of reporting when in doubt. Agree in advance who approves a report, and make sure that approval can happen at night, over a phone call. Approval must never become the bottleneck.

Decide how evidence will be preserved before anyone starts fixing. Wiping and reinstalling a server is the usual instinct, and it destroys exactly the logs and disk state that the report and any later investigation will need. Snapshot first, copy the logs off, then clean.

Then rehearse it once. A one-hour walk-through of a realistic scenario — the website has been defaced and the admin password no longer works — finds the missing phone number, the expired login and the person who did not know they were the deputy, while finding them costs nothing.

The Digital Personal Data Protection Act adds a separate duty, coming into force in phases under the DPDP Rules notified in November 2025: a breach of personal data must be notified to the Data Protection Board and to each affected person. A single incident can trigger both duties — a report to CERT-In about the incident, and a notification under the DPDP Act about the personal data — and they go to different bodies, with different content and on different timelines.

Plan them together, so that the person writing the CERT-In report in the fifth hour is not discovering the second obligation for the first time. Our guide to the DPDP Act covers that side in more detail.

The deadline runs from when you notice an incident, but the damage runs from when it began. An intruder found the same day leaves a short, clear story and a report that can be written in an hour. One found three months later, by a customer or by the police, leaves a long and murky one, and by then the 180-day logs may be the only record of how it started.

That is the practical case for continuous monitoring. An alert on a new administrator login, an unusual outbound transfer or a port that should not be open is what turns the six-hour window from a scramble into a procedure. Whether you build that yourself or have someone run it for you, it is the part of readiness that a policy document cannot provide.

This guide explains what CERT-In's Directions ask for and how to prepare for them in practice. It is not legal advice, and it does not tell you whether a particular incident must be reported. For that, and for whether the Directions apply to your organisation at all, speak to a lawyer about your actual facts. We help with the security and technical side of readiness — logging, monitoring, response plans and evidence handling — and we will tell you plainly when a question needs a lawyer instead.