Skip to main content
← BlogIndia

CERT-In's 6-hour rule, explained

Any company operating in India must report a cyber incident to CERT-In within 6 hours. The rule has been in force since June 2022, and it is still the compliance obligation most often misunderstood — usually in the direction of doing too little, occasionally in the direction of very expensive advice that the rule does not require at all.

This post covers what the rule says, when the clock starts, what has to be reported, and the one myth worth killing.

Where the rule comes from

Direction No. 20(3)/2022, issued by CERT-In under the Ministry of Electronics and Information Technology on 28 April 2022, effective 60 days later — so from late June 2022. Its legal basis is section 70B(6) of the Information Technology Act, 2000. Non-compliance may invite punitive action under section 70B(7) of that Act.

Who it binds

The Direction is addressed to service providers, intermediaries, data centres, body corporates and Government organisations. In practice that covers essentially every company operating in India, at any size. There is no revenue threshold, no headcount threshold, and no sector carve-out. A ten-person software company is a body corporate.

The 6-hour clock, and when it actually starts

The wording is the part that matters:

within 6 hours of noticing such incidents or being brought to notice about such incidents

Two triggers, not one. The second is the one that catches businesses out. The clock can start when somebody tells you — a security researcher, a customer, a payment partner, a regulator — and it starts then whether or not your own monitoring saw anything. You do not get to begin counting from the moment you finish confirming the report.

Six hours is short enough that it cannot be improvised. The realistic answer is a decision already made in advance: who is allowed to declare an incident, who sends the report, and what goes in it. That is a one-page procedure, not a project.

Reports go to CERT-In by email at incident@cert-in.org.in, by phone on 1800-11-4949, or by fax on 1800-11-6969.

What has to be reported

Annexure I to the Direction lists twenty reportable incident types. Not a handful. They include unauthorised access to systems or data, compromise of critical systems, website defacement, ransomware and other malicious code, attacks on database, mail and DNS servers, phishing and identity theft, denial-of-service attacks, attacks on IoT devices, attacks affecting digital payment systems, fake or malicious mobile apps, unauthorised access to social media accounts, and attacks on cloud, big data, blockchain, drone, 3D printing, AI and machine-learning systems.

Two entries worth noting: data breach and data leak are listed separately. A leak with no attacker — an exposed storage bucket, a misconfigured dashboard — is its own reportable type.

Also on the list, and easy to dismiss: targeted scanning or probing of critical networks and systems. Scanning is reportable when it is targeted at critical systems.

The five obligations that come with it

The 6-hour rule is one of six directions, and the others are what make the reporting possible:

  • Clock synchronisation. ICT system clocks must be synchronised to the NTP servers of the National Informatics Centre or the National Physical Laboratory, or to servers traceable to them. Entities spanning multiple geographies may use another accurate standard time source, provided it does not deviate from NPL and NIC. Unsynchronised clocks make a log timeline unusable, which is why this direction sits first.
  • A designated Point of Contact. In the format at Annexure II, kept up to date. All CERT-In communication goes through that person.
  • 180 days of logs, retained within Indian jurisdiction. Logs of all ICT systems, maintained securely on a rolling 180-day basis, and provided to CERT-In with an incident report or when ordered.
  • Five years of subscriber records — for data centres, virtual private server providers, cloud service providers and VPN providers. Validated names and addresses, period of hire, IPs allotted, registration timestamps, purpose and ownership pattern.
  • Five years of KYC and transaction records — for virtual asset service providers, exchange providers and custodian wallet providers, detailed enough that individual transactions can be reconstructed.

There is also a standing duty to provide information or assistance when CERT-In orders it, in the format and timeframe specified — which can be near real-time. Failing to do so is treated as non-compliance in its own right.

The myth: CERT-In does not require your servers to be in India

This one is worth being precise about, because getting it wrong is expensive.

Direction (iv) localises logs. The words are "maintained within the Indian jurisdiction", and they attach to the 180-day log store. Nothing in the Direction requires primary servers, databases or application hosting to be in India.

Data-localisation duties do exist in Indian law. They are sectoral — the Reserve Bank of India's payment-system data directive is the well-known one — and they apply to the entities and data those rules name. They are not a general CERT-In obligation.

So a company hosting its application outside India is not in breach of the CERT-In Directions for that reason alone. Its 180-day log store does need to sit within Indian jurisdiction. Those are different problems with very different price tags, and being told to relocate an entire production estate on CERT-In grounds is advice worth questioning.

What to do about it

Four things, in order:

  1. Synchronise your clocks to NIC or NPL, or to a traceable source.
  2. Name a Point of Contact and file the Annexure II format.
  3. Get 180 days of logs into an India-resident store, and check your retention actually reaches 180 days rather than the default your logging tool shipped with.
  4. Write the six-hour procedure before you need it: who declares, who reports, what the report says, and where the details are kept.

None of that is difficult. All of it is slow to arrange during an incident.

Kaitara Security helps businesses in India meet the CERT-In Directions — log retention, incident procedures and the readiness evidence behind them. Details: CERT-In Compliance.