CERT-In’s Six-Hour Incident Reporting Rule: A Quick Guide

CERT-In’s Six-Hour Incident Reporting Rule: How to Actually Comply

When CERT-In issued its April 2022 directions mandating incident reporting within six hours of detection, it fundamentally changed the operational calculus for every regulated enterprise in India. The CERT-In 6 hour incident reporting requirement isn’t just a policy checkbox. It is an operational capability that most organizations have yet to build.

Six hours sounds manageable in theory. In practice, it compresses detection, triage, classification, internal escalation, evidence gathering, and formal reporting into a window that most security and compliance teams have never rehearsed against. The gap between knowing about this requirement and being able to execute on it reliably, under pressure, at 2 AM on a Saturday, is where real compliance risk lives.

What the Six-Hour Window Means in Practice

The clock starts at the moment of “noticing” or “coming to know” about the incident. This is a critical distinction. CERT-In does not measure from the moment an attack begins, or from the moment it is contained. It measures from when your organization becomes aware that a reportable incident has occurred.

This creates an immediate structural challenge. If your SOC analyst detects anomalous behavior at 11 PM, and it takes until 1 AM for the incident to be classified as reportable, you have already consumed two hours of your six-hour window before the reporting process even begins. The remaining four hours must cover internal approvals, evidence compilation, and submission through the designated channel.

Consider a mid-sized NBFC with a security operations team of five people. An alert fires indicating unauthorized access to a database containing customer financial records. The on-call analyst sees the alert, begins investigation, escalates to the team lead, who loops in the CISO. By the time there is organizational consensus that this is a reportable event, three hours have passed. The compliance team now has three hours to draft the report, gather supporting evidence, obtain sign-off, and submit. This is the reality the six-hour rule imposes.

The Problem of Ambiguity in Detection Time

One of the less discussed challenges is determining exactly when the clock starts. If your SIEM generates an alert that sits in a queue for 45 minutes before an analyst reviews it, does the clock start at alert generation or at analyst acknowledgment? CERT-In’s language suggests the former. The moment your system “knows,” your organization knows. This makes automated alerting and immediate triage capabilities not just good practice, but compliance necessities.

Which Incidents Must Be Reported Under the CERT-In 6 Hour Incident Reporting Mandate

The April 2022 directions specify a broad set of incident types that trigger the reporting obligation. Understanding the full scope is essential because many organizations underestimate what qualifies.

The breadth of this list catches many organizations off guard. Targeted scanning alone, something most enterprises experience daily, becomes reportable when directed at critical systems. This demands that your incident classification framework explicitly maps CERT-In’s categories to your internal severity and reporting triggers.

Sector-Specific Overlaps

For BFSI entities, CERT-In reporting often runs parallel to RBI’s own incident reporting requirements. An NBFC experiencing a data breach must report to CERT-In within six hours and to RBI under its cybersecurity framework. Insurance companies face similar dual obligations with IRDAI. Capital markets intermediaries must consider SEBI’s cybersecurity circular alongside CERT-In. Each has different formats, different timelines, and different escalation paths. Managing these concurrently is where the operational burden compounds.

The Reporting Format and Channel

CERT-In accepts incident reports through email (incident@cert-in.org.in), their web portal, and telephone for urgent matters. The report must contain specific fields, and incomplete submissions can result in follow-up queries that consume additional time and resources.

The required information includes the organization’s name and contact details, nature and classification of the incident, systems affected (including IP addresses, operating systems, and applications), date and time of incident detection, impact assessment (scope and severity), initial remediation steps taken, and any indicators of compromise identified.

The critical point is that this is not a placeholder notification. CERT-In expects substantive detail within that six-hour window. You cannot simply say “we detected something, details to follow.” The initial report must contain enough technical and contextual information for CERT-In to assess the incident’s significance.

Follow-Up Obligations

The six-hour report is the beginning, not the end. CERT-In may request additional information, forensic reports, or status updates. Organizations must maintain communication until the incident is resolved. This means your documentation process cannot stop at the initial report. Continuous evidence capture and status tracking become essential throughout the incident lifecycle.

Why Most Organizations Cannot Meet the CERT-In 6 Hour Incident Reporting Timeline Today

The honest assessment is that most regulated enterprises in India lack the integrated process, pre-built documentation, and rehearsed workflows to reliably report within six hours. This isn’t a technology problem alone. It is a process design problem with three structural dimensions.

First, incident classification is too slow. Most organizations have generic incident severity matrices that don’t directly map to CERT-In’s reportable categories. An analyst must detect the incident, determine its type, cross-reference it against CERT-In’s list, and make a reporting determination. Without pre-mapped classification rules, this alone can consume hours.

Second, internal escalation chains are not designed for speed. In a typical bank, an incident moves from SOC analyst to SOC lead to CISO to compliance head, with each handoff introducing delay. If any person in the chain is unavailable, in a meeting, asleep, or on leave, the clock keeps running.

Third, evidence collection is fragmented. The data needed for a CERT-In report lives in multiple systems: SIEM logs, endpoint detection tools, network monitoring, asset management databases. Pulling this together manually under time pressure leads to errors and omissions.

