What Is the Cert‑in Breach Reporting in India: Six‑hour Rule, Reportable Events & Penalties

Understanding what is the CERT‑In breach reporting in India is now a baseline compliance requirement for every organisation that operates digital infrastructure on Indian soil. The Indian Computer Emergency Response Team (CERT‑In), functioning under the Ministry of Electronics and Information Technology, mandates that any entity that notices or becomes aware of a qualifying cybersecurity incident must report it within six hours, one of the shortest mandatory notification windows anywhere in the world. With the CERT‑In Directions of 2022 now fully embedded in enforcement practice, and the Digital Personal Data Protection (DPDP) Act adding a parallel layer of data‑breach notification duties, CISOs and general counsel face a multi‑regulator reporting landscape that demands documented, rehearsed response procedures.

This guide sets out the legal basis, the reportable incidents list, the operational six‑hour checklist and the cross‑regulator mapping that in‑house teams need to build a defensible compliance posture.

Executive Summary, What CERT‑In Breach Reporting Is

CERT‑In breach reporting is the mandatory obligation on service providers, intermediaries, data centres, body corporates and government organisations to notify CERT‑In whenever they detect, or are made aware of, a cybersecurity incident that falls within a defined list of reportable events. The obligation is rooted in the Directions issued by CERT‑In under section 70B of the Information Technology Act, 2000, published in the Gazette of India as G.S.R. 20(E). Those Directions require that the report be filed within six hours of the entity first noticing the incident, not within six hours of completing an investigation.

The practical effect is that the clock starts the moment a Security Operations Centre analyst, a managed‑service provider alert, or an automated detection tool flags an anomaly that could constitute a reportable event. Industry observers expect that as enforcement matures through 2026, regulators will scrutinise the gap between initial alert timestamps and actual filing with increasing precision.

Quick Action: The Six‑Hour Reporting Rule, Timeline and First Steps

The six‑hour reporting rule India imposes is aggressive by international standards. The European Union’s NIS 2 Directive allows an initial “early warning” within 24 hours; the United States SEC cyber‑incident disclosure rule gives registrants four business days. India’s six‑hour window demands a pre‑rehearsed, near‑automatic response. The following hour‑by‑hour checklist maps the operational steps to the CERT‑In incident reporting form fields that must be completed.

Hour 0–1: Contain, Scope and Classify

• Isolate affected systems. Disconnect compromised endpoints from the network without powering them down (preserve volatile memory for forensic imaging).
• Classify the incident type. Map it against the CERT‑In reportable incidents list (see the annotated table below). If in doubt, treat the event as reportable, conservative classification is the defensible position.
• Record the “notice” timestamp. Document the exact date and time the incident was first noticed and by whom. This timestamp anchors the six‑hour deadline.
• Activate the incident response team. Notify the designated Point of Contact (PoC), the CISO and in‑house legal counsel.

Hour 1–3: Triage and Evidence Collection

• Collect initial evidence. Firewall logs, intrusion‑detection alerts, system event logs and any indicators of compromise (IoCs) available at this stage.
• Determine preliminary scope. Estimate the number of affected systems, records or users. This feeds directly into the CERT‑In form fields for “scope of impact” and “affected assets.”
• Assess personal‑data involvement. If personal data is involved, flag a parallel DPDP notification obligation for the Data Protection Board.
• Engage external forensics (if needed). Brief the forensic vendor but do not wait for a full forensic report before filing.

Hour 3–6: Approve, Draft and File the CERT‑In Report

• Draft the CERT‑In incident report. Populate the fields specified in the official CERT‑In incident reporting form (certinirform.pdf). Include: incident type, date and time of occurrence, date and time of detection, systems and networks affected, brief description of the incident, preliminary IoCs, and the name, designation and contact details of the reporting officer.
• Obtain internal sign‑off. The authorised signatory, typically the CISO or a designated senior officer, must review and approve the report.
• Submit to CERT‑In. File the report via the channels specified on the CERT‑In SecurityIncident.jsp portal: e‑mail (incident@cert-in.org.in), phone, fax or the online reporting interface. Retain the acknowledgement and tracking number.
• Trigger parallel notifications. Where required, notify sectoral regulators (RBI, SEBI, IRDAI) and, if personal data is compromised, prepare a notification for the Data Protection Board under the DPDP Act.

Who Signs and Files the Report

The CERT‑In Directions require every entity to designate a Point of Contact who shall interface with CERT‑In. This PoC must be an employee of the organisation (not an outsourced vendor) and must be available around the clock. For cyber security incident reporting India purposes, the PoC is typically the CISO, Head of IT Security, or a person of equivalent seniority. The PoC’s name, phone number and e‑mail address must be communicated to CERT‑In proactively as part of standing compliance.

CERT‑In Incident Reporting Form, Required Fields

