CERT-In 6 Hour Reporting: 2026 Compliance Playbook for India

For most Indian organisations the hard part of an incident is not the malware — it is the clock. CERT-In 6 hour reporting gives you six hours from the moment an incident is noticed to file with India’s national computer emergency response team, and that window almost always opens at the worst possible time: a Friday night, mid-festival, while your on-call analyst is still confirming whether the alert is real. The legal basis is firm. The CERT-In Directions were issued on 28 April 2022 under Section 70B(6) of the Information Technology Act 2000 and took effect on 28 June 2022, and four years on they remain the baseline every CISO, compliance lead and IT head in India is measured against. This playbook covers who the Directions bind, what starts the clock, the log-retention and time-sync mandates that sit underneath, how to build a workflow that holds at 2 a.m., and how all of this interacts with DPDP breach notification.

Who the Directions actually apply to

The scope is deliberately broad. The Directions bind service providers, intermediaries, data centres, body corporates and government organisations — which in practice means almost every entity running ICT systems that touch Indian users or data. There is no revenue threshold and no sector carve-out; a 30-person SaaS startup is as much in scope as a listed bank. If you operate a VPS, cloud or VPN service, additional obligations apply, including retention of specified subscriber and KYC records for five years. The practical takeaway for most readers: assume you are in scope, and stop looking for an exemption that is not there. If you are still mapping your obligations across frameworks, our India compliance overview shows where CERT-In sits alongside RBI, SEBI and DPDP requirements.

What starts the six-hour clock

The clock starts when an incident is noticed or brought to your notice — not when it is fully understood, root-caused or contained. This is the single most misread part of the regime. Teams routinely wait until they have a clean forensic picture before filing, and by then the window has long closed. CERT-In specifies roughly twenty categories of reportable incident, and the list is expansive: targeted scanning and probing of critical networks, unauthorised access to systems or data, website defacement and intrusion, malicious code and ransomware attacks, identity theft, spoofing and phishing, denial-of-service and DDoS, attacks on critical infrastructure and SCADA systems, attacks on IoT and emerging-technology deployments such as AI, blockchain and drones, and data breaches and data leaks. Severity is not a filter — the obligation attaches to the category, not the blast radius. Build your detection-to-decision path around a simple question: does this match a reportable category? If yes, the report goes out within six hours regardless of how small it looks. Our CERT-In Directions guide breaks down each category with examples drawn from Indian incidents.

The 180-day log and NTP mandates underneath

Reporting fast is only half the regime. The Directions require you to enable logs of all your ICT systems and maintain them securely for a rolling period of 180 days, within Indian jurisdiction. That jurisdiction clause matters: logs parked in a US or EU region of your cloud provider do not satisfy it on their own — you need a copy retained in India. The Directions also mandate synchronising all system clocks to the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or a traceable source. This sounds like a footnote until you are reconstructing an incident timeline across a dozen systems whose clocks drift by minutes — at which point unsynchronised time makes your evidence near-useless and your report incoherent. Treat both as standing controls, not incident-time scrambles. Verify NTP sync in your build baseline and confirm 180-day retention with India-resident storage as part of every quarterly review. If you are unsure your logging actually covers the systems CERT-In cares about, a scoped assessment via our VAPT services will surface the gaps before an incident does.

Building a reporting workflow that holds at 2 a.m.

A compliant workflow has five moving parts, and the time to build them is now — not during the incident. First, detection: your SOC, SIEM or managed provider must be able to flag a reportable-category event and escalate it without waiting for full triage. Second, classification: a named decision-maker (not a committee) maps the event to a CERT-In category and makes the file/no-file call against the clock. Third, the report itself: CERT-In accepts reports by email to [email protected], by phone, and through its portal, using the prescribed incident-reporting format — keep a pre-filled template covering who is reporting, when the incident was noticed, what happened, what was affected and what actions you have taken. Fourth, a RACI: write down, in advance, who is Responsible for filing, who is Accountable for the decision, and who must be Consulted and Informed — legal, the DPO, and leadership. Fifth, evidence handling: preserve logs, images and indicators with chain-of-custody discipline from the first minute, because your initial six-hour report is rarely the last word and CERT-In may seek follow-up information. Rehearse this path in a tabletop at least twice a year; the first time you run it should never be the real thing. Our CERT-In readiness checklist turns these five parts into a verifiable task list.

Where CERT-In meets DPDP breach notification

Indian CISOs now face two reporting regimes that can fire from the same event, and conflating them is a common and costly mistake. CERT-In reporting goes to the national CERT within six hours and is concerned with cyber incidents broadly. DPDP breach notification is a separate obligation: when personal data is breached, the Digital Personal Data Protection Act requires notifying the Data Protection Board of India, on a different timeline and to a different authority. One ransomware event that encrypts a customer database can trigger both — a CERT-In report and a DPDP breach notification — and your workflow must branch accordingly rather than treat them as one filing. Map this dependency explicitly in your incident-response plan so the personal-data assessment runs in parallel with, not after, the CERT-In clock. For the data-protection side, our DPDP compliance guide and our breakdown of the DPDP Rules 2025 deadlines set out what the Board expects. And because ransomware is the event most likely to trip both regimes at once, our analysis of ransomware’s operational impact in India is worth reading alongside this playbook.

The takeaway

CERT-In 6 hour reporting is not a documentation exercise you complete once and file away — it is an operational capability you either have or you do not, tested the night an alert fires. The Directions have been in force since June 2022, and non-compliance can attract action under Section 70B(7) of the IT Act, which provides for imprisonment of up to one year and/or a fine. But the real cost of getting this wrong is rarely the statutory penalty; it is the credibility hit of telling a regulator, a customer or a board that you noticed the breach and then sat on it past the deadline. Get the standing controls right — 180-day India-resident logs, NTP sync, a named decision-maker, a pre-filled template, and a tested RACI — and the six-hour window stops being a panic and becomes a procedure. If you want a second set of eyes on whether your logging, detection and response actually meet the mandate before you are tested in anger, talk to RingSafe about a CERT-In readiness review.