CERT-In Cyber Incident Reporting Interface with Cyber Insurance Programmes India 2026

The Indian Computer Emergency Response Team (CERT-In) issued sweeping directions on 28 April 2022 under Section 70B(6) of the Information Technology Act 2000, titled Directions relating to information security practices, procedure, prevention, response and reporting of cyber incidents for safe and trusted internet. The Directions imposed a 6-hour reporting obligation on Indian entities (and entities providing services in India) for a defined list of cyber incident categories. The Directions were operational from 28 September 2022 for general entities and 25 June 2022 for Virtual Private Server (VPS) providers and similar specified categories.

The Directions broke from the prior reporting regime in three respects. First, the 6-hour clock was significantly tighter than the 72-hour reporting baseline familiar from international frameworks (GDPR, US state breach laws). Second, the incident category list was broad, covering 20 categories ranging from targeted scanning and probing through ransomware to cryptocurrency theft. Third, the log retention requirement of 180 days for ICT systems with mandatory production on CERT-In request created an operational baseline that affected the cyber insurance underwriting and claims framework directly.

The Directions attracted significant industry concern over scope creep, the 6-hour timeline practicality, and the log retention scale. CERT-In issued FAQ clarifications in May 2022 and additional clarifications across 2022 to 2024 that softened specific operational aspects (clarifying that internal scanning and probing not impacting third parties may be excluded, specifying acceptable log formats, addressing the cloud-services reporting interaction). The 2024 to 2026 operational reality reflects both the rigid 6-hour standard and the practical interpretations that have emerged through enforcement experience.

For commercial insurance buyers and brokers, the CERT-In framework reshapes the interface between cyber incident response and cyber insurance claim management. The insurer's notice clause, the policy's claim cooperation language, the multi-jurisdictional reporting overlap, and the log retention requirement all intersect with the broader cyber risk programme. A buyer that treats CERT-In as a discrete regulatory check rather than an integrated component of the cyber programme will face friction at the claim point that materially affects recovery.

The enforcement posture has tightened across 2023 to 2026. CERT-In has issued multiple information requisition notices and non-compliance observations to entities, and the CERT-In coordination with sectoral regulators including RBI, SEBI, and IRDAI has produced a multi-regulator review framework for cyber incidents at financial sector entities. Insurance brokers operating in this environment need to understand the framework in operational detail, not just in regulatory summary.

The CERT-In Directions specify the reporting obligation in operational detail that brokers, insureds, and incident response teams must internalise. The framework has three dimensions: the timing, the categories, and the reporting mechanics.

The 6-hour timing

The reporting must occur within 6 hours of noticing the incident or of becoming aware of the incident. The 'noticing' language is operationally important because it pins the clock to the first awareness rather than to confirmation of the incident's full scope. An entity that notices unusual network behaviour at 14:00 has until 20:00 to file the initial report, even if the investigation will continue well beyond.

The 6-hour clock starts running on detection, not on resolution. Initial reports are expected to contain known information, with follow-up reports providing additional detail as the investigation progresses. The CERT-In FAQ clarifies that initial reports do not need to contain all information about the incident, and the obligation is for the entity to report what it knows at the time, with structured follow-up.

The 20 incident categories

The Directions cover 20 incident categories, organised loosely as follows.

1. Targeted scanning and probing of critical networks and systems.
2. Compromise of critical systems and information.
3. Unauthorised access to IT systems and data.
4. Defacement of website or intrusion into website.
5. Malicious code attacks including ransomware.
6. Attacks on servers and network appliances.
7. Identity theft, spoofing and phishing attacks.
8. Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks.
9. Attacks on critical infrastructure, SCADA and operational technology systems.
10. Attacks on application platforms including e-governance and e-commerce platforms.
11. Data breach and data leak.
12. Attacks on Internet of Things devices and associated systems.
13. Attacks or incidents affecting digital payment systems.
14. Attacks through malicious mobile applications.
15. Fake mobile applications.
16. Unauthorised access to social media accounts.
17. Attacks or malicious or suspicious activities affecting cloud computing systems.
18. Attacks or malicious or suspicious activities affecting systems related to Big Data, Blockchain, virtual assets, virtual asset exchanges, custodian wallets, robotics, 3D and 4D printing.
19. Attacks on systems related to artificial intelligence and machine learning.
20. Other incidents affecting safety, security, integrity, availability or trust of information processing systems.