The official CERT‑In incident reporting form (certinirform.pdf) asks for the following core data points. Preparing a pre‑populated template with standing organisational details reduces drafting time during an incident:

• Organisation details. Name, sector, address, PoC name and contact information.
• Incident classification. Category from the reportable events list (e.g., ransomware, data breach, unauthorised access).
• Date and time. When the incident occurred and when it was first noticed.
• Affected systems. IP addresses, hostnames, operating systems and applications involved.
• Description of the incident. Free‑text narrative of what happened, the attack vector (if known) and current status.
• Impact assessment. Data, services or users affected; business impact.
• Indicators of compromise. Malicious IPs, domains, file hashes, e‑mail addresses.
• Remedial actions taken. Steps already executed to contain and mitigate.

Legal Basis: CERT‑In Directions, IT Act and DPDP Act

Cyber security incident reporting India obligations rest on three interlocking statutory pillars. Understanding which instrument applies, and when more than one applies simultaneously, is critical to building a legally defensible response.

The Information Technology Act, 2000 provides the foundational mandate. Section 70B establishes CERT‑In as the national agency for incident response and empowers it to issue directions relating to information security practices, procedures, prevention, response and reporting of cyber incidents. Failure to comply with directions issued under section 70B is an offence under section 70B(7), which provides for imprisonment of up to one year, a fine of up to one lakh rupees, or both.

CERT‑In Directions (G.S.R. 20(E), 2022) operationalise section 70B. They prescribe the six‑hour reporting window, enumerate the categories of reportable incidents, require mandatory log retention for 180 days, mandate NTP synchronisation of all ICT systems, and impose VPN‑provider record‑keeping obligations. These Directions apply to service providers, intermediaries, data centres, body corporates and government organisations.

The Digital Personal Data Protection Act, 2023 adds a data‑breach‑specific notification layer. Where a cybersecurity incident involves personal data, the Data Fiduciary (controller) is required to notify both the Data Protection Board and each affected Data Principal “without delay.” The DPDP Act applies alongside, not instead of, CERT‑In obligations, meaning a single ransomware attack that exfiltrates personal data can trigger both a CERT‑In report and a DPDP breach notification.

When DPDP Applies vs CERT‑In: Controller and Processor Distinction

The CERT‑In Directions cast a wide net: any entity that notices a reportable incident must report. The DPDP Act, by contrast, places notification duties specifically on the Data Fiduciary (controller). A Data Processor (processor) that detects a breach involving personal data must inform its Data Fiduciary, who then carries the statutory obligation to notify the Data Protection Board and affected Data Principals. The conservative compliance approach is to contractually require processors to alert the fiduciary immediately, ideally within one to two hours, so the fiduciary has enough runway to meet the CERT‑In six‑hour deadline as well.

What Incidents Are Reportable: The CERT‑In List

The CERT‑In Directions enumerate specific categories of reportable cyber incidents. The table below annotates each category with a practical example and the primary evidence an organisation should collect before filing. This annotated list of reportable cyber incidents (CERT‑In list) is not exhaustive, the Directions include a residual category allowing CERT‑In to call for reports on any incident it considers necessary.

If an incident does not neatly fit one of the enumerated categories but could have a material impact on Indian users or infrastructure, the recommended conservative approach is to report it. CERT‑In has indicated that under‑reporting carries greater enforcement risk than over‑reporting.

Who Must Report: The Mandatory Reporting Requirement to CERT‑In

The mandatory reporting requirement to CERT‑In applies broadly. The Directions specifically name the following categories of obligated entities:

• Service providers. Internet service providers, cloud service providers, managed security service providers and any entity offering services over the internet.
• Intermediaries. As defined under section 2(1)(w) of the IT Act, this captures platforms, marketplaces and hosting providers.
• Data centres. Both captive and third‑party data centre operators.
• Body corporates. Any company or firm that handles sensitive personal data or information under the IT Act framework.
• Government organisations. Central and state government agencies and their digital service arms.

In practice, this coverage is near‑universal: any entity running networked digital operations in India is likely captured. Early indications suggest that CERT‑In views the obligation as applying to all organisations with an Indian nexus, including foreign entities whose systems process Indian user data or are integrated with Indian infrastructure.

When a Third‑Party Vendor Must Report

If a managed‑service provider or cloud vendor detects a reportable incident on infrastructure it manages for an Indian client, both the vendor and the client may have independent reporting obligations. The CERT‑In Directions do not excuse the service provider from reporting merely because the client is also filing. Organisations should update vendor contracts and SLAs to require immediate mutual notification, ideally within one to two hours, so both parties can meet the six‑hour window. This contractual discipline also supports compliance with the RBI’s new banking rules in India, which impose additional vendor‑management requirements on regulated financial entities.

