Updated: Feb 25, 2026
CERT-In requires certain cyber incidents to be reported within six hours of detection or awareness. If your detection, classification, and escalation chain exceeds two hours, you risk non-compliance under CERT-In directions in India.
The CERT-In six-hour reporting requirement mandates that organisations in India report specified cybersecurity incidents within six hours of noticing or becoming aware of them. The rule applies to incidents such as unauthorised access, data breaches, ransomware, and attacks on critical systems. Reporting must follow the format and process defined under the current CERT-In directions.
This is a statutory obligation. It requires operational readiness, not post-incident documentation.
At 01:40 a.m., an IT manager in Noida sees unusual outbound traffic from a finance server. By 03:10 a.m., the SOC confirms possible data exfiltration. By 08:30 a.m., legal asks a simple question. Is this reportable under CERT-In directions?
Silence follows.
You do not fail the six-hour window because you ignore it. You fail because you do not know, fast enough, what happened, how severe it is, and whether it meets reporting criteria.
CERT-In does not measure your intent. It measures your response time.
The CERT-In direction requires you to report certain cyber incidents within six hours of noticing them. That clock does not wait for your internal debates. This requirement tests five operational capabilities:
If one breaks, the clock keeps running.
Most enterprises believe they are compliant. Few have tested their reporting chain under pressure. You can assess your position across three maturity levels.
At this level, the six-hour window is at risk during nights, weekends, and complex incidents.
At this level, compliance is possible but inconsistent. Delays occur during scope validation and cross-team coordination.
At this level, reporting becomes procedural rather than reactive. The organisation can detect, classify, and report within four hours during simulation.
You should know your current level. If you cannot state it clearly, you are likely operating at Level 1 or Level 2.
CERT-In Reporting Maturity Summary Table
You must report incidents such as:
The challenge is not knowing the list. The challenge is deciding, within hours, whether your situation fits the criteria.
In Pune’s industrial belt, a manufacturing firm saw lateral movement across shop-floor systems. The SOC tagged it as suspicious but low impact. Four hours later, a forensic review showed credential abuse. The reporting clock had already narrowed.
Classification delays create regulatory risk.
You cannot report what you do not detect. Many firms still lack unified visibility across endpoint, network, identity, and cloud.
Logs sit in silos. Endpoint logs live in one tool. Firewall logs sit elsewhere. SaaS activity remains outside central monitoring. During an incident, analysts waste time stitching events together.
If you lack a severity matrix aligned to CERT-In categories, your team debates instead of deciding.
In one Gurugram-based services firm, the breach surfaced on Sunday. Legal, compliance, and executive sign-off waited until Monday morning. The six-hour window did not.
1. A Reportability Decision Tree
Build a simple matrix that maps incident types to CERT-In reporting requirements. Train SOC analysts to use it. Remove ambiguity.
2. Detection To Escalation In Under Two Hours
Set a measurable target. If detection to executive alert exceeds two hours, fix it. Measure this monthly.
3. Centralised Logging With Evidence Readiness
You need searchable logs across endpoint, network, identity, and cloud. Retain them as mandated. Test log retrieval under time pressure.
4. Named Reporting Owner
Assign one accountable executive. When the threshold is met, that person reports. No committee. No delay.
5. Pre-Approved Reporting Template
Draft your CERT-In reporting format in advance. Store it securely. During crisis, you fill blanks, not draft from scratch.
Can your security stack answer these within one hour:
Which systems are affected?
If the answer is no, the six-hour rule exposes a structural weakness.
Policy alone will not fix this. You need integrated detection across identity, endpoint, and network layers. You need segmentation that limits the spread. You need clear workflows that link technical findings to executive action.
A mature model includes:
Technology without discipline fails. Discipline without visibility fails.
In Hyderabad’s IT corridor, a mid-sized enterprise implemented a defined escalation matrix, identity enforcement for privileged users, and segmented finance workloads. When abnormal access surfaced, the SOC confirmed the scope in ninety minutes. Legal received a clear brief. Reporting happened within four hours.
The difference was not a panic response. It was preparation.
You should be able to detect, classify, escalate, and report a notifiable cyber incident within four hours, with documented evidence, executive alignment, and containment underway.
Measure this monthly:
If you cannot meet these targets during simulation, your CERT-In six-hour reporting readiness is weak.
Proactive Data Systems works with enterprises across India to operationalise CERT-In reporting compliance. As a Cisco Preferred Security Partner, Proactive designs and deploys integrated security architectures that combine identity control, network segmentation, central visibility, and incident workflows into a single accountable operating model.
We test your detection-to-reporting chain under real-world scenarios. You receive a clear gap assessment, defined remediation steps, and measurable targets. If you want certainty on your CERT-In compliance posture, request a focused reporting readiness assessment.