The breadth of the categories is operationally challenging. Category 20 in particular is broad enough that many entity-internal incidents arguably fall within scope even where the entity would otherwise consider them routine.

Reporting mechanics

The report must be filed with CERT-In through the prescribed mechanism, which includes:

1. Email to incident@cert-in.org.in with the prescribed information.
2. Web portal submission through the CERT-In portal with structured forms.
3. Phone helpline for urgent incidents requiring immediate engagement.
4. Fax as a fallback channel (still listed in the formal Directions).

The prescribed information includes the entity identity, the incident category, the date and time of detection, the nature and impact, the systems affected, the data categories affected, the response actions initiated, and the contact for follow-up. The information density expected in the initial report has been calibrated by CERT-In through experience, with the FAQ noting that limited information at initial reporting is acceptable provided structured follow-up occurs.

Scope considerations: who is covered

The Directions apply to:

1. Entities in India including government, public sector, private sector, businesses, and individuals.
2. Foreign entities providing services in India including cloud providers, SaaS providers, and platform operators with Indian users.
3. Specific category entities including data centres, body corporates, service providers, intermediaries, government organisations, and cryptocurrency exchanges.

The broad scope creates jurisdictional reporting overlaps that the multi-jurisdictional section below addresses. An entity may simultaneously have reporting obligations under CERT-In, the DPDP Act, the SEBI cyber framework for listed entities, the RBI cyber framework for regulated financial entities, the US SEC for SEC-registered entities, the EU GDPR for European data, and other applicable frameworks.

The CERT-In Directions attracted significant industry feedback on scope creep when issued in 2022, and the operational interpretation through 2024 to 2026 has settled around specific practical positions. Understanding the operational interpretation matters for brokers and insureds because the gap between the literal text of the Directions and the practical compliance expectation is material.

The probing and scanning category

Category 1 (targeted scanning and probing of critical networks and systems) was initially read by some commentators as covering ordinary external scanning of any internet-facing systems. The CERT-In FAQ clarified that this category applies to targeted scanning of critical networks, with 'critical' referring to systems whose compromise would have material impact rather than to all internet-facing systems. The practical interpretation in 2026 is that ordinary background scanning of public-facing systems does not require reporting, but scanning that shows targeted reconnaissance against specific critical systems does.

Internal incidents not affecting third parties

The initial industry concern was that internal incidents within an entity's own systems (a failed employee phishing test, an isolated malware infection on a single endpoint contained immediately) would require reporting. The CERT-In FAQ clarified that internal incidents without third-party impact may be excluded from reporting, though the entity should document the impact assessment.

The practical interpretation in 2026 is that incidents with confirmed containment within the entity's own perimeter, no data exfiltration, no third-party impact, and no continuing risk may not require reporting. The entity should document the basis for the no-report decision in the incident response file for inspection-readiness.

The cloud and SaaS service interaction

For entities using cloud or SaaS services, the reporting obligation interaction with the cloud provider's own reporting was initially unclear. The 2024 to 2026 interpretation is that:

1. The cloud provider reports incidents affecting its infrastructure (the platform-level incidents).
2. The cloud customer reports incidents affecting its own data or services, even where the underlying platform is cloud-hosted.
3. Joint incidents affecting both platform and customer scope require coordination between cloud provider and customer.

In practice, multinational cloud providers (AWS, Azure, Google Cloud) have engaged with CERT-In on platform-level reporting frameworks. Customers report incidents specific to their tenancy, with the cloud provider's role as platform host noted in the customer's report where relevant.

The threshold interpretation

The Directions do not specify a quantitative threshold below which incidents need not be reported. The practical interpretation is that:

