CERT-In 6-Hour Reporting: Is Your Organization Actually Ready?

CERT-In directions require reporting specified cyber incidents within 6 hours of detection — a considerably tighter window than most incident response processes were originally designed for.

The bottleneck usually isn't technical — it's organizational. Who has authority to declare an incident reportable? Who drafts the report? Who reviews it before submission? Without clear pre-assigned answers, the 6-hour window disappears fast.

We recommend a pre-drafted reporting template with placeholders for incident-specific details, rather than drafting structure from scratch under pressure. A clear internal escalation chain with designated backups matters just as much.

Logging infrastructure needs to support this obligation too — CERT-In also requires maintaining logs for 180 days and NTP time synchronization, requirements much easier satisfied proactively than retrofitted mid-incident.

We strongly recommend running this as an actual timed tabletop exercise. Most organizations are surprised where real delays occur — rarely the technical investigation, more often internal approval bureaucracy or outdated contact information.

Getting this right also directly improves your actual incident response speed more broadly — the regulatory deadline is less a compliance burden and more a forcing function toward genuinely better incident response discipline.\n\nOrganizations sometimes ask whether every security event needs to be reported under CERT-In's 6-hour window, and the honest answer requires understanding the specific categories the directions cover — unauthorized access, data breaches, ransomware, and several other defined categories, rather than every single security alert your SOC generates. Building clear internal criteria for what qualifies as CERT-In reportable, reviewed with legal counsel if there's ambiguity, prevents both under-reporting (a compliance risk) and over-reporting (which can create unnecessary noise and erode credibility with the regulator over time).\n\nWe also recommend keeping a simple internal log of near-misses and borderline cases that didn't ultimately require formal reporting, along with the reasoning for that decision. This creates a defensible paper trail showing your organization is actively evaluating incidents against the reporting criteria, rather than simply hoping nothing reportable ever happens.\n\nFor organizations still building this capability, starting with a simplified internal decision tree — a short flowchart mapping incident types to reportability status — gives your team a fast, low-ambiguity reference during the pressure of an actual event, rather than needing to reason through the full regulatory text from scratch in real time.\n\nWe also recommend appointing a specific individual as the CERT-In liaison for your organization, someone who maintains familiarity with the current reporting portal, format requirements, and any updates to the directions over time, rather than leaving this as a diffuse responsibility that nobody specifically owns until an incident forces the question.\n\nIt's also worth periodically reviewing CERT-In's published advisories and guidance documents directly, since directions and interpretive guidance have evolved since the original 2022 directions were issued, and organizations relying on an understanding formed several years ago may be operating with an outdated picture of current specific requirements.\n\nOrganizations sometimes ask whether engaging a third-party security partner changes who bears the reporting obligation — generally, the obligation remains with the affected entity itself, even when a managed security provider is monitoring the environment, which makes it essential that your contract with any security vendor clearly specifies their role in supporting (not replacing) your own CERT-In reporting responsibility, avoiding ambiguity about who actually submits the report when an incident occurs.\n\nWe'd also suggest maintaining a simple internal FAQ document, updated as your team encounters edge cases, capturing how your organization has interpreted ambiguous reporting scenarios in the past. This creates consistency across different incidents and different people potentially making the reportability call over time, rather than each new ambiguous case being reasoned through from scratch, which risks inconsistent decisions that could look arbitrary if ever scrutinized by a regulator reviewing your historical reporting pattern.\n\nOrganizations that build genuine reporting readiness — not just documented on paper, but actually rehearsed — consistently describe the process as far less stressful when a real qualifying incident occurs, precisely because the ambiguity and decision paralysis that typically eats up the most time has already been resolved in advance through the exercises we've described throughout this piece, leaving the team free to focus their limited hours on the technical response itself rather than figuring out the reporting process for the first time under pressure.