The Rehearsal Gap

Perhaps the most telling indicator: ask your incident response team when they last rehearsed a CERT-In report submission under timed conditions. Most organizations run tabletop exercises annually at best, and rarely simulate the full reporting workflow including documentation, approval, and actual submission mechanics. The first time your team attempts a real six-hour report should not be during an actual incident.

Building an Incident Response Process That Meets the Timeline

Meeting the six-hour window consistently requires deliberate process engineering, not just faster typing. The process must be designed backward from the deadline.

Pre-Classification Rules

Map every alert category in your SIEM and detection tools to CERT-In’s reportable incident types in advance. When an alert fires, the analyst should immediately know whether it falls within CERT-In’s scope without having to reference external documents. This mapping should be embedded in your detection platform’s workflow, not in a separate policy document that someone has to look up.

Parallel Escalation, Not Sequential

Redesign your escalation to trigger simultaneously, not in sequence. The moment an incident is classified as potentially reportable, the CISO, compliance head, and designated CERT-In reporter should all be notified in parallel. The investigation continues while the reporting preparation begins. These are not sequential activities, and treating them as sequential is what burns the clock.

Pre-Populated Report Templates

Maintain report templates pre-filled with static organizational information, contact details, and system descriptions. Your team should only need to add incident-specific details: timestamps, affected systems, indicators of compromise, and initial response actions. Every field that can be filled in advance should be filled in advance.

Designated Reporters with Authority

Identify specific individuals (with backups) who have the authority to submit reports without additional approval chains. If your CERT-In report requires board-level sign-off before submission, you will not meet the deadline. The designated reporter needs pre-authorized submission authority, with post-submission governance reviews built in afterward.

Automated Evidence Snapshots

Configure your security tools to automatically capture and preserve evidence at the point of detection. System states, log segments, network captures, and alert metadata should be automatically packaged rather than manually retrieved. This is where GRC platforms that integrate with your security stack provide measurable time savings, automatically associating evidence with incidents and pre-staging it for report compilation.

eQomply’s evidence management capabilities are specifically designed for this kind of time-pressured compliance workflow, automatically capturing audit trails and organizing documentation against specific regulatory requirements including CERT-In’s reporting framework.

Evidence and Documentation Requirements

Beyond the initial report, CERT-In expects organizations to maintain comprehensive records. The directions mandate that all ICT system logs be maintained for 180 days (rolled over) and must be provided to CERT-In upon request. This is not optional, and non-compliance carries penalties under the IT Act.

What to Preserve Immediately

At the moment of incident detection, your process should automatically preserve firewall logs, system event logs for affected hosts, authentication logs showing access patterns, network flow data for the relevant time window, and any malware samples or artifacts identified. These must be preserved in their original form, with integrity protections (hashing, chain of custody documentation) that ensure they remain admissible and trustworthy for any subsequent investigation.

The 180-Day Log Retention Requirement

CERT-In’s requirement for rolling 180-day log retention applies to all organizations, not just those experiencing incidents. This is a standing obligation. For large enterprises with distributed infrastructure, this creates significant storage and management challenges. Logs must be securely stored, indexed for rapid retrieval, and synchronized to accurate time sources (CERT-In specifically mandates NTP synchronization with the IC/NIC NTP servers).

Post-Incident Documentation

Following the initial six-hour report, organizations should maintain a complete incident timeline, all communications with CERT-In, forensic analysis reports, remediation actions taken and their timestamps, root cause analysis, and evidence of preventive measures implemented. This documentation serves dual purposes: demonstrating compliance to CERT-In and providing audit evidence for your primary regulators (RBI, SEBI, IRDAI) who will want assurance that incident management processes are robust.

A centralized GRC platform that consolidates incident records, evidence, regulatory communications, and remediation tracking into a single auditable repository eliminates the fragmentation that makes post-incident compliance reviews painful. eQomply’s approach to this, unifying compliance tracking and evidence management across multiple regulatory requirements, means that documentation captured for CERT-In automatically feeds into your broader compliance posture for RBI, SEBI, or IRDAI audits.

Making This Operationally Real

The CERT-In 6 hour incident reporting requirement is not going to relax. If anything, the trend across Indian regulators is toward faster, more detailed incident disclosure. RBI’s draft digital lending incident reporting norms, SEBI’s evolving cybersecurity framework, and the DPDP Act’s breach notification provisions all point in the same direction: regulated enterprises must build the operational muscle for rapid, documented, multi-regulator incident response.

The organizations that will meet this standard consistently are those that invest in process engineering now, before the next incident forces them to improvise under pressure. Pre-mapped classification rules, parallel escalation workflows, pre-authorized reporting authority, automated evidence capture, and centralized documentation are not aspirational improvements. They are the baseline for compliance in India’s current regulatory environment.

If your current incident response process relies on manual handoffs, sequential approvals, and scattered documentation, the gap between your capability and the regulatory expectation is measurable, and it grows more costly with each incident. Building the infrastructure to close that gap is where platforms like eQomply fit: purpose-built for the speed and documentation depth that Indian regulators now demand.

To see how this works in practice for your specific regulatory landscape, schedule a walkthrough with the eQomply team.