Six hours. That is how long Indian organisations have to report specified cyber incidents to CERT-In once the incident is noticed. Not six business hours. Not six hours after legal review. Six hours on the clock — which means an incident noticed at 11 p.m. on a Sunday is due before dawn on Monday.
If your incident response plan was written for a 72-hour GDPR-style window, it will fail this test. This playbook walks through what the CERT-In Directions actually require, who they apply to, and how to build a reporting motion that survives contact with a real incident.
Where the 6-Hour Rule Comes From
In April 2022, the Indian Computer Emergency Response Team (CERT-In) issued Directions under Section 70B of the Information Technology Act. Three obligations in those Directions reshape day-to-day security operations:
- 6-hour incident reporting. Specified categories of cyber incidents must be reported to CERT-In within six hours of the organisation noticing them or being made aware of them.
- 180 days of security logs. Organisations must maintain logs of their ICT systems on a rolling 180-day basis and produce them to CERT-In on request.
- Time synchronisation. System clocks must be synced to designated NTP sources, so that timestamps in logs and reports line up when CERT-In correlates events across organisations.
The Directions apply broadly: service providers, intermediaries, data centres, body corporates, and government organisations. If you run a SaaS product, host customer data, operate a data centre, or are simply an Indian company of meaningful size, you should assume you are in scope and plan accordingly.
We cover the full obligation set in the CERT-In guide — this post focuses on the part that breaks most response plans: the clock.
What Actually Has to Be Reported
CERT-In's Directions specify categories of reportable incidents. The list is broader than many teams expect. Reportable categories include:
- Targeted scanning or probing of critical networks and systems
- Compromise of critical systems or information
- Unauthorised access to IT systems or data
- Defacement of websites or unauthorised changes such as inserted malicious code or links
- Malware and ransomware attacks, including attacks on servers and network devices
- Identity theft, spoofing, and phishing attacks
- Data breaches and data leaks
- Attacks on cloud computing systems, IoT devices, and payment systems, among other digital infrastructure
Two things stand out. First, several of these categories — targeted scanning, phishing campaigns — are events many SOCs would historically triage and close without external reporting. Under the Directions, they can be reportable. Second, the trigger is noticing the incident. The six hours do not start when you finish your investigation; they start when someone in your organisation becomes aware that a reportable event has occurred.
The Hard Part: Deciding in Hours, Not Days
The honest operational challenge is not filling in CERT-In's reporting format. It is making the report/no-report decision fast enough. A workable playbook looks like this:
1. Pre-classify incidents against the CERT-In categories
Map your existing incident taxonomy to the CERT-In reportable categories before an incident. Every incident type in your tracker should carry a flag: reportable to CERT-In, not reportable, or needs-judgement. When the SOC raises a ticket at 2 a.m., the analyst should not be reading the Directions for the first time. If you run your taxonomy in Incident Management, this mapping becomes a field on the incident record, not tribal knowledge.
2. Define "noticed" in writing
Decide, in policy, what counts as the organisation noticing an incident: an automated alert that meets defined criteria, a SOC analyst's confirmation, an employee report to the security mailbox. Document it, because in a post-incident review the timeline question will be "when did the clock start?" — and you want one defensible answer, not three competing ones.
3. Pre-draft the report skeleton
CERT-In reports ask for predictable elements: affected systems, incident type, time of occurrence and detection, and contact details. Keep a pre-filled template with your organisation's standing details so the on-call responder only adds incident specifics. At hour five, nobody should be hunting for the company CIN or the designated point of contact's phone number.
4. Empower the on-call lead to file
A six-hour window does not allow for a sign-off chain that includes legal counsel, the CISO, and a managing partner who is on a flight. Pre-authorise a small set of people — including whoever holds the on-call pager — to submit the initial report. You can always supplement a report with more detail later; you cannot un-miss a deadline.
5. Drill it on a weekend
Run at least one tabletop a year where the scenario starts at 9 p.m. on a Saturday. The exercise will surface the real gaps: nobody has the CERT-In email template, the designated contact left the company, the incident tracker is behind SSO that the on-call contractor cannot access.
The 180-Day Log Mandate Is the Quiet Workhorse
The reporting rule gets the headlines, but the logging mandate is what determines whether your report — and your subsequent cooperation with CERT-In — holds up. The Directions require security logs to be maintained on a rolling 180-day basis and produced when CERT-In asks.
Practical implications:
- Retention must be verified, not assumed. Many log pipelines silently drop sources or truncate retention when storage fills. Schedule a periodic control check: pick five critical systems, confirm 180 days of logs actually exist and are retrievable.
- Clock sync is part of evidence quality. The NTP requirement exists so that your 03:14 matches everyone else's 03:14. Drift on a domain controller or a firewall can make an otherwise solid timeline look unreliable.
- Treat log retention as an auditable control. Fold it into your ISMS control set and test it in internal audits, the same way you would test access reviews. Teams that track control testing in Audit Management typically wire the 180-day check in as a recurring evidence task with an owner and a due date.
One Breach, Two Clocks: CERT-In and the DPDPA
Here is where 2026 makes things genuinely harder. If a cyber incident involves personal data, you may now be running two notification clocks in parallel:
- CERT-In: report the cyber incident within 6 hours of noticing it.
- DPDPA: notify the Data Protection Board (and affected individuals, per the DPDPA Rules) of the personal data breach.
These are different recipients, different formats, and different framings — CERT-In wants the technical incident picture; the DPDPA regime cares about the personal data breach and the individuals affected. A ransomware event that exfiltrates a customer table triggers both. Your playbook should treat them as two distinct workstreams launched from the same incident record, each with its own owner and deadline. The DPDPA framework guide covers the data protection side in detail.
The failure mode to avoid: the team spends the first six hours debating DPDPA notification thresholds and misses the CERT-In window, which had no such threshold debate to begin with.
A Minimal 6-Hour Runbook
If you build nothing else, build this:
- T+0 (noticed): On-call analyst stamps the detection time on the incident record and checks the pre-mapped CERT-In flag.
- T+1 hour: Incident lead confirms category. If reportable or ambiguous, the report workstream starts now — ambiguity gets resolved in parallel, not before.
- T+3 hours: Draft report assembled from the template; facts marked as confirmed or preliminary.
- T+5 hours: Report submitted to CERT-In through the prescribed channel. If personal data is implicated, the DPDPA workstream is already running with its own owner.
- T+6 hours onward: Continue investigation; supplement the report as facts firm up; preserve logs beyond routine rotation for the affected window.
Then schedule the retro. Every real or drilled activation should produce at least one improvement to the runbook.
Where Tooling Helps (and Where It Doesn't)
No platform makes the six-hour judgement call for you. What a GRC platform does do is remove the friction that consumes the six hours: a single incident record with the CERT-In category mapping built in, escalation timers that page the right owner, the report template attached to the workflow, and an audit trail showing exactly when the incident was noticed and reported. Compliance Enablers ships this as part of Incident Management, connected to the control evidence and audit programmes the rest of your ISMS already runs on.
If you want to pressure-test your current incident response against the CERT-In clock — or stand up the runbook above in a structured tool — book a demo and we will walk through it with your scenarios.
This is general information, not legal advice. Consult counsel for your organisation's specific obligations under the CERT-In Directions and the IT Act.