It is 2:07 AM. Your monitoring tool flags unusual outbound traffic from a database server. By the time an analyst confirms that data is leaving the network, it is nearly 3 AM. Under the CERT-In Directions issued in April 2022 under Section 70B(6) of the Information Technology Act, the clock for reporting that incident started when you noticed it, not when you finished investigating it. You have six hours.

Many Indian organisations still treat this requirement as a paperwork item that Legal or Compliance will handle after the technical team contains the problem. That sequence does not work. Six hours is short enough that reporting has to be a rehearsed, built-in step of your incident response process, not an afterthought.

What the Directions actually require

The Directions are broader than most people remember. The headline item is the six-hour reporting window, but the same document contains several other obligations that auditors and regulators increasingly look at together:

  • Incident reporting within six hours of noticing an incident, or of it being brought to your notice, to CERT-In. The annexure lists the reportable incident types, including unauthorised access to IT systems or data, data breaches and leaks, ransomware, targeted scanning, compromise of critical systems, attacks on cloud and IoT infrastructure, and several others.
  • Log retention. Logs of all ICT systems must be enabled and retained for a rolling period of 180 days, maintained within Indian jurisdiction.
  • Time synchronisation. System clocks must be synchronised to the NTP servers of the National Informatics Centre or the National Physical Laboratory, or to sources traceable to them. Without consistent time, correlating events across systems during an investigation becomes unreliable.
  • A designated point of contact for interaction with CERT-In.
  • Additional retention duties for certain categories such as data centres, VPN providers and cloud service providers, which must keep specified subscriber and registration information for longer periods.

If you operate in India, even as a mid-sized services company, you should assume these apply to you unless counsel has advised otherwise.

Why the six-hour window is harder than it sounds

On paper, filing a report looks simple. In practice, teams stumble on the same few problems.

Nobody knows who decides that something is an incident. A suspicious alert is not automatically a reportable incident, but the line is blurry. If the decision requires a meeting of three senior people who are all asleep, the clock keeps running. Organisations that handle this well define in advance who has the authority to declare an incident, and under what conditions.

Evidence is not ready when you need it. The 180-day log requirement is only useful if logs are complete, searchable and stored somewhere the incident response team can reach quickly. We often see log sources missing: a firewall that was never forwarding to the SIEM, a cloud workload with logging disabled by default, a SaaS application whose audit log is not exported anywhere.

Initial reports are treated as final reports. You do not need a complete root-cause analysis within six hours. You need to report what you know, state clearly what you do not yet know, and follow up. Teams that wait until they have a full picture miss the window.

Vendors and third parties are forgotten. If your managed service provider detects an incident on your behalf, who reports, and when does your clock start? Contracts rarely answer this question unless someone thought about it beforehand.

Building a SOC that can meet the window

A security operations capability, whether in-house or outsourced, can be made CERT-In ready with a handful of practical steps.

1. Write a reporting playbook, not just a policy. The playbook should say who classifies the event, who approves reporting, who files it, what template to use, and what information goes in the first submission. Keep it to a page or two. During a real incident nobody reads a twenty-page document.

2. Map your log sources against the 180-day requirement. Build a simple register: system, log type, where it is stored, retention period, location of storage, owner. Gaps in this register are gaps in your compliance posture. Pay particular attention to cloud environments, identity providers and endpoint tools.

3. Fix time synchronisation once, centrally. Standardise NTP configuration across servers, network devices, cloud instances and appliances. Document which sources you use. This is one of the cheapest controls to implement and one of the easiest for an assessor to verify.

4. Define incident severity and reportability criteria. Create a short decision tree that maps incident types from the CERT-In annexure to your own severity levels. Anything that matches a listed type triggers the reporting workflow automatically, rather than waiting for debate.

5. Test the whole chain at night. Run a tabletop exercise that starts at an inconvenient hour and measures how long it takes to reach the point of filing. Most teams discover that their first run takes much longer than six hours. That is the purpose of the exercise.

6. Align contracts with the requirement. Update agreements with managed security providers, cloud vendors and other critical suppliers so they commit to notifying you promptly, with enough detail to support your own reporting.

Common mistakes we see

  • Treating CERT-In compliance as a Legal-only matter, with no technical team involvement.
  • Retaining logs for 180 days but storing them outside India without checking the requirement.
  • Having a reporting email address in the policy that nobody has ever tested.
  • Assuming the cloud provider's default logging is sufficient evidence.
  • Failing to record the time an incident was first noticed, which makes it impossible to demonstrate compliance later.

How this connects to your wider programme

CERT-In requirements overlap with other frameworks you may already be pursuing. ISO 27001 expects an incident management process and log monitoring. SOC 2 expects evidence of detection and response. Sector regulators such as the RBI and SEBI have their own incident reporting timelines. Building one well-tested incident response capability that satisfies all of them is far more efficient than maintaining separate procedures for each.

A quick self-check

Ask your team these questions today:

  1. Who can declare a reportable incident at 3 AM, and do they know it?
  2. Where is the contact for CERT-In documented, and when was it last verified?
  3. Can we produce 180 days of logs for our critical systems within an hour?
  4. Are all our systems synchronised to an approved time source?
  5. When did we last rehearse the full reporting chain?

If you hesitated on any of these, you have work to do.

Get ready before the incident, not during it

F9 Infotech helps Indian organisations assess their CERT-In readiness, close log and time-sync gaps, write usable reporting playbooks and rehearse them through realistic exercises. Book a free CERT-In incident-readiness check with F9 Infotech and find out whether your SOC could meet the six-hour window tonight.

This article is general information, not legal advice. Check the current text of the CERT-In Directions and any applicable sector rules with your counsel.