1. High-impact incidents (ransomware, data breach with material data, sustained DDoS, SCADA attack) require reporting regardless of quantum.
2. Lower-impact incidents with minimal third-party effect and confirmed containment may not require reporting with documented basis.
3. Pattern incidents (multiple low-impact incidents indicating a broader campaign) require reporting on the pattern recognition.

The absence of a hard threshold creates judgment calls for incident response teams. The discipline is to document each no-report decision with the basis, the impact assessment, and the senior approval.

Information requisition and follow-up

CERT-In has demonstrated active follow-up on reports through information requisition notices issued under Section 70B(6) of the IT Act. The notices request specific information beyond the initial report, including:

1. Detailed forensic findings as the investigation progresses.
2. System logs for the relevant period under the 180-day retention requirement.
3. Communication with attackers in ransomware or extortion cases.
4. Decryption tool or key information where available.
5. Customer or third-party impact assessment in detail.

The information requisition response is mandatory under Section 70B(6), with non-compliance attracting penalty up to INR 1 lakh per day of continuing non-compliance under the IT Act Section 70B(7).

The cyber incident reporting framework under CERT-In sits alongside multiple other reporting regimes, creating a multi-notification reality that incident response teams must manage. The most operationally important interaction is with the Digital Personal Data Protection Act 2023 (DPDP Act) and the Data Protection Board regime.

The DPDP breach reporting timeline

The DPDP Act and the DPDP Rules notified through 2024 to 2025 require data fiduciaries to report personal data breaches to the Data Protection Board and to affected data principals within prescribed timelines. The rules establish a 72-hour reporting window to the Board for most personal data breach categories, with notification to data principals within timelines that vary with breach severity.

Where CERT-In and DPDP overlap

A cyber incident involving personal data triggers both reporting regimes:

1. CERT-In reporting within 6 hours under the IT Act framework.
2. DPDP Data Protection Board reporting within 72 hours under the DPDP framework.
3. DPDP data principal notification within the timeline appropriate to severity.

For a ransomware incident affecting customer database with personal data, all three reporting streams run concurrently. The reports must be consistent on the facts (date and time of detection, scope of data, impact assessment) while addressing the specific information requirements of each regime.

Operational implications of dual reporting

Three operational disciplines support coherent multi-regulator reporting.

1. A single incident timeline maintained by the incident response team, with each regulator report drawing from this timeline.
2. Coordinated drafting of CERT-In and DPDP reports to ensure factual consistency, with separate emphasis on the information specific to each regime.
3. Senior approval discipline with the same senior executive (typically the CISO or CIO with legal counsel input) approving both reports to ensure consistency.

The sequencing typically runs:

1. 0 to 6 hours: CERT-In initial report.
2. 6 to 24 hours: Initial DPDP impact assessment, incident scope refinement, internal escalation.
3. 24 to 48 hours: DPDP report drafting, additional CERT-In follow-up.
4. 48 to 72 hours: DPDP Board report submission, data principal notification planning.
5. 72 to 168 hours: Continued CERT-In information requisition response, data principal notification execution, regulator coordination.

Multi-jurisdictional layer for global entities

For multinational entities with operations in multiple jurisdictions, the reporting layer extends further:

1. CERT-In for incidents affecting India operations or Indian data.
2. DPDP for incidents affecting personal data of Indian data principals.
3. EU GDPR for incidents affecting personal data of EU data subjects (72-hour reporting to the relevant data protection authority).
4. US state breach laws for incidents affecting US residents under the 50-state mosaic of breach notification laws.
5. US SEC for SEC-registered entities under the 8-K disclosure framework requiring reporting within 4 business days of materiality determination.
6. UK ICO for UK data subjects under the UK GDPR framework.
7. Other applicable national breach notification regimes depending on geographical footprint.

A listed Indian IT services company with US clients and EU operations faces concurrent reporting under CERT-In (6 hours), DPDP (72 hours), GDPR (72 hours to EU regulator), US state laws (varying), and SEC (4 business days from materiality determination). Coordinating these timelines requires structured incident response capability with legal counsel engaged from the first hours.

