CERT-In 6-Hour Breach Reporting Rule: Everything You Need to Know

What Is the CERT-In 6-Hour Rule?

Just before the summer of 2022 a major change came in when on 28 April 2022, India's Computer Emergency Response Team (CERT-In) published some important directions under Section 70B(6) of the Information Technology Act 2000. These directions became law in effect on 27 June 2022. They require all service providers, intermediaries, data centres, body corporates, and government organisations operating in India to report designated cybersecurity incidents to CERT-In within six hours of first becoming aware of them.

This is one of the most aggressive breach-notification timelines in the world. Here's how India's 6-hour rule stacks up against other major jurisdictions:

India's 6-hour rule is 12 times faster than GDPR's 72-hour standard — and unlike GDPR, it applies regardless of whether individuals are at risk. The CERT-In window runs 24/7, including weekends and public holidays.

Crucially, the 6-hour requirement is for an initial report — not a complete investigation. You do not need to know the full extent of the breach within 6 hours. You need to report what you know: that an incident has occurred, its approximate category, and the systems affected. Supplementary reports with more details can be filed as the investigation goes on.

Who Must Comply

The CERT-In Directions apply broadly — there is no size exemption, sector carve-out, or revenue threshold. The following categories of entity must comply:

• All companies registered in India — under the Companies Act 2013 or any prior legislation
• Foreign companies operating in India — or providing services to Indian users from abroad
• Internet Service Providers (ISPs) and Telecom Service Providers
• Data centres and cloud service providers — including AWS, Azure, GCP customers operating infrastructure for Indian services
• Virtual Private Server (VPS) providers
• Intermediaries — social media platforms, e-commerce marketplaces, search engines, payment aggregators
• Government ministries, agencies, and public sector undertakings
• Startups and SMEs — there is explicitly no minimum size threshold

A Series A startup with 50 employees processing personal data of Indian users must comply with the CERT-In 6-hour rule just as a multinational corporation with thousands of employees must. This is a common point of confusion — many founders assume CERT-In applies only to large enterprises or critical infrastructure operators. It does not.

What Incidents Trigger Reporting

The CERT-In Directions specify 18+ categories of reportable incidents. The list is intentionally broad — virtually any cybersecurity event at an Indian organisation falls within scope. It covers a pretty long list of stuff, including all sorts of malicious activity like probes into critical networks, compromises of important systems or information getting into the wrong hands, unauthorised access to computers or data, and websites getting defaced or modified without permission. Some specific examples:

CERT-In vs DPDP: Two Separate Clocks Running

When a data breach occurs at an Indian organisation, two separate, overlapping legal obligations are triggered simultaneously. They have different timelines, different recipients, and different required information:

These obligations are not duplicative — they serve entirely different legal purposes. CERT-In is concerned with cybersecurity posture and national infrastructure protection. The DPDP breach notification is concerned with protecting individual data principal rights under the DPDP Act 2023. Both must be met independently. Failing to file either report has separate legal consequences under separate statutes.

For organisations that are also subject to GDPR (EU data), a third clock may also be running: GDPR's 72-hour notification to the relevant EU supervisory authority. However, GDPR applies only to breaches involving EU residents' data. The CERT-In 6-hour obligation applies to the incident itself, regardless of whose data was involved.

What to Include in a CERT-In Report

The initial 6-hour report does not require a complete incident picture. File what you know. CERT-In explicitly accommodates incomplete initial reports followed by supplementary filings. The initial report should include:

1. Reporting entity details — Name, registered address, contact person name, designation, phone, and email
2. Date and time of detection — When your organisation first became aware of the incident (this starts your 6-hour clock)
3. Incident category — From the CERT-In list (ransomware, data breach, DDoS, etc.)
4. Systems and services affected — Which IT systems, networks, services, or applications are impacted
5. IP addresses and domains — Any attacker IPs, malicious domains, or affected server addresses (if known)
6. Estimated impact — Approximate number of users or records affected; services disrupted
7. Attack description — Initial understanding of how the incident occurred (attack vector, if known)
8. Containment measures taken — What your team has already done to contain the incident

How to File a CERT-In Report

CERT-In provides three channels for incident reporting:

Method 1 — CERT-In Online Portal

Just head on over to https://www.cert-in.org.in and navigate over to "Report an Incident". The portal has a pretty straightforward form that matches up with CERT-In's categories for incident reporting. This is the best way to go about it because it makes sure you get all the right info filled out and you'll even get an acknowledgement with a reference number to boot. As you'd expect, this is the preferred method as it's just about the safest way to do things.

Method 2 — Email

If the online portal is out of commission or your organisation's web access has been compromised, you can send your incident report to incident@cert-in.org.in. When you do this, make sure to give your email a clear subject line that includes all the relevant details — "Cybersecurity Incident Report — [Company Name] — [Date] — [Incident Type]" kind of thing. Throw in all the fields from the list above and you're good to go. Email is a good option when you can't get to the portal.

Method 3 — Phone (Critical Incidents)

If you're dealing with something big — I mean, a critical infrastructure breach or something that poses a pretty serious national security risk — then give CERT-In helpdesk a ring on +91-1800-11-4949 (24/7, toll-free). This is the way to go, especially if you need to get a message across right away.

