CERT-In and the telecom cyber security rules: same six hours, two different triggers

Telecom operators occupy an unusual position in India's cyber incident reporting landscape: they are subject to both the general CERT-In Directions, which apply to virtually every organisation, and the sector-specific Telecom Cyber Security Rules issued under the Telecommunications Act, which apply specifically to licensed telecom entities. Both carry a six-hour reporting clock. The coincidence of timing has led more than one operator to assume the two obligations can be satisfied by a single unified process. They cannot, because the trigger definitions are not the same.

Where the two frameworks diverge

CERT-In's twenty incident categories are broad and general-purpose, covering everything from targeted scanning to data breach to website defacement, written to apply across every sector. The telecom cyber security rules define incident categories specific to telecom network operation — network element compromise, service disruption, signalling anomalies — that reflect the operational reality of running a telecom network rather than a generic IT estate.

An event can meet one trigger definition and not the other. A signalling-layer anomaly affecting network availability may squarely meet the telecom-specific trigger while not obviously mapping onto any of CERT-In's twenty general categories in the same way. Conversely, a data exposure incident in a customer-facing billing system may clearly trigger CERT-In's general categories while not meeting the telecom-specific rules' network-focused trigger at all.

The reporting destinations and forms are separate. A telecom-specific incident is reported through the Department of Telecommunications' process under the sector rules; a CERT-In-triggering incident is reported to CERT-In directly. An incident meeting both triggers — which does happen, particularly for anything touching both network infrastructure and customer data — requires two separate reports, on two separate forms, to two separate authorities, within the same six-hour window.

Why a single unified process reliably fails one obligation

We have seen telecom operators build a single incident response and reporting workflow, reasonably assuming that because both frameworks share a six-hour window, one assessment and one report can satisfy both. This fails in a specific, predictable way: the workflow gets built around one framework's trigger definitions — usually whichever framework the team building it was most familiar with — and incidents that meet only the other framework's trigger get missed entirely, not late.

This is a harder failure to catch than a late report, because a late report at least generates an internal record that something was reported, just outside the window. A missed report under the framework the unified process was not built around generates no internal flag at all — the incident was assessed, found not to meet the trigger the team was checking against, and closed, with the second framework's separate trigger never evaluated.

Building a process that actually covers both

Maintain two explicit trigger checklists, run in parallel on every incident, not one combined checklist assumed to cover both. Every incident gets assessed against CERT-In's twenty categories and separately against the telecom-specific categories, as two distinct evaluation steps within the same intake process, rather than a single merged assessment.

Assign clear ownership for each report, because the two reports may reasonably be prepared by different functions — a general security operations team for CERT-In, a network operations or regulatory affairs function with telecom-specific expertise for the sector report — and an incident meeting both triggers needs both functions engaged from the point of detection, not sequentially.

Log the trigger assessment outcome for both frameworks on every incident, including "assessed, does not meet trigger." This is what makes a missed-report failure visible in a later audit: a documented "assessed against telecom-specific categories, does not meet threshold" is defensible; the absence of any record that the telecom-specific trigger was even considered is not.

Test the process against incidents that plausibly meet only one trigger, not just incidents that would obviously meet both. A tabletop exercise built entirely around scenarios that trigger both frameworks simultaneously will never reveal a process gap that only shows up when an incident meets one trigger and not the other — which, in our reading of the two frameworks, is a genuinely common scenario, not an edge case.

The underlying lesson

Two regulators sharing the same reporting window creates an understandable temptation to treat their obligations as one obligation with two addressees. They are not. Each has its own trigger definition, built for its own regulatory purpose, and a compliance process that does not evaluate both, independently, on every incident, will eventually miss one of them — quietly, with no internal alarm, on exactly the incident where the two frameworks' trigger definitions diverge.