CERT-In 6-Hour Rule: Why Your SOC Team Isn't Ready

On 28 April 2022, the Indian Computer Emergency Response Team (CERT-In) issued Directions under Section 70B(6) of the Information Technology Act, 2000, mandating that all organizations report cybersecurity incidents to CERT-In within 6 hours of "noticing or being brought to notice" of the incident. The Directions came into effect on 28 June 2022 and apply to every entity -- government, private sector, and intermediaries -- operating in India.

This 6-hour window is among the strictest incident reporting timelines in the world. By comparison, the European Union's NIS2 Directive requires an initial notification within 24 hours, and GDPR allows up to 72 hours for breach notification. CERT-In's mandate demands that Indian organizations detect, triage, scope, and report incidents four times faster than their European counterparts.

Nearly four years after the Directions took effect, the reality on the ground is sobering. The majority of Indian organizations still cannot consistently meet the 6-hour deadline, and the consequences of non-compliance are becoming increasingly real as CERT-In ramps up enforcement.

What the 6-Hour Rule Actually Requires

The CERT-In Directions specify 20 categories of reportable incidents that must be reported within 6 hours. These are not limited to large-scale breaches -- they include a wide range of security events:

Targeted scanning/probing of critical networks

Compromise of critical information systems

Unauthorized access to IT systems or data

Defacement of websites and applications

Malicious code attacks (ransomware, worms, trojans)

Attacks on servers (databases, mail, DNS)

Identity theft, phishing, and spoofing attacks

Denial of Service (DoS/DDoS) attacks

Attacks on critical infrastructure and IoT devices

Attacks or malicious activities on cloud computing systems

Data breaches or leaks

Attacks through malicious mobile applications

Fake mobile applications

Unauthorized access to social media accounts

Attacks or suspicious activities on payment systems

Attacks through malicious code (supply chain)

Attacks on application programming interfaces (APIs)

Data leaks through third parties or vendors

Beyond incident reporting, the Directions also mandate that organizations maintain ICT system logs for a rolling 180-day period, synchronize system clocks with NTP servers (preferably NIC or NPL), and designate a Point of Contact (PoC) for CERT-In communication. Virtual private server (VPS) and cloud service providers must maintain KYC records of customers for at least five years.

Critical nuance: The 6-hour clock starts when the incident is "noticed" -- not when it is confirmed or fully investigated. This means your SOC team must report based on initial indicators, even before the full scope is understood. Over-investigation before reporting is itself a compliance failure.

Five Reasons Most Organizations Fail the 6-Hour Test

Understanding why organizations fail is the first step to building readiness. Based on DSCI's industry surveys and CERT-In's own post-drill analysis, these are the most common failure points:

1. No 24x7 SOC Coverage

A 2025 NASSCOM-DSCI survey found that only 38 percent of Indian enterprises with more than 500 employees operate a 24x7 Security Operations Center. The rest rely on business-hours monitoring or outsourced managed detection and response (MDR) services with SLAs of 30 minutes to 4 hours for initial triage -- which leaves little margin for the 6-hour reporting window. If an incident occurs at 2:00 AM on a Saturday, many organizations will not even notice it until Monday morning.

2. Inadequate Log Management

The 180-day log retention requirement caught many organizations unprepared. A PwC India study found that 54 percent of Indian enterprises had log retention policies of 30 days or less before the CERT-In Directions. Without adequate logging, SOC teams cannot perform the initial triage needed to classify an incident within 6 hours. They also cannot provide the forensic evidence CERT-In expects in follow-up reports.

3. No Rehearsed Reporting Workflow

Most organizations have incident response plans, but very few have a rehearsed CERT-In reporting workflow. The reporting process requires specific information in a specific format submitted through CERT-In's portal. Without a pre-built template, escalation matrix, and designated reporter, teams waste precious hours figuring out what to report, who should approve it, and how to submit it.

4. Slow Mean-Time-to-Detect (MTTD)

IBM's Cost of a Data Breach Report 2025 found that the global average time to identify a breach is 194 days, with Indian organizations averaging 221 days. Even for incidents that are detected in real-time by SIEM or EDR tools, the time from alert to confirmed incident (triage time) averages 4.2 hours for organizations without regular SOC training. Add the reporting workflow, and 6 hours becomes nearly impossible.

5. Lack of Forensic Capability

CERT-In expects organizations to preserve digital evidence and provide technical details about the incident vector, affected systems, and indicators of compromise (IoCs). A DSCI study found that only 22 percent of Indian enterprises have in-house digital forensics capability, and 67 percent rely entirely on external forensic investigators -- who may take 24 to 48 hours to mobilize.

What "Ready" Actually Looks Like

An organization that can consistently meet the CERT-In 6-hour reporting mandate has these operational characteristics:

Continuous monitoring capability (24x7 SOC or equivalent MDR service with sub-15-minute initial triage SLA).
Centralized SIEM with correlation rules tuned for all 20 CERT-In reportable incident categories, with automated alerting.
Pre-built CERT-In reporting templates with auto-populated fields (organization details, PoC, system inventory) ready for analyst input.
A clear escalation matrix that moves from L1 detection to CERT-In report submission in no more than 4 steps.
Designated CERT-In liaison(s) authorized to submit reports without executive approval delays.
Regular (quarterly) drill exercises that simulate detection-to-report within the 6-hour window.
Forensic readiness: tools and training for initial evidence preservation (disk images, memory dumps, network captures) within the first hour.
NTP-synchronized logs with 180-day retention across all critical systems, centrally accessible.