Cross‑Notifications and Sectoral Overlaps: DPDP, RBI, SEBI, IRDAI and TRAI

A single cybersecurity incident can trigger notifications to multiple regulators. The table below maps each regulator, the event that triggers its notification requirement and the practical action to take. Coordination of these parallel obligations is essential to avoid both duplicated effort and missed deadlines.

The recommended sequence is: file with CERT‑In first (it has the shortest deadline), then immediately prepare the DPDP notification if personal data is affected, and file with sector regulators in parallel. Where an entity is regulated by both CERT‑In and the RBI (for example, a payments bank), maintaining a unified incident log that serves both reporting formats reduces duplication. For banks navigating the overlap, a detailed analysis of the RBI new banking rules 2026 is essential.

Penalties, Enforcement Posture and Practical Mitigation

Non‑compliance with CERT‑In Directions carries statutory consequences under section 70B(7) of the Information Technology Act: imprisonment of up to one year, a fine of up to one lakh rupees, or both. While these headline penalties may appear modest, the real risk is compounding: a single incident can attract enforcement actions from CERT‑In, the Data Protection Board (which can impose penalties of up to ₹250 crore under the DPDP Act for breaches of its provisions), and sector regulators whose sanctions include licence conditions, monetary penalties and public censure.

Industry observers note that CERT‑In’s enforcement posture has matured considerably since the Directions first took effect. Early indications suggest a shift from advisory notices to formal non‑compliance proceedings, particularly where an entity knew of an incident and failed to report it, or where log‑retention failures frustrated post‑incident analysis. The likely practical effect is that organisations without a documented, rehearsed six‑hour response plan face significantly greater enforcement exposure in 2026 than in prior years.

Practical Mitigation Steps

• Pre‑populate the CERT‑In form. Standing organisational details, PoC information and system inventories should be ready before any incident occurs.
• Run quarterly tabletop exercises. Simulate a ransomware or data‑breach scenario and drill the full six‑hour timeline, including internal escalation, evidence collection, form drafting and regulator notification.
• Retain logs for a minimum of 180 days. The CERT‑In Directions mandate this. NTP‑synchronise all systems so log timestamps are forensically reliable.
• Document everything. Maintain a written incident chronology from first alert to final resolution. This record is the primary evidence of good‑faith compliance if enforcement action follows.
• Consider legal privilege. Engage external legal counsel early in the response. Communications made for the dominant purpose of obtaining legal advice may attract privilege, but this is fact‑specific, do not assume privilege will protect all internal communications. The conservative approach is to channel sensitive legal analysis through external counsel and mark it clearly as privileged.

Organisations facing severe incidents, particularly those that could trigger insolvency proceedings or force the closure of a company, should engage board‑level oversight and notify cyber‑insurance carriers immediately.

Practical Templates and Checklist Downloads

Below is a ready‑reference template mapping the key CERT‑In incident reporting form fields to the internal information sources that should feed them. Use this as a pre‑incident preparation tool: fill in all standing fields now and store the template where the incident response team can access it within minutes.

The official CERT‑In incident reporting form (certinirform.pdf) can be accessed directly from the CERT‑In website. Organisations should also prepare a parallel internal legal memo template that records the decision‑making rationale for classifying an event as reportable, the legal basis for any notifications triggered and any privilege‑related instructions issued to the response team.

For organisations that also need to protect intellectual property assets as part of post‑breach remediation, understanding the cost and process of trademark registration in India can be relevant where brand impersonation or domain spoofing is involved.

Conclusion: What CERT‑In Breach Reporting in India Means for Your Organisation

The question of what is the CERT‑In breach reporting in India is no longer academic, it is an operational imperative with criminal‑law consequences. Every CISO and general counsel should take three immediate steps. First, run a tabletop exercise simulating the full six‑hour reporting timeline, testing whether your team can contain, triage, draft and file within the window. Second, update all vendor contracts and SLAs to require immediate mutual notification of cybersecurity incidents, giving your organisation enough lead time to meet its own filing obligations. Third, brief the board and notify your cyber‑insurance carrier proactively, so that when an incident occurs, escalation paths are clear and coverage is not jeopardised by late reporting.

Organisations seeking tailored guidance on CERT‑In readiness, DPDP compliance and cross‑regulator coordination can connect with specialist TMT counsel through the Global Law Experts lawyer directory.

Sources

1. CERT‑In, Reporting of a Security Incident
2. CERT‑In, Incident Reporting Form (certinirform.pdf)
3. CERT‑In, G.S.R. 20(E) Directions
4. Digital Personal Data Protection Act, 2023, Official Gazette of India
5. Information Technology Act, 2000, India Code
6. Supreme Court of India, Justice K.S. Puttaswamy v. Union of India
7. Reserve Bank of India, Cyber Security Guidelines and Circulars