CERT-In Incident Reporting Requirements: Can Your Team Meet the 6-Hour Rule?

Six hours. That is how long Indian organizations have to report a cyber incident to CERT-In once they notice it or are told about it. Detecting an incident is only part of the challenge. The harder part is having the people, evidence and approval process ready to report within that window. This article explains the CERT-In incident reporting requirements in plain terms, uses a real Indian case to show how an incident unfolds, and gives you a six-hour drill to test your own readiness.

What the 6-hour rule says

On 28 April 2022, CERT-In issued directions under Section 70B(6) of the Information Technology Act, 2000, which took effect 60 days later. They require specified cyber incidents to be reported within six hours of being noticed or brought to the organisation’s attention.

The directions apply to service providers, intermediaries, data centres, body corporates and government organisations. 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, and CERT-In publishes a form listing the details it expects.

Section 70B(7) of the IT Act provides for imprisonment of up to one year, a fine of up to one lakh rupees, or both, for failing to comply with such directions. Source: CERT-In Directions No. 20(3)/2022-CERT-In, available on cert-in.org.in.

One clock, four stages

Teams often treat the six hours as the time to finish an investigation. It is not. It helps to separate four stages.

  • Detection or notice: Someone in the organization sees the problem, or an outsider such as a customer, vendor or researcher tells you about it. This is when the six hours begin.
  • Initial assessment: A trained person quickly judges whether this is a genuine incident and whether it falls under the CERT-In incident categories.
  • Reporting: The organization submits the report to CERT-In with the information it has at that point.
  • Further investigation: Root cause analysis, impact scoping and recovery continue after the report, and updates follow as facts become clear.

The key point is that the organization should not wait for a complete investigation before making the initial report. CERT-In’s guidance has indicated that an initial report can be made with the information available and supplemented later. Waiting for certainty is the most common way to miss the window.

Which incidents must be reported

An annexure to the directions lists around twenty incident types. It covers targeted scanning of critical networks, compromise of critical systems, unauthorised access to systems or data, website defacement, malicious code attacks, phishing and spoofing, denial-of-service attacks, data breaches and leaks, and attacks on IoT devices, cloud services and AI or machine learning systems.

Assess each incident against the applicable CERT-In categories. When the position is unclear, obtain appropriate guidance from your legal or compliance advisers or from CERT-In itself, and do it early, because the clock is already running.

A real-world example: the AIIMS Delhi ransomware attack

On the morning of 23 November 2022, the All India Institute of Medical Sciences (AIIMS) in Delhi was hit by ransomware. According to a Hindustan Times report of 27 November 2022, the first sign was a call from the emergency lab, which could not view test reports. Billing and OPD counters reported similar errors soon after.

The lesson is in the sequence. Several business symptoms appeared in different departments. They were connected into one incident, and ownership moved to the hospital’s IT teams and the National Informatics Centre. The matter was escalated to CERT-In and Delhi Police, which registered a case on 25 November, and the National Investigation Agency later joined.

The public record does not establish exactly when AIIMS reported to CERT-In, so this article does not measure the case against the six-hour rule. It is a useful illustration of how an incident starts: not with an alert that says ransomware, but with scattered, ordinary-looking faults that someone has to recognize and own.

What this means for an SOC

For security operations teams, the six hours run through a chain of handoffs. Each step needs a named owner, or time is lost between them.

Two practical points follow. First, preserving evidence early protects both the investigation and the report. The directions require logs to be kept for 180 days within Indian jurisdiction, and system clocks to be synchronised with the NTP servers of the National Informatics Centre or the National Physical Laboratory, so that timestamps agree across tools. Second, the approval step should be pre-agreed, with a named backup, so the report does not wait for one person to wake up or land.

Why readiness is a business issue

Meeting the rule is not only about avoiding penalties. A team that is ready for the six-hour window is also better prepared for the incident itself. Readiness reduces:

  • Reporting delays, because the form, contacts and approval path already exist.
  • Confusion over ownership, because everyone knows who declares and who decides.
  • Evidence gaps, because logs and timestamps are retained and trustworthy.
  • Dependency on individual employees, because every key role has a backup.
  • Escalation delays during an incident, because the route to senior management is defined in advance.

The same preparation helps with other duties. The Digital Personal Data Protection Act, 2023 and its rules add a separate obligation to notify the Data Protection Board and affected individuals after a personal data breach, and regulators such as RBI and SEBI have their own expectations for the entities they supervise. Timelines differ and some provisions are being phased in, so check the current text for each. One playbook with a single intake step is easier to run than several separate processes.

Run a six-hour drill

The best way to know whether you can meet the CERT-In incident reporting requirements is to rehearse. Take a scenario like the AIIMS one, where several departments report odd faults at once, and run it as a timed tabletop exercise. Start the clock when the first complaint arrives and work through these checkpoints.

TimeQuestion
0 to 30 minutesWho identifies and declares the incident?
Up to 2 hoursWho determines whether it must be reported to CERT-In?
Up to 4 hoursCan the available information be assembled for the report?
Up to 6 hoursWho submits the report and records the time it was sent?

Most teams find at least one blocker in their first drill. That is the point. Finding it in a rehearsal costs an afternoon, while finding it during a real attack costs far more. Record the time each step actually took and fix the slowest one first.

Your next step

This week, write down three things on one page: who can declare an incident, who approves a CERT-In report, and who is the backup for each. Then book a two-hour drill within the next month and time it honestly.

More
articles