Security Insights

India's 6-Hour Cyber Incident Reporting Rule — What Your Startup Must Do Right Now

By Aditya Kumar— Founder & CEO, CyberSharcx
June 23, 20268 min read1,653 words
Share
India's 6-Hour Cyber Incident Reporting Rule — What Your Startup Must Do Right Now

Today, June 23, 2026, BITS Pilani became the latest Indian institution confirmed breached — this time by the DragonForce ransomware group. It will not be the last. The World Economic Forum's Global Risk Report 2026 now ranks cybersecurity as India's number one national risk, ahead of economic downturns and climate disasters.

And yet most Indian startups have no documented incident response plan. No designated point of contact. No idea what they are legally required to do in the hours after a breach is discovered.

That is not just a security problem. Under Indian law, it is a compliance failure that carries its own penalties — on top of whatever damage the breach itself causes.

This post explains exactly what CERT-In's 6-hour reporting mandate requires, what the DPDP Act adds on top of it, and what your startup needs to have in place before the clock starts.

What the 6-Hour Rule Actually Says

In April 2022, CERT-In — the Indian Computer Emergency Response Team — issued a directive that changed the compliance landscape for every Indian organization handling digital infrastructure.

The rule is simple: any cybersecurity incident must be reported to CERT-In within six hours of being detected. Not six hours after investigation. Not six hours after confirmation. Six hours after detection.

The types of incidents covered include unauthorized access to IT systems, data breaches, identity theft, denial-of-service attacks, malware infections, ransomware, and attacks on critical infrastructure. For practical purposes, this covers virtually any significant security event a startup might experience.

For listed companies, a separate layer applies. BSE and NSE-listed companies must disclose material cybersecurity incidents to the stock exchange within 24 hours. Operators of Critical Information Infrastructure — power grids, telecom, banking — must also notify NCIIPC in parallel.

Personal data breaches carry an additional requirement under the DPDP Act 2023: both the Data Protection Board and affected users must be notified promptly. The rules will define the exact timeline, but "promptly" in the context of a law with ₹250 crore penalties is not something to interpret loosely.

Why Six Hours Is Almost Impossible Without Preparation

The six-hour window sounds reasonable until you think about what has to happen inside it.

Someone on your team has to notice that something is wrong. This is not guaranteed. IBM's research puts the average time to detect a breach at 194 days globally. Most breaches are discovered not by the victim but by a third party — a customer, a researcher, or law enforcement.

Once detected, someone has to decide whether the event qualifies as a reportable incident under CERT-In's definitions. That requires knowing the definitions, which requires someone having read them.

Then a report has to be drafted and submitted to CERT-In's incident reporting portal. The report must include the type of incident, the systems affected, the estimated impact, the time of detection, and the initial containment steps taken.

All of this has to happen in six hours — while simultaneously containing the breach, notifying internal stakeholders, and figuring out what actually happened.

For a startup with no documented incident response plan, no designated contact person, and no monitoring tools that would have flagged the intrusion early, six hours is not a reporting deadline. It is a death sentence.

What CERT-In Requires in the Report

When you submit to CERT-In, you are not sending a vague message saying "we think something happened." The report needs to include:

Type of incident. CERT-In has defined categories — unauthorized access, data breach, ransomware, denial of service, website defacement, and others. You need to be able to classify what happened.

Affected systems and estimated impact. Which systems were compromised? How many users affected? What data was potentially exposed? You will not have complete answers in six hours, but you need initial estimates.

Time and method of detection. How did you find out? What tool or person flagged it? This matters because it tells CERT-In whether you have monitoring in place or whether you only found out because a customer called you.

Containment actions taken. What have you done so far to stop the spread? Isolated a server? Revoked credentials? Shut down an API? The report should reflect that you are actively responding, not just reporting.

Contact details. A named individual who CERT-In can follow up with. This person needs to be reachable and technically informed — not just whoever happens to be on a phone.

The DPDP Act Makes It More Complicated

The six-hour CERT-In rule and the DPDP Act operate as separate but overlapping obligations. A breach that triggers CERT-In reporting will almost always also trigger DPDP Act obligations — because most breaches involve personal data.

Under the DPDP Act, you must notify the Data Protection Board of India when a personal data breach occurs. You must also notify the affected individuals — the actual users whose data was compromised.

The penalty for failing to notify the Data Protection Board: up to ₹200 crore. The penalty for inadequate security safeguards that allowed the breach in the first place: up to ₹250 crore.

