CERT-In 6-Hour Reporting: Build the Process
The CERT-In directions of 2022 require certain cyber incidents to be reported within 6 hours. A short, practised process makes that deadline realistic.
In this article
In 2022, CERT-In, India’s national computer emergency response team, issued directions on information security practices and incident reporting. One requirement stands out for most organisations: certain types of cyber incidents must be reported to CERT-In within 6 hours of noticing them or being told about them.
Six hours is not long. It covers a period when your team may still be working out what happened. Meeting the deadline reliably needs a clear process, named owners and practice. This guide explains how to build one.
1. What the rule means in practice
The directions list the types of incidents that must be reported. Check the official text for the current list and the reporting format, because the details decide what your process needs to capture. The list is broad and covers many incidents that a typical company could face.
The clock starts when the incident is noticed or brought to your attention, not when the investigation ends. That is the key point for planning. Your process must allow you to report what you know within the window, then follow up as you learn more.
The directions also cover other practices, such as keeping logs and naming a point of contact for CERT-In. Read the full text, and make sure the reporting process fits with those wider duties.
If you are unsure whether an event is reportable, treat that decision as urgent in itself. It is usually easier to explain a cautious report than a missed one.
The 6-hour clock starts when you notice the incident, not when you finish understanding it.
2. Build a short, clear process
A reporting process with a tight deadline needs to be simple enough to run under pressure. A clear sequence helps.
Detect and log.
Make sure alerts, staff reports and supplier notices reach a single place, and record the time each potential incident is noticed.
Classify quickly.
Have a short guide that helps the on-call person decide whether an event may fall within the reportable types.
Escalate to the owner.
Name a reporting owner, with a deputy, who decides whether to report and signs off the submission.
Submit what you know.
Use a prepared template to report the facts available within the window, marking what is still being investigated.
Follow up.
Provide further information as the investigation progresses, and keep a record of every update sent.
Review afterwards.
Look at what worked and what slowed you down, and improve the process.
Keep the process on one page. Store it where the team can reach it even if your main systems are affected, and include contact details for the reporting owner, the deputy and key suppliers.
Prepare the template with the fields the directions ask for, so that nobody is searching for the format at the worst moment. Fill in the fixed parts, such as company details and contacts, in advance.
3. Owners, overlaps and drills
Ownership is the most common weak point. If nobody is sure who decides to report, the 6 hours can pass in discussion. Agree the owner in advance, give them the authority to decide, and make sure leadership supports quick reporting rather than delay.
Many organisations face more than one reporting duty. A personal data breach may also need to be reported under the DPDP Rules, which expect a detailed report to the Data Protection Board within 72 hours. Regulated sectors may have their own rules. Map how these duties fit together, so that one investigation feeds every report and nobody misses a deadline.
Suppliers matter too. Many incidents start at a cloud provider, a software vendor or an outsourced service. Your contracts should require suppliers to tell you quickly about incidents that affect you, so that your own clock does not run out while you wait for them.
Then practise. A tabletop exercise walks the team through a realistic scenario: an alert arrives late on a Friday, the facts are unclear and the reporting owner is travelling. Time each step and note where people hesitate. Run the drill at least once a year, and after any major change to your systems or team.
Finally, keep records. Note when each incident was noticed, when it was reported and what was sent. Those records show that you acted on time, and they help you improve.
If you would like help building a CERT-In reporting process or running a drill, our regulatory audits team and cybersecurity audit team are happy to help.