How Cyber Range Exercises Build CERT-In Response Speed

The gap between having an incident response plan and being able to execute it under time pressure is bridged only through practice. Cyber range exercises provide the closest approximation to real incident conditions -- with live attack scenarios, time constraints, and realistic infrastructure.

CERT-In itself has recognized this need. Since 2004, CERT-In has conducted 122 cyber security mock drills involving 1,570 organizations from critical sectors including finance, power, telecom, transport, health, and government. These drills evaluate organizational preparedness for incident detection, analysis, and reporting.

The data from these drills is compelling. Organizations that participate in regular cyber exercises show measurable improvements:

68%

Improvement in MTTD

Mean-time-to-detect drops from hours to minutes after 3+ drill cycles

45%

Improvement in MTTR

Response time improves as analysts build muscle memory for incident workflows

4.2x

Faster Reporting

Organizations with quarterly drills report to CERT-In 4.2x faster than those without

The types of exercises that build CERT-In readiness include:

SOC Battle Drills (CDX)

Team-based defensive exercises where SOC analysts face live adversary simulation in a realistic network environment. Participants must detect intrusions using SIEM, triage alerts, contain threats, and produce a CERT-In report -- all within the 6-hour window. These exercises build the speed and coordination essential for compliance.

Incident Response Tabletop + Live-Fire Hybrid

Executive-level tabletop exercises that transition into live-fire SOC exercises. Leadership practices decision-making and communication while the technical team performs actual forensics and reporting on a parallel timeline. This builds the cross-functional coordination needed for rapid incident escalation.

CERT-In Reporting Specific Drills

Focused exercises that practice the mechanics of CERT-In reporting: filling out the report template, gathering the required technical details (attack vector, affected systems, IoCs, containment actions), obtaining internal approvals, and submitting through the CERT-In portal. The goal is to reduce reporting time to under 2 hours.

Building a CERT-In Readiness Program: A Practical Roadmap

Achieving consistent CERT-In 6-hour compliance is not a one-time project. It requires a structured program that builds capability over time:

1Month 1-2: Baseline assessment. Conduct a tabletop exercise to measure current detection-to-report time. Identify the top 3 bottlenecks (typically: detection delay, escalation confusion, report drafting).
2Month 3-4: Infrastructure hardening. Deploy or tune SIEM correlation rules for CERT-In's 20 reportable categories. Implement 180-day log retention. Set up NTP synchronization.
3Month 5-6: Workflow design. Build pre-populated CERT-In report templates. Create a 4-step escalation matrix. Designate and train CERT-In liaison officers. Establish a "report-first, investigate-later" protocol.
4Month 7-8: First live-fire drill. Run a SOC battle drill on a cyber range with a simulated ransomware incident. Measure time-to-detect, time-to-report, and report quality. Score the exercise and debrief.
5Month 9-10: Second drill with variation. Run a different scenario (data exfiltration, DDoS, supply chain compromise). Measure improvement against the baseline. Address persistent gaps.
6Month 11-12: Quarterly cadence. Establish quarterly drills covering different CERT-In reportable categories. Track MTTD and MTTR trends. Report readiness metrics to the board.

The Cost of Non-Compliance

While the CERT-In Directions do not specify explicit monetary penalties in the same way as the DPDP Act, non-compliance carries serious consequences:

CERT-In can issue directives for corrective action, and persistent non-compliance can result in escalation to the Ministry of Electronics and Information Technology (MeitY).
For regulated industries (banking, telecom, power), CERT-In non-compliance can trigger actions from sectoral regulators (RBI, TRAI, CEA) who reference CERT-In Directions in their own cybersecurity frameworks.
The DPDP Act's breach notification provisions compound the risk: an organization that fails to detect and report a breach involving personal data may face both CERT-In enforcement and DPBI penalties of up to Rs 200 crore.
Reputational damage from publicly visible non-compliance erodes customer and partner trust, particularly for organizations handling sensitive financial or healthcare data.
Insurance implications: cyber insurance providers increasingly require evidence of CERT-In compliance and regular drill participation as underwriting conditions.

Conclusion: Speed Is a Skill, and Skills Require Practice

The CERT-In 6-hour rule is not going away. If anything, enforcement will tighten as India's cybersecurity regulatory framework matures with the DPDP Act, sectoral guidelines (RBI's CSCRF, SEBI's CSCRF, TRAI's cybersecurity framework), and evolving CERT-In directives.

The organizations that will meet this standard consistently are not the ones with the most expensive SIEM or the largest SOC team. They are the ones that practice. Detection speed, triage accuracy, reporting discipline, and cross-functional coordination are all trainable skills -- but they require regular, realistic exercises to build and maintain.

The 6-hour clock starts the moment you notice an incident. The question is not whether your organization will face a reportable event -- it is whether your team will be ready when it happens. Start drilling now, because 6 hours is less time than you think.