Cyber insurance interface

The cyber insurance policy's notice clause typically requires the insured to notify the insurer of an actual or potential claim within a specified period (commonly 7 to 30 days for many wordings, with some carriers requiring as soon as practicable). For Indian operations, the insurer notice runs in parallel with the regulatory notifications. The broker's role is to coordinate insurer notice with the regulatory reporting, ensuring the insurer is engaged early enough to influence the incident response but the insured retains control of regulator-facing communications.

Cyber insurance policies in the Indian market are diverse in wording, but most share a common structure for notice and claim cooperation. The CERT-In framework intersects with this structure in specific ways that brokers and insureds need to understand.

Standard notice clause provisions

A typical cyber insurance notice clause requires the insured to:

1. Notify the insurer of any actual or suspected incident likely to give rise to a claim, within a defined period (commonly as soon as practicable with a hard outer limit of 30 to 90 days).
2. Provide such information as the insurer reasonably requests including incident details, response actions, and counterparty communications.
3. Cooperate with the insurer's investigation and any panel forensic firm appointed by the insurer.
4. Not admit liability or settle any matter without insurer consent.
5. Coordinate communication with the insurer on regulatory engagement and public-facing communication.

The notice clause language varies materially across carriers, with London market wordings often more sophisticated than domestic Indian wordings. Brokers should review the specific notice language at policy inception and ensure the insured's incident response procedures align with the notice requirements.

Where CERT-In interacts with notice and cooperation

The 6-hour CERT-In timeline creates specific interaction points with the cyber insurance policy.

1. The CERT-In report content is published-facing (in the sense that the regulator has visibility) and can be cited in subsequent litigation or regulatory proceedings. The insurer has a legitimate interest in reviewing the report before submission where time permits, but the 6-hour clock typically does not permit insurer review of the initial report.
2. The CERT-In follow-up reports provide more time for insurer review. The follow-up communications should be coordinated with the insurer panel firm where appointed.
3. The CERT-In information requisition response with detailed forensic findings sits squarely within the insurer's panel firm's work. The insurer should be engaged on the response content.
4. The DPDP reports typically benefit from longer time for insurer coordination given the 72-hour window.

The 'panel firm' framework

Most cyber insurance policies operate a panel framework where the insurer has pre-arranged forensic firms, legal counsel, public relations advisors, and other specialist providers. The panel firms can be engaged at no incremental cost to the insured (or at preferred rates) on the insurer's account.

The panel framework operational reality in India in 2026 includes:

1. Forensic firms with India presence including Big Four advisory firms, specialised forensic firms, and global providers with Indian offices.
2. Legal counsel with cyber-specific experience and CERT-In familiarity.
3. Public relations firms with crisis communication capability.
4. Ransomware negotiators with experience of Indian regulatory framework on ransom payment.
5. Notification vendors with capability to execute data principal notification at scale.

Brokers should review the insurer's panel for India relevance at policy inception, with attention to firms that have experience with CERT-In and DPDP coordination. A panel that is strong on US or UK incident response but weak on Indian regulatory experience may produce friction at incident time.

Claim cooperation in the CERT-In environment

The claim cooperation language in the policy is operationally important when the incident response and the CERT-In engagement intersect with the claim process.

For a ransomware incident with regulatory reporting and claim implications:

1. The insured's incident response team runs the technical containment and recovery.
2. The insurer panel forensic firm runs the forensic investigation and findings.
3. The insurer panel legal counsel coordinates regulatory reporting language and external communications.
4. The broker coordinates between the insured, the insurer, and the panel firms with structured oversight on cooperation discipline.
5. The internal CISO or CIO owns the CERT-In primary relationship and the regulator-facing communication.

The respective roles must be defined and documented before incident time. A common failure pattern is unclear ownership of CERT-In communications, with multiple parties drafting potentially inconsistent reports.

Ransom payment cooperation

