The CERT-In directions of 28 April 2022 say service providers, intermediaries, data centres, body corporate and government organisations must report the incident types in Annexure I within 6 hours of noticing them or being told about them. If you lack full details at hour six, send what you have and follow up.
What starts the clock
The text is specific: 6 hours "of noticing such incidents or being brought to notice about such incidents". Noticing is the trigger, not confirmation of root cause and not the end of your investigation.
The FAQ addresses the late discovery case directly. If an incident sat undetected for a long time, the 6 hours still run from when you notice it. The FAQ adds that organisations are expected to deploy appropriate controls and follow reasonable security practices to detect incidents in good time.
For an engineering team, that means the on-call process needs a named person who can decide "this is a reportable type" quickly. A ticket that waits for Monday triage will miss the window.
What is on the list
Annexure I lists 20 incident types. A few that software teams meet often:
- Unauthorised access of IT systems or data
- Malicious code attacks, including ransomware and cryptominers
- Data breach and data leak
- Attacks on applications such as e-commerce
- Attacks affecting cloud computing systems and applications
- Attacks on systems related to AI and machine learning
The FAQ also picks out the cases that must meet the 6 hour window, including data breaches and data leaks, severe incidents such as DoS or ransomware on public information infrastructure, and incidents affecting the safety of people. Read the FAQ list before deciding something is out of scope.
How to report and what if details are missing
The directions give an email address, a phone number and a fax number, and point to the CERT-In website for the reporting format. The FAQ answers the "we do not know everything yet" problem: provide the information available at the time, and report more later within a reasonable time.
Two other points worth writing into your runbook:
- The FAQ says the statutory reporting duty overrides a confidentiality clause in a customer contract.
- The directions also ask each organisation to designate a Point of Contact for CERT-In and send the details in the Annexure II format.
A minimal runbook
- Keep the current CERT-In contact details and the incident form link in your runbook, and check them, since the directions say the details may be updated.
- Name the person who may declare an incident reportable, plus a backup.
- Pre-fill what you can: system names, time noticed, type from the Annexure I list, affected services, first containment steps.
- Log the exact time you noticed. The clock starts there.
- Send the first report, then schedule the follow up.
None of this replaces legal advice on your own situation, and sector regulators may add their own timelines on top.
Try it yourself
In the demo, open a finding and note how quickly you can tell which systems and components are affected. That is the information a first report needs.
Click through it at your own pace, or open it full screen.
Safeguard's asset discovery and dependency scanning can help you know what you run, so scoping an incident takes minutes rather than hours. It does not report to CERT-In for you.
Quick check
Do we wait until the investigation is finished before reporting?
No. The FAQ says to report the information available at the time and add more later.
Is an unconfirmed vulnerability reportable?
The FAQ says reporting a vulnerability on its own, unconnected with a cyber security incident, is not mandatory at present. An incident from the Annexure I list is a different matter.
Sources
Last reviewed: 19 October 2026.
