CERT-In's six-hour rule: what it means when something actually happens

The CERT-In Directions issued in April 2022 contain the tightest incident-reporting clock in mainstream data regulation: six hours from noticing a qualifying incident, not six hours from confirming it, and not one business day.

Most Indian startups discover this the week it becomes relevant, which is the worst possible week to read a regulation for the first time.

Six hours from when, exactly

The clock starts when you notice the incident or are told about it — not when you have finished investigating. This is the part teams get wrong. The instinct is to establish what happened before saying anything, and that instinct will run you past the deadline every time.

The practical consequence is that your first report is expected to be incomplete. You report what you know, and you follow up. A team that understands this reports on time with three known facts; a team that does not misses the window trying to write a complete account.

Which incidents qualify

The Directions list categories rather than a severity threshold, and the list is broader than most founders expect. Among them:

• Unauthorised access to IT systems or data — the category most breaches fall into.
• Data breaches and data leaks.
• Compromise of critical systems, and website defacement or intrusion.
• Malicious code attacks, including ransomware.
• Attacks on servers, network appliances, and applications — including denial of service.
• Attacks on cloud infrastructure, and on identity or authentication systems.

Note what is absent: a materiality test. There is no "only if significant" carve-out to hide behind, which is why a documented internal triage step — is this a qualifying category, yes or no — is more useful than a severity matrix.

The obligations that are not about incidents

The same Directions carry three standing duties that have nothing to do with any particular breach, and these are the ones quietly ignored:

• Log retention — security logs kept for 180 days, and kept within India.
• Clock synchronisation — systems synced to NIC or NPL time sources, so that logs from different systems can actually be correlated.
• KYC and subscriber records — applies to VPS, cloud, VPN and similar providers, with a five-year retention period.

The log retention one has real architectural consequences if your logging is a managed service in another region, and it is far cheaper to decide that at setup than to migrate later.

Why you should raise it with buyers yourself

Here is the part Indian vendors miss. A US enterprise buyer's questionnaire will ask how quickly you commit to notifying them of a breach. The common vendor answer is something like "without undue delay" or "within 72 hours".

You are subject to a mandatory six-hour reporting duty to a national authority. That is a stronger commitment than almost any vendor offers voluntarily, and it is evidence that you must have detection and escalation capable of meeting it. Volunteering that in a security review converts a piece of Indian regulatory burden into a differentiator. Very few of your competitors will be doing this.

The caveat is that you have to be telling the truth. A six-hour duty implies someone is watching, someone is reachable out of hours, and there is a documented path from alert to report. If those do not exist, the honest move is to build them before you cite the obligation.

Incident reporting is one of those obligations that costs almost nothing while nothing is happening and is impossible to retrofit on the day it matters. Write the runbook, name the person, test the path once.