Nobody can meet the CERT-In six-hour clock on the first try

The CERT-In Directions of April 2022 require specified cyber incidents to be reported within six hours of noticing them or being brought to notice. Every organisation we have asked believed it could do this. On unannounced test, almost none could.

The interesting part is why.

The failure mode is not technical#

When a six-hour test fails, the post-mortem almost never points at detection. Most organisations with a functioning SOC notice a reportable event within the first hour or two.

The clock is lost afterwards, to a sequence that looks like this:

• 00:15 — Analyst identifies suspicious lateral movement. Escalates to the on-call engineer.
• 00:40 — On-call engineer confirms unauthorised access. Asks whether this is reportable.
• 01:10 — Nobody on the technical side knows. Somebody suggests asking Legal.
• 01:15 — Legal's on-call number goes to voicemail. It is Saturday.
• 03:30 — Head of Legal responds, asks for details the engineer does not have in the format requested.
• 05:00 — A draft report exists. Nobody knows who is authorised to submit it.
• 07:20 — Submitted, having missed the window.

Six hours is not a detection SLA. It is an authorisation and drafting SLA, and it fails on org design, not tooling.

The reportable list is broader than "breach"#

A second common failure is treating the direction as a data breach rule. It is not. The specified list includes, among others:

• Targeted scanning or probing of critical networks and systems
• Compromise of critical systems or information
• Unauthorised access to IT systems or data
• Defacement of a website, or intrusion into a website
• Malicious code attacks including ransomware
• Attacks on servers, network appliances and application infrastructure
• Identity theft, spoofing and phishing attacks
• Denial of service and distributed denial of service attacks
• Attacks on critical infrastructure, SCADA, operational technology and wireless networks
• Attacks on applications including e-governance and e-commerce
• Data breach and data leak
• Attacks on IoT devices and associated systems
• Attacks affecting digital payment systems
• Unauthorised access to social media accounts
• Fake mobile applications

Note that targeted scanning of critical systems is on the list. So is a defaced marketing microsite. The list is deliberately wide, and a decision tree that only handles data breaches will systematically under-report.

What a working capability looks like#

Four components, in order of how often they are missing.

1. A decision tree a duty engineer can run alone

The single highest-value artefact. One page, plain language, no legal terminology, taking a duty engineer from observed symptom to a reportable / not-reportable determination without waking a lawyer.

It must be pre-approved by Legal so that following it is the legal position. If the engineer still has to ask, you have built a flowchart, not a control.

The bias should be explicit and toward reporting. Over-reporting carries reputational cost within CERT-In; under-reporting carries statutory consequence under Section 70B(7) — up to one year's imprisonment or a fine, or both.

2. Standing authorisation, with named alternates

Somebody must be permanently authorised to submit a report without further approval. Then two alternates, in a defined order, with contact details in the runbook rather than in someone's phone.

The authorisation should be documented as a delegation from the board or an executive committee, so the authorised individual is not personally exposed for filing.

3. Pre-positioned submission mechanics

Credentials for the CERT-In reporting channel, tested quarterly. The report template pre-filled with everything static — entity details, point of contact, sector, infrastructure description. At 3am, the only fields that should need writing are the incident-specific ones.

An hour lost to a password reset at 3am is a common failure mode. Test the credentials, not the process document.

4. One incident, all obligations

A single incident can trigger CERT-In reporting within six hours, DPDPA notification to the Data Protection Board and affected data principals, sectoral regulator reporting under RBI, SEBI or IRDAI rules, contractual notification to enterprise customers, and — where EU data principals are affected — GDPR's seventy-two hour clock.

Running these as separate processes guarantees at least one is missed. The pattern that works is a single assessment that fires all applicable notifications from one determination, with a matrix mapping incident characteristics to obligations.

The log residency question#

The 180-day in-country retention requirement is often read as prohibiting foreign cloud. It does not. It requires logs be retained within Indian jurisdiction.

A workable pattern: run workloads wherever the architecture calls for it, and replicate logs into an Indian region with restricted access and immutability controls. Storage cost is manageable because logs compress well and hot access is rarely needed beyond thirty days.

What is not acceptable is logs held solely outside India with no in-country copy, which is the default for a lot of SaaS-heavy estates. Check your SIEM's actual storage region rather than your contract's data residency clause — they are frequently different.

Run the test#

Pick a Saturday. Pick a plausible scenario — ransomware precursor activity on a file server, say. Page the on-call engineer without warning and time the sequence to a submitted report.

You will learn more in that four hours than from any amount of documentation review, and the result will tell you exactly which of the four components above you are missing.

A worked timeline that actually holds#

For comparison, here is the same scenario at an organisation that had done the preparation. Same incident, same weekend.

• 00:00 — SIEM correlation rule fires on credential access followed by lateral movement from a file server. Analyst acknowledges.
• 00:12 — Analyst confirms unauthorised access and opens the decision tree. Symptom maps to "unauthorised access to IT systems" — reportable, no legal consultation required.
• 00:20 — Duty engineer notifies the standing authoriser and begins the pre-filled report. Entity details, sector, point of contact and infrastructure description are already populated.
• 00:48 — Report submitted to CERT-In with the facts known at that point, explicitly marked as preliminary.
• 01:30 — Containment underway. Parallel assessment begins against DPDPA and customer contractual notification obligations from the same incident record.
• 04:00 — Supplementary detail filed as scope becomes clearer.

Forty-eight minutes, not seven hours. Nothing in that sequence required a better SOC — it required a decision tree, a standing authorisation, and credentials that had been tested.

Note the fourth line. Reporting with incomplete information and supplementing later is both permitted and correct. Organisations that wait for a complete picture miss the window and then have to explain why. A preliminary report inside six hours followed by detail at four days is a far better position than a complete report at nine hours.

Designing the 180-day log estate#

The retention requirement is the second-largest cost in CERT-In readiness after detection, and most of that cost is avoidable.

The pattern that works separates three tiers:

Hot, 7–14 days. Indexed and searchable in the SIEM. This is where investigation happens, and it is the expensive tier. Keep it short.

Warm, to 90 days. Object storage in an Indian region, compressed, queryable on demand with a few minutes of latency. Costs roughly a twentieth of hot storage per gigabyte.

Cold, to 180 days and beyond. Archive-class storage with immutability enabled. Retrieval takes hours, which is acceptable for a regulatory production order and unacceptable for an investigation — which is precisely why the tiers are separate.

Two details matter for compliance rather than cost. Immutability on the cold tier is what lets you assert the logs were not altered, and that assertion is the whole point of retention. And the Indian residency requirement applies to the copy you rely on — running workloads in Singapore while replicating logs to Mumbai is compliant; holding logs only in Singapore is not.

Check where your SIEM actually stores data rather than what your contract's data residency clause says. Those two often differ, particularly with vendors who added an Indian region after you signed.

Two administrative items round this out, and both are five-minute jobs that get missed for years. Register your designated point of contact with CERT-In and keep it current — a report filed by an unregistered contact invites exactly the scrutiny you are trying to avoid, and people change roles. And verify NTP configuration across every system class rather than assuming it: cloud instances, network appliances and virtual machines built from old images are the three that routinely point somewhere other than an NPL or NIC source, which quietly undermines the timeline evidence in every report you file.

Our Cyber Security Advisory engagements include this exercise, but it is entirely runnable in-house — and it should be.