These penalties do not replace each other. A startup that experiences a breach, fails to secure systems adequately, and delays reporting can face both sets of penalties simultaneously.

The Detection Gap Is Where Everything Falls Apart

Here is the problem that most compliance checklists ignore.

A six-hour reporting window assumes you know about the breach within hours of it happening. In reality, the average detection window in India is measured in months, not hours. Attackers spend weeks inside networks before deploying ransomware or exfiltrating data. During that time, the DPDP Act obligation to implement reasonable security safeguards is being violated continuously — and the company does not know it.

The only way to meet a six-hour reporting obligation in practice is to catch intrusions early — during the reconnaissance phase, before data is exfiltrated or systems are encrypted.

This is where early detection infrastructure becomes a legal argument, not just a security argument. A startup running honeypot-based detection, behavioral monitoring, and automated alerting is in a fundamentally different position than one relying on reactive discovery. When an attacker probes a decoy system at 2 AM, an alert fires. The clock starts from a position of knowledge, not from the moment a customer tweets that their data is on Telegram.

The detection gap is where compliance fails. Closing it is the only way to make the six-hour rule survivable.

What You Need to Have in Place Before a Breach

Do not build your incident response plan during an incident.

Designate a CERT-In reporting contact. This is a named individual whose details are registered with CERT-In and who is responsible for submitting reports. At an early-stage startup, this is the founder. As you scale, it becomes a dedicated role. Either way, it must be documented.

Set up the CERT-In reporting portal access. The portal is at incident.cert-in.org.in. You should have an account, know how to use it, and have tested the submission flow before you need it under pressure.

Document your incident classification criteria. Write down what types of events in your environment would constitute a reportable incident. This prevents the situation where a major breach goes unreported because the person on call was not sure if it counted.

Implement detection infrastructure. You cannot report an incident you do not know about. Behavioral monitoring, honeypot systems, login anomaly detection, and access alerting are not optional for an organization subject to a six-hour reporting mandate.

Draft a breach notification template. For user-facing notifications under the DPDP Act, have a template drafted in advance. Personalizing and sending a pre-written template takes minutes. Writing one from scratch while managing a live breach takes hours you do not have.

Review your third-party vendor contracts. In April 2026, Adobe was breached through an Indian BPO contractor. In 2025, ICICI Bank was targeted through a compromised vendor portal. If your vendors process data on your behalf, their breach is your obligation. Your contracts need to require them to notify you immediately — which means you need to notify CERT-In on a timeline that depends on a vendor calling you.

Frequently Asked Questions — CERT-In Reporting for Indian Startups

What is the CERT-In 6-hour reporting rule? CERT-In's April 2022 directive requires all Indian organizations to report cybersecurity incidents to the Indian Computer Emergency Response Team within six hours of detecting them. The rule applies to all organizations operating digital infrastructure in India, regardless of size.

Does the 6-hour reporting rule apply to startups and small businesses? Yes. There is no size exemption. A 10-person startup that detects unauthorized access to its systems must report to CERT-In within six hours, the same as a large enterprise.

What happens if you miss the CERT-In reporting deadline? Failure to comply with CERT-In's directives can result in penalties and increased regulatory scrutiny. In the context of a concurrent DPDP Act breach, delayed reporting compounds the legal exposure significantly.

How is the DPDP Act reporting obligation different from CERT-In? CERT-In reporting goes to the government incident response body. DPDP Act reporting must go to the Data Protection Board of India and also to affected users. A breach involving personal data triggers both obligations simultaneously.

What is the best way for a startup to meet the 6-hour reporting deadline? The only practical way to meet a six-hour reporting window is to detect breaches early — during the reconnaissance or intrusion phase, not after data has been exfiltrated. Early detection tools, documented response processes, and a pre-registered CERT-In contact are the minimum requirements.

Where do you submit a CERT-In incident report? Reports are submitted through the CERT-In incident reporting portal at incident.cert-in.org.in. Organizations should register and familiarize themselves with the portal before an incident occurs.


CyberSharcX is an early-warning cyber threat detection platform for Indian startups and SMEs. Honeypot-based detection, behavioral analytics, and automated alerting — built so you know about a breach in minutes, not months. Learn more at cybersharcx.in

CyberSharcx

Secure Today, Stronger Tomorrow

Compliance-led breach detection for startups and SMEs — honeypot-verified alerts in minutes, with CERT-In and DPDP regulator-ready reports.

© 2026 CyberSharcx Inc. All rights reserved.