The specific cooperation requirement around ransom payment merits separate attention. The cyber insurance policy may cover ransom payment up to a sub-limit, but the payment requires structured insurer cooperation:

1. Pre-payment authorisation with insurer review of the ransom demand, the criminal threat assessment, and the regulatory compliance position.
2. OFAC and sanctions screening of the threat actor to confirm payment legality.
3. Payment mechanics through specialised vendors with the appropriate documentation.
4. CERT-In communication of the payment fact and the surrounding circumstances.
5. Tax and legal treatment with documentation for the audit trail.

The broker's role in ransom payment is significant, coordinating across the insured's internal team, the insurer panel, the regulator engagement, and the payment vendor.

The CERT-In Directions require ICT systems to retain logs for 180 days with mandatory production to CERT-In on request. The log retention requirement is operationally significant because it sets a floor for the forensic evidence available at incident time, with implications for both regulatory reporting and cyber insurance claim defensibility.

The scope of log retention

The 180-day requirement applies to logs of:

1. Operating systems including authentication, authorisation, and system-level events.
2. Applications including user activity, transactions, and application-level events.
3. Network devices including firewalls, routers, switches, and intrusion detection systems.
4. Cloud services for the entity's tenancy.
5. Email systems for messaging trails.
6. Endpoint systems for end-user device activity.

The 180-day retention is a floor. Many entities retain logs for longer periods (1 year, 2 years, or more) under their internal security policy or under specific regulatory regimes (RBI cyber framework, SEBI cybersecurity framework, IRDAI Information Security Guidelines 2023).

Log integrity and availability

The log retention requirement implies log integrity (the logs must be reliable evidence of the system activity) and log availability (the logs must be retrievable on request). For both requirements, the operational disciplines include:

1. Log centralisation in a Security Information and Event Management (SIEM) system with structured retention.
2. Tamper-evident storage ensuring logs cannot be modified post-collection.
3. Backup and disaster recovery ensuring log availability through system failures.
4. Retrieval testing with periodic exercises confirming log accessibility on request.
5. Documentation of retention policies and the technical implementation.

Forensic value of log retention

For cyber incident response and cyber insurance claim defence, the 180-day log retention is a baseline forensic capability. The logs support:

1. Incident timeline reconstruction showing how the incident developed.
2. Threat actor activity analysis showing what the attacker did.
3. Data exfiltration evidence showing what data left the environment.
4. Containment validation showing that the incident has been contained.
5. Causation analysis for cyber insurance claim purposes.

An entity without adequate log retention faces challenges at every step. The CERT-In information requisition response is hampered, the DPDP impact assessment is uncertain, and the cyber insurance claim faces causation and quantum challenges.

The IRDAI Information Security Guidelines 2023 overlap

The IRDAI Information Security Guidelines 2023 apply to insurers and intermediaries (including brokers) and impose log retention requirements that overlap with the CERT-In framework. The Guidelines specify log retention periods that match or exceed the 180-day CERT-In floor.

For insurance brokers, the layered requirement is:

1. CERT-In for general ICT system logs (180-day floor).
2. IRDAI Information Security Guidelines for insurance-specific logs.
3. DPDP for logs relating to personal data processing.
4. Companies Act for accounting and statutory records.

The broker should integrate the requirements in a single log retention policy with the most restrictive requirement applied for each log category.

Practical investment in log infrastructure

For a mid-market commercial broker (annual revenue INR 25 crore to INR 100 crore), the log infrastructure investment to support CERT-In, DPDP, and IRDAI compliance typically runs:

1. SIEM platform at INR 35 lakh to INR 1.5 crore initial setup plus annual subscription.
2. Log storage at INR 12 lakh to INR 40 lakh annually depending on volume.
3. Operational staffing for SIEM monitoring at INR 25 lakh to INR 80 lakh annually.
4. Forensic readiness through retainer or panel arrangements at INR 8 lakh to INR 25 lakh annually.
5. Periodic audit and testing at INR 6 lakh to INR 15 lakh annually.