Penalties for Non-Compliance

Failure to comply with CERT-In Directions is a punishable offence under Section 70B(7) of the IT Act 2000. Penalties include:

• Imprisonment up to 1 year
• Fine up to ₹1 Lakh
• Both fine and imprisonment may be imposed simultaneously

Beyond criminal penalties, CERT-In may name non-compliant entities in public advisories, creating significant reputational risk. For regulated sectors — banking (RBI), insurance (IRDAI), telecommunications (TRAI), and securities (SEBI) — CERT-In non-compliance can trigger separate sectoral regulator action and reporting obligations under those sector-specific frameworks.

The DPDP Act has separate, additional penalty provisions for breach notification failures: up to ₹200 Crore for failure to notify the Data Protection Board of a personal data breach (DPDP Act Schedule, Item 3). This is a distinct obligation from CERT-In and carries its own penalties.

The Real-World Challenge: 6 Hours Is Extremely Tight

We have to face the fact here that six hours from the time you detect the incident to the time you submit your report is a crazy tight timeline. Let's take a look at what that looks like in real life:

• Hour 0:00 — SIEM alert fires or a user reports suspicious activity
• Hour 0:30 — Security analyst assesses whether this is a genuine incident or false positive
• Hour 1:30 — Incident confirmed; escalation to CISO and management
• Hour 2:00 — Incident response team assembled; initial containment begins
• Hour 3:00 — Legal team briefed; CERT-In report preparation begins
• Hour 5:00 — Report reviewed and filed with CERT-In
• Hours 6–72 — Continue investigation; prepare DPDP Board notification; assess individual data principal notifications

This optimistic timeline assumes instant incident detection, rapid false-positive elimination, and a pre-existing incident response playbook. In practice, many organisations discover incidents hours or days after they begin — compressing the available window further.

The 6-hour compliance window is only consistently achievable with: (1) 24/7 automated monitoring and alerting, (2) pre-built incident response playbooks with clear escalation paths, (3) pre-drafted CERT-In report templates that can be quickly populated, and (4) a platform that automatically timestamps the moment of "first awareness" — which starts the legal clock.

How Consiva Automates Both Timers

Consiva's Breach Response module addresses the multi-timer challenge directly. When a potential security incident is logged in Consiva — either manually by your security team, or automatically via API integration with your SIEM, EDR, or cloud security platform — the platform immediately takes the following actions:

• Timestamps the detection event in an immutable log, establishing the legal "first awareness" time
• Starts the CERT-In 6-hour countdown with a visible timer and escalation notifications at 2 hours, 4 hours, and 5 hours remaining
• Starts the DPDP Board 72-hour countdown simultaneously, with its own notification schedule
• Auto-generates a CERT-In report draft from the incident data entered — pre-filling organisation details, incident category, systems affected, and initial description from your IT asset inventory
• Guides your team through the incident classification — assessing whether personal data was involved (triggering DPDP obligations), and whether the risk level requires data principal notifications
• Stores all incident events, report submissions, and notification records in an immutable audit log exportable for regulatory review

The CERT-In report draft can be reviewed and submitted directly from the Consiva interface in minutes, rather than requiring your team to construct the report from scratch under time pressure. After the CERT-In report is filed, Consiva tracks your DPDP Board notification separately, including the separate assessment of whether affected data principals must be individually notified. For a platform that handles both, see our pricing plans or start your free trial.

Step-by-Step Breach Response Checklist

1. Detect and confirm the incident — Verify it is genuine, not a false positive. Log the exact date and time of confirmation — this is your legal "time of first awareness" that starts the CERT-In clock.
2. Contain immediately — Isolate affected systems from the network, revoke compromised credentials, block malicious IP ranges. Prioritise containment over investigation in the first hour.
3. Notify CERT-In within 6 hours — File an initial report via the CERT-In portal (cert-in.org.in) or email (incident@cert-in.org.in) with available information. Incomplete reports are acceptable — timeliness matters more than completeness at this stage.
4. Preserve evidence — Take forensic images of affected systems before remediation. Do not overwrite logs. CERT-In requires 180-day log retention; preserve them for the investigation period plus the regulatory retention minimum.
5. Assess personal data impact — Which categories of personal data were exposed? How many data principals are affected? This assessment determines the DPDP Board notification requirement and the individual data principal notification requirement.
6. Notify the Data Protection Board — File the DPDP breach notification within the prescribed timeline (expected 72 hours per draft Rules). Document the nature of the breach, affected data, likely consequences, and measures taken.
7. Assess data principal notification — If the breach is likely to result in high risk to affected individuals (identity theft, financial fraud, physical harm), notify them directly with information about the breach and steps they can take.
8. Conduct a root cause analysis — Once the incident is wrapped up, look at how it went down. Document the attack vector, the vulnerability that was exploited, the systems that got hit and the timeline of events.
9. Implement remediation steps — Patch the vulnerabilities that got exploited, get the configs updated, retrain the staff on phishing & social engineering so they can spot the risks next time, and plug any gaps in your monitoring.
10. File a supplementary CERT-In report — Update that initial report with all the details you found out — what happened, how you fixed it, and any other systems or users you figure out got caught up in the mess.