Every organisation we audit knows the number. Six hours, from noticing a reportable incident to telling CERT-In about it, under the Directions issued in April 2022. Almost none of them can tell us who would notice, who would decide it was reportable, and who would write the email at two in the morning on a Sunday.
That gap is the whole problem. The rule is not difficult to comply with on a Tuesday afternoon. It is difficult to comply with at the only time it will ever matter.
What the six hours actually starts from
The clock runs from noticing, not from the breach. That distinction does more work than anything else in the Directions. An intrusion that began in March and was noticed in July gives you six hours from July, which sounds generous until you consider that "noticing" is rarely a single moment. An analyst sees an odd authentication pattern at 21:40. A second one correlates it with an outbound transfer at 23:15. Somebody uses the word "incident" out loud at 01:00.
Which of those started the clock? In our experience the honest answer is the first one, and organisations that argue for the third in a post-incident review tend to have a bad time. Build your process around the earliest defensible moment and you will never have to make that argument.
What counts as reportable
The Directions list twenty categories, and people fixate on the dramatic ones: ransomware, data breach, defacement. The ones that actually catch organisations out are the quiet entries. Unauthorised access to social media accounts. Attacks on IoT devices. Malicious code in an application. Identity theft and phishing affecting your users.
If you run a consumer platform, a credential stuffing campaign against your login endpoint is reportable. Most teams treat it as noise, because from inside the SOC it looks like noise. That is a compliance failure sitting quietly in your alert queue right now.
The logs requirement is the one that bites
Section 5 requires 180 days of logs, maintained within India, and produced when CERT-In asks. This is where audits fail more often than the reporting clause, because log retention is a budget decision that was made three years ago by somebody who has since left.
Two questions worth asking today. First, do your logs actually cover the systems that would matter in an intrusion, or do you have 180 days of firewall logs and thirty days of the application logs anyone would actually need? Second, if the retention lives in a cloud region outside India, you are not compliant regardless of how good the logs are.
What a working six hour capability looks like
It is four things, and none of them are technology.
A named decision maker with a named deputy, both reachable out of hours, both with the authority to say "this is reportable" without convening anybody. If that decision needs three people on a call, you will not make six hours.
A pre-written template with the fields CERT-In asks for, held somewhere reachable when your own systems may be the thing that is compromised. We have watched an organisation lose ninety minutes because the incident response plan was on the file server that had just been encrypted.
A triage rule that says what is reportable, written down in advance, in your own vocabulary rather than the Directions' vocabulary. "Any confirmed unauthorised access to a production database" is a rule an analyst at 02:00 can apply. "Data breach" is not.
One rehearsal a year where somebody is woken up. Not a tabletop over lunch. The failure modes only appear when people are tired and the on call rota is wrong.
Where this sits against everything else
If you are also subject to the DPDP Act 2023, note that the two obligations are separate and the triggers are different. A personal data breach can require notice to the Data Protection Board and to affected data principals on a timeline that has nothing to do with the CERT-In six hours. Organisations that build one process for "incidents" and assume it covers both usually discover the difference the hard way.
Start here, this month
Write the triage rule. One page, in your own words, listing what your team would report. Circulate it to the people who would be on the call.
Then check your log retention against the systems that would matter, not the systems that were easy to onboard.
Everything else can wait. Those two are what stand between a difficult night and a regulatory problem that lasts a year.