The total investment of INR 86 lakh to INR 3.6 crore annually is significant but proportionate to the regulatory and claim exposure. Brokers without this investment face substantial gaps that surface at incident time.

For commercial insurance brokers and insureds operating in the CERT-In environment, the operational discipline required to manage incident reporting alongside cyber insurance claim management is material. The capability building requires structured investment across people, process, and technology.

The incident response runbook

The foundation of CERT-In compliance is a structured incident response runbook that walks the response team through detection, assessment, reporting, response, and recovery with specific time gates.

A structured runbook for the Indian environment contains:

1. 0 to 1 hour: Detection and initial assessment. Confirm the incident is real (not a false positive). Initial categorisation against CERT-In categories. Senior escalation triggered.
2. 1 to 4 hours: Scope assessment. What systems, what data, what users. Containment actions initiated. Insurer pre-notice consideration.
3. 4 to 6 hours: Initial CERT-In report drafting and submission. Insurer formal notice if claim is likely.
4. 6 to 24 hours: Investigation continuation. Insurer panel firm engagement. Internal stakeholder communication.
5. 24 to 72 hours: DPDP Board report drafting and submission if personal data is involved. Additional CERT-In follow-up reports.
6. 72 to 168 hours: Data principal notification execution if applicable. Customer and counterparty communication. Continuing forensic investigation.
7. Beyond 168 hours: Cyber insurance claim formal submission. Continuing regulator engagement. Post-incident review.

The runbook should be tested through tabletop exercises annually, with named individuals walking through their roles in simulated incidents. Tabletop exercises also identify gaps in the framework that need remediation.

Named accountability across the response

The response framework must have named accountability with backups for unavailability. The principal roles are:

1. Incident Commander typically the CISO or CIO with overall coordination authority.
2. CERT-In Liaison with primary regulator-facing responsibility.
3. DPDP Liaison typically a designated Data Protection Officer.
4. Insurer Liaison typically the broker's claims advocate or the insured's risk manager.
5. Forensic Lead from the panel firm or internal team.
6. Legal Counsel with cyber and regulatory experience.
7. Communications Lead for internal and external messaging.
8. Business Continuity Lead for operational recovery.

The responsibilities and decision authority of each role should be documented in the runbook, with the chain of command for decisions that require multiple-role coordination.

Technology readiness

The technology stack supporting incident response includes:

1. SIEM platform for log aggregation and alerting.
2. Endpoint Detection and Response (EDR) for endpoint-level visibility.
3. Network monitoring for traffic-level analysis.
4. Forensic tools for incident investigation.
5. Communication tools for crisis communication (out-of-band channels in case primary systems are compromised).
6. Documentation systems for incident tracking and evidence preservation.

Periodic readiness validation

Readiness should be validated through:

1. Annual tabletop exercises simulating specific incident types.
2. Quarterly runbook reviews updating for regulatory changes.
3. Semi-annual SIEM and EDR validation confirming detection and response capability.
4. External penetration testing at least annually.
5. Vendor and third-party incident readiness reviews confirming downstream coordination capability.

The 2026 to 2027 trajectory

Looking ahead, the regulatory trajectory points to:

1. Continued CERT-In activism with more information requisitions and enforcement actions.
2. DPDP Board operationalisation with the first significant penalty actions emerging through 2026 to 2027.
3. Sectoral regulator engagement with RBI, SEBI, and IRDAI deepening their cyber incident review for regulated entities.
4. Bima Sugam onboarding introducing additional cyber requirements for insurance entities participating in the marketplace.
5. Cross-border information sharing with CERT-In coordinating with international counterparts on multinational incidents.

The cyber insurance market in India will continue to evolve in response. Insurers are tightening underwriting on entities without strong incident response capability, expanding panel firm coverage for India incidents, and refining policy language for CERT-In and DPDP compatibility. Brokers and insureds that invest in the operational capability will navigate the environment effectively; those that treat compliance as a checklist will find friction at incident time that affects both regulatory standing and insurance recovery.