CERT-In Compliance: Directions, 6-Hour Incident Reporting & Audit Guide

The clock starts before you know you have been hit. That is the part most boards do not grasp about CERT-In. When a ransomware note lands on a Monday morning, or your SOC flags data exfiltration from a payments API, the six-hour countdown for reporting to CERT-In began at the moment of detection — not at the moment your legal team finished arguing about wording. We have watched organisations burn four of those hours drafting a perfect email that no one asked for, then miss the window that actually mattered.

CERT-In is the Indian Computer Emergency Response Team, operating under the Ministry of Electronics and Information Technology (MeitY). Its 28 April 2022 Directions, issued under Section 70B(6) of the Information Technology Act 2000, are not a framework you adopt at leisure. They are binding law with a criminal tail — non-compliance can attract imprisonment up to one year, a fine up to one lakh rupees, or both, under Section 70B(7). And yet most Indian entities we assess treat it as an afterthought bolted onto their ISO 27001 project. This guide is what we tell clients in the audit room, minus the corporate softening.

The single biggest misconception is that CERT-In only applies to critical infrastructure or licensed sectors. It does not. The 2022 Directions apply to service providers, intermediaries, data centres, body corporates and Government organisations. If you run a website, an app, a cloud tenancy or a network in India, you are in scope for incident reporting. There is no revenue floor, no employee count, no sectoral carve-out for the core reporting obligation.

Where scope does narrow is the specialised obligations. Some rules bite only certain categories:

That VPN and cloud KYC rule is the one that made headlines. It is real, it is in force, and if you resell hosting or VPS you cannot pretend it does not exist. But for the average body corporate running SaaS on AWS Mumbai, the two clauses that will define your audit are the six-hour rule and the 180-day log retention.

The Direction says you must report cyber incidents to CERT-In within six hours of noticing such incidents or being brought to notice about such incidents. Read that carefully. The trigger is noticing, not confirming, not root-causing, not containing. The moment a competent person in your organisation becomes aware of a reportable incident, the timer runs.

This is where teams get it wrong. They wait for certainty. They want to know the blast radius, the CVE, the attacker attribution — all the things a forensic investigation delivers days later. CERT-In does not expect a finished report at hour six. It expects notification. You tell them what you know, flag it as preliminary, and update as facts firm up. A same-day report that says under investigation beats a perfect report filed on day three that lands you a Section 70B(7) exposure.

The Directions annexe a list of mandatorily reportable incident types. It is broad by design. Do not read it as an exhaustive menu where anything unlisted is safe to ignore — CERT-In reserves the right to add categories, and the spirit is over-report rather than under-report. The core categories you must know:

Notice how many of these have nothing to do with critical infrastructure. A defaced marketing microsite is reportable. A phishing page impersonating your brand is reportable. A compromised corporate LinkedIn account is reportable. This breadth is deliberate, and it is why we insist clients build reporting into the incident runbook rather than treating each event as a fresh legal debate.

There is no mystery here, but there are avoidable delays. CERT-In accepts reports by email to incident@cert-in.org.in, via phone on the published helpline, by fax, or through the online reporting portal. For a live incident, email plus the portal is what we use. The format is the CERT-In Incident Reporting Form, and the fields you must be ready to populate include:

The friction is never the form. It is the internal path to the form. Who is authorised to hit send? Does the SOC analyst at 2am have that authority, or must they wake a CISO who must wake general counsel? Every handoff eats the six hours. The organisations that get this right pre-authorise a named point of contact — a CERT-In liaison — with standing authority to file the preliminary report without a committee.

A mid-sized fintech we assessed had a genuinely capable SOC. Detection was fast — their EDR caught lateral movement within eleven minutes. Then it fell apart. The playbook routed the decision to a chief information security officer who was on a flight. His deputy did not believe he had authority to notify a regulator. Legal wanted the forensic firm engaged first. By the time the report went out, it was hour nine. In the post-incident review we did not fault their tooling. We faulted a single missing line in the runbook: a named backup authoriser and a standing instruction that preliminary notification is mandatory, not discretionary. That one gap converted a well-handled incident into a compliance breach.

The Direction requires you to enable logs of all your ICT systems and maintain them securely for a rolling period of 180 days, within Indian jurisdiction. When CERT-In asks — during an incident or an order — you must produce them. Simple to state, genuinely hard to satisfy when your estate is a sprawl of SaaS, managed services and multi-region cloud.

Three failure modes we see repeatedly:

That last point is under-appreciated. The Directions specifically require connection to the Network Time Protocol (NTP) servers of the National Informatics Centre or the National Physical Laboratory, or servers traceable to them. The reason is not bureaucratic — when CERT-In correlates your logs against a national picture of an attack campaign, mismatched clocks make your evidence useless. We have seen a forensic reconstruction collapse because the firewall was fourteen minutes off the application servers.

Here is a distinction that costs organisations real money when they get it wrong. A CERT-In empanelled audit is not the same as any competent penetration test or ISO gap assessment. CERT-In maintains a panel of empanelled security auditing organisations, and certain obligations — for Government projects, regulated sector mandates, or post-incident directions — must be conducted by a firm on that panel. If your compliance requirement specifies CERT-In empanelled, an audit from a non-empanelled firm, however good, does not satisfy it.

The cost figures move with scope — a single web application is at the low end, a full network plus multiple applications plus a source-code review sits at the high end, and repeat cycles are cheaper once the baseline exists. Do not choose on price alone. The value is in whether the report is accepted by the party demanding it.

CERT-In does not live in isolation. It sits alongside a stack of Indian obligations, and treating them as separate projects wastes budget. The overlaps are substantial and you should exploit them.

The practical takeaway: one incident can trigger three separate regulatory clocks. A payments company suffering a breach of cardholder and personal data may owe reports to CERT-In within six hours, to RBI within its window, and to the Data Protection Board under DPDP — plus PCI DSS obligations to card schemes. If your runbook has one destination, you have already failed two regulators. Build a single detection trigger that fans out to every obligation.

When we assess CERT-In readiness, the same five gaps recur. None is technically hard. All are organisational.

Do these now, while things are calm. Every item removes minutes from your response time or removes an audit finding.

Come back to where we started. The six-hour window is not a paperwork nuisance — it is a test of whether your organisation can act under uncertainty. The technical controls matter, but the failures we see are almost always human and organisational: an unauthorised analyst, a default log setting, a runbook that routes a regulatory decision into a committee. Fix those and CERT-In compliance stops being a scramble and becomes muscle memory.

If you would rather pressure-test your readiness with people who have sat on both sides of the table, CyberSigma is a CERT-In empanelled auditor. We run the tabletop, close the gaps, and conduct the audit hands-on — quietly, without the theatre.