CERT-In 6-Hour Incident Reporting: Complete Process, Timeline, Reporting Format & Checklist 2026

The most challenging aspect of CERT-In's incident reporting requirement is that organisations are expected to act before investigations are complete. Security teams often have only a few hours to determine whether an incident is reportable, gather key facts, coordinate stakeholders, and notify CERT-In. In this guide, we explain the CERT-In 6-hour reporting requirement, reporting process, timeline, format, checklist, and common compliance mistakes. 

Key Takeaways

• CERT-In's 6-hour reporting timeline starts when an incident is noticed, not when the investigation is complete: Organisations should assess reporting obligations as soon as a reportable cybersecurity incident is identified or brought to their attention.
• Reportability is determined by the incident category, not the size of the impact: Ransomware attacks, phishing incidents, unauthorised access, data breaches, DDoS attacks, website defacements, and other incidents identified by CERT-In may require reporting regardless of the affected environment's scale.
• Successful compliance depends on preparation before an incident occurs: Organisations should maintain predefined escalation paths, reportability criteria, reporting templates, and designated points of contact to avoid losing valuable time during the six-hour reporting window.
• The initial report is only the beginning of the reporting process: Organisations can submit an initial notification based on available information, continue their investigation, preserve evidence, retain required logs, and provide follow-up information as new findings emerge.
• CERT-In reporting does not replace other regulatory obligations: A single cyber incident may require both CERT-In reporting and separate assessments under the DPDP framework if personal data is affected. Organisations should also review the DPDPA Compliance Checklist to understand the key compliance obligations following a personal data breach.

What Is CERT-In 6-Hour Incident Reporting?

CERT-In's 6-hour incident reporting requirement obligates organisations covered under the CERT-In Directions to report specified cybersecurity incidents to the Indian Computer Emergency Response Team (CERT-In) within six hours of noticing the incident or being informed about it. The requirement is issued under Section 70B(6) of the Information Technology Act, 2000, and the CERT-In Directions dated 28 April 2022, which came into effect on 27 June 2022.

A key aspect of the requirement is that the reporting timeline begins when an organisation becomes aware of a reportable incident or receives information about it. Organisations are expected to submit an initial report within the prescribed timeframe and provide additional information to CERT-In as further details become available during the investigation.

Who Must Comply With the CERT-In 6-Hour Reporting Rule?

The CERT-In reporting requirement applies to organisations and entities covered under the CERT-In Directions. If a covered entity experiences a reportable cybersecurity incident, it must notify CERT-In within the prescribed reporting timeline.

Entities in Scope Under the CERT-In Directions

The CERT-In Directions apply to a broad range of organisations that provide digital services, operate technology infrastructure, or process information systems in India. Covered entities include:

• Service providers
• Intermediaries
• Data centres
• Body corporates
• Government organisations

Additional Record-Keeping Requirements for VPS, Cloud, and VPN Providers

The CERT-In Directions impose additional record-retention requirements on certain service providers. Virtual Private Server (VPS) providers, cloud service providers, Virtual Private Network (VPN) service providers, and virtual asset service providers must maintain specified subscriber and customer information for a minimum period of five years after the cancellation or withdrawal of registration, as required under the Directions.

Is Any Organisation Exempt From the Reporting Requirement?

The CERT-In Directions do not provide a blanket exemption for organisations that fall within the covered categories. Any entity subject to the Directions that experiences a reportable cybersecurity incident must assess its reporting obligations and comply with applicable requirements.

When Does the 6-Hour Clock Start?

The six-hour reporting window starts when a reportable cybersecurity incident comes to an organisation's attention. The deadline is based on awareness of the incident, not on the date the attack occurred or the completion of an investigation.

What Counts as "Awareness" of an Incident?

An organisation may become aware of a reportable incident through multiple channels. Common examples include a validated SIEM alert, suspicious activity reported by an employee who has received security awareness training, a customer notification, or information received from a trusted third party. Once a reportable incident is identified or brought to the organisation's attention, the reporting timeline begins.

Why Doesn't CERT-In Wait for a Complete Investigation?

CERT-In requires timely notification of reportable cybersecurity incidents, even when investigations are still in progress. Organisations can submit an initial report based on the information available at the time and provide additional technical findings, impact details, or forensic evidence as the investigation continues.

Example of When the Reporting Clock Starts

Assume an attacker gains unauthorised access to a system on Monday, but the activity remains undetected. On Thursday, the organisation identifies suspicious activity and determines that a reportable cybersecurity incident may have occurred. In this scenario, the six-hour reporting timeline begins on Thursday when the incident is discovered, not on Monday when the compromise originally took place.

Which Cyber Incidents Must Be Reported to CERT-In?

Organisations must report cybersecurity incidents that fall within the categories specified by CERT-In. The reporting obligation is determined by the type of incident rather than the size of the affected environment, financial impact, or completion of an internal investigation.

Learn more about the different types of cyber attacks that may trigger CERT-In reporting obligations.

The Reportable Cyber Incident Categories

CERT-In requires reporting of several categories of cybersecurity incidents, including:

• Unauthorised access to information systems or data
• Website defacement or unauthorised changes to websites
• Malicious code attacks, including malware and ransomware
• Identity theft, spoofing, and phishing attacks
• Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks
• Attacks targeting servers, applications, databases, or network devices
• Data breaches and unauthorised disclosure of information
• Targeted scanning or probing of systems and networks
• Attacks affecting critical systems and digital services
• Other reportable cybersecurity incidents identified in the CERT-In Directions

For example, a ransomware infection that disrupts business operations, a phishing campaign that compromises user credentials, or unauthorised access to a corporate application may fall within reportable incident categories. Organisations should assess incidents against the categories defined by CERT-In rather than relying solely on the perceived severity of the event.

What Is Not Automatically Reportable?

Discovering a vulnerability, software misconfiguration, or security weakness during a Vulnerability Assessment and Penetration Test (VAPT) does not automatically trigger a reporting obligation. For example, identifying an unpatched server during a vulnerability assessment is different from discovering evidence that the vulnerability has been exploited. The reporting requirement applies when a cybersecurity incident falls within a reportable category specified by CERT-In.

Rule of Thumb: If the Incident Matches a Reportable Category, Assess It for Reporting

Organisations should not delay assessment simply because the full scope or impact of an incident is still being investigated. If an incident appears to fall within a reportable category identified by CERT-In, it should be promptly evaluated for reporting while technical and forensic investigations continue.

For many organisations, meeting the six-hour reporting timeline depends on having the right operational processes in place before an incident occurs. Continuous monitoring, rapid incident triage, clear escalation paths, and experienced security analysts can help teams identify potential reportable incidents and accelerate response activities. Providers such as Eventus Security support organisations through managed SOC operations, threat detection, incident response, and compliance-focused security monitoring that can help strengthen reporting readiness. 

Learn how SOC monitoring supports DPDPA compliance while improving incident detection and regulatory readiness.

What Is the CERT-In Incident Reporting Process?

The CERT-In reporting process is designed to help organisations move from incident identification to regulatory notification within six hours while continuing investigation and response activities. Although the exact workflow may vary between organisations, most reporting processes follow the same core sequence.

The process generally involves the following activities:

• Identify and Escalate the Incident: Ensure suspected cybersecurity incidents are promptly escalated to the appropriate security, IT, compliance, or incident-response stakeholders.
• Determine Whether the Incident Is Reportable: Assess the incident against CERT-In's reportable incident categories and document the basis for the reporting decision.
• Collect the Required Incident Information: Compile the key facts available at the time, including incident type, detection timeline, affected assets, current impact, actions taken, and designated points of contact.
• Submit the Initial Notification to CERT-In: Report the incident through an approved reporting channel within six hours of noticing the incident or being informed about it.
• Preserve Evidence and Continue Follow-Up Activities: Retain relevant logs, alerts, and forensic artefacts, continue the investigation, and provide additional information to CERT-In as new findings emerge.

Organisations should also be aware that the CERT-In Directions contain additional compliance requirements beyond incident reporting. These include retaining ICT system logs for a rolling period of 180 days within the Indian jurisdiction and maintaining accurate time synchronisation across ICT systems using approved reference time sources. These records can play an important role in supporting investigations and incident-response activities. 

What Does the CERT-In 6-Hour Reporting Timeline Look Like, Hour by Hour?

The six-hour reporting window leaves little room for delays, especially in organisations that require technical validation, management notifications, and compliance reviews. A predefined timeline helps teams coordinate reporting activities while continuing incident response efforts.

Hour 0–1: Detection and Initial Assessment

Security teams identify the incident, validate that the alert or report is credible, and initiate the organisation's escalation process. Early evidence should be preserved, and key stakeholders should be notified according to the incident response plan.

Hour 1–3: Classification and Reporting Assessment

The incident is reviewed against the reportable categories defined by CERT-In. During this stage, teams gather the initial facts needed to understand what happened, which systems may be affected, and whether reporting obligations are likely to apply.

Hour 3–5: Report Preparation and Internal Review

The reporting team compiles the available incident details and prepares the initial notification. Where required, legal, compliance, data protection, or leadership stakeholders may review the submission before it is sent.

Hour 5–6: Report Submission and Evidence Preservation

The initial report is submitted to CERT-In within the prescribed timeline. Organisations should then continue preserving logs, alerts, forensic artefacts, and investigation records while gathering additional information that may be shared through follow-up communications.

What Is the CERT-In Incident Reporting Format?

Organisations must provide sufficient information for CERT-In to understand the nature of the incident, the affected environment, and the actions taken so far. Having a standard reporting format helps reduce delays during an active incident.

What Information Should Be Included?

A typical CERT-In incident report should include:

• Organisation and contact details
• Incident category
• Date and time of detection
• Description of the incident
• Affected systems or assets
• Actions taken and current status

The Format in Plain English

Most CERT-In reports ultimately answer five questions:

• Who is reporting the incident?
• When was the incident detected?
• What happened?
• What systems, services, or data were affected?
• What actions have been taken so far?

Sample Initial Incident Report Structure

How Do You Submit a Report to CERT-In?

Organisations can report cybersecurity incidents to CERT-In through multiple channels, including email, telephone, the incident reporting portal, and fax. The reporting method should allow the organisation to notify CERT-In promptly while maintaining records of the submission.

Reporting Channels

CERT-In provides the following reporting channels:

• Email: [email protected]
• Helpline: 1800-11-4949
• Incident Reporting Portal
• Fax (as listed by CERT-In)

What Happens If You Miss the 6-Hour Deadline?

Failure to comply with the CERT-In Directions may attract penalties under Section 70B(7) of the Information Technology Act, 2000. The provision states that a person who fails to provide information, comply with directions, or furnish assistance required by CERT-In may be punished with imprisonment for a term that may extend to one year, a fine that may extend to ₹1 lakh, or both.

Beyond regulatory penalties, delayed reporting can affect an organisation's ability to demonstrate compliance, support investigations, and coordinate incident response activities with relevant authorities. Organisations should therefore establish clear reporting procedures, escalation paths, and decision-making processes to help meet the prescribed reporting timeline.

How Is CERT-In Reporting Different From DPDP Breach Notification?

CERT-In incident reporting and DPDP breach notification are separate compliance obligations. Although a single incident may trigger both requirements, the two frameworks focus on different risks and reporting objectives.

The key differences are outlined below:

• CERT-In focuses on reportable cybersecurity incidents.
• DPDP focuses on personal data breaches and their impact on affected individuals.
• CERT-In reporting does not automatically satisfy DPDP obligations, and vice versa.
• A single incident may trigger both requirements. For example, a ransomware attack affecting customer data may require both cybersecurity and personal-data assessments.
• Organisations should assess personal-data exposure in parallel with CERT-In reporting rather than waiting for the incident investigation to conclude.

What Is the Complete CERT-In 6-Hour Reporting Checklist?

Organisations can improve CERT-In reporting readiness by establishing clear processes before an incident occurs, following a structured reporting workflow during an incident, and documenting lessons learned after the event. The checklist below summarises the key activities across each stage.

What Are the Most Common CERT-In Reporting Mistakes?

Organisations frequently struggle with the six-hour reporting requirement because key decisions, responsibilities, and reporting workflows have not been defined before an incident occurs. The following mistakes are among the most common causes of delayed reporting and compliance gaps:

• Waiting for root-cause confirmation before initiating reporting activities. CERT-In's reporting timeline starts when a reportable incident is noticed or brought to the organisation's attention, not when the investigation is complete or the root cause has been confirmed.
• Treating a suspected incident as a routine security alert for too long. Valuable reporting time can be lost while teams continue validating alerts or assessing impact instead of escalating the event for a reporting determination.
• Not defining who is authorised to make the reportability decision. Delays often occur when SOC teams, IT teams, compliance teams, and management are unsure who is responsible for determining whether an incident falls within a reportable category.
• Preparing incident reports from scratch during an active incident. Searching for contact details, collecting stakeholder information, and compiling report content under time pressure can consume a significant portion of the six-hour window.
• Failing to preserve logs and forensic evidence before containment actions. Rebuilding systems, disabling accounts, or isolating affected assets without collecting relevant evidence can make it difficult to reconstruct the incident and support follow-up investigations.

Strengthening Incident Reporting Readiness with Eventus Security

Timely incident reporting depends on an organisation's ability to quickly identify, investigate, and escalate potential cybersecurity incidents. Delays often occur when security teams lack visibility into emerging threats, established escalation workflows, or the resources needed to analyse incidents as they unfold.

How Eventus Security Supports Incident Readiness:

• 24/7 Security Monitoring: Continuous monitoring helps organisations detect suspicious activity and security incidents across their environments.
• Threat Detection and Investigation: Security analysts investigate alerts, validate potential cyber threats, and help organisations understand the nature of security events.
• Incident Response Support: Eventus Security assists organisations in analysing, containing, and responding to cybersecurity incidents.
• Managed SOC Operations: Centralised monitoring, alert triage, and incident management processes can help improve operational readiness during security events.
• Security Visibility Across Environments: Integrated monitoring and threat detection capabilities help organisations maintain visibility into on-premises, cloud, and hybrid environments.

Speak with the Eventus Security team to learn how 24/7 SOC monitoring, threat detection, and incident response services can help strengthen your organisation's cyber resilience and incident-readiness capabilities.

FAQs

1. When does the CERT-In 6-hour reporting clock start? 

The six-hour reporting timeline begins when a reportable cybersecurity incident is noticed or brought to the organisation's attention. Organisations should not wait for full investigation results, root-cause confirmation, or impact assessments before evaluating reporting obligations.

2. Do organisations need complete forensic evidence before reporting to CERT-In? 

No. CERT-In reporting should not be delayed while forensic investigations are ongoing. Organisations can submit an initial report based on the information available at the time and provide additional details as the investigation progresses.

3. What logs must be retained under the CERT-In Directions? 

The CERT-In Directions require covered entities to enable and retain logs of ICT systems for a rolling period of 180 days within the Indian jurisdiction. Depending on the environment, this may include system, application, security, network, cloud, and authentication logs.

4. Does the CERT-In reporting requirement apply to startups and small businesses? 

The reporting requirement is based on whether an organisation falls within the scope of the CERT-In Directions and experiences a reportable cybersecurity incident. There is no general exemption solely because an organisation is a startup or a small business.

5. How should managed service providers handle reporting in multi-tenant environments? 

Managed service providers should establish clear processes for identifying, escalating, and assessing incidents that affect customer environments. Reporting responsibilities may vary depending on contractual arrangements, service models, and the nature of the incident, so organisations should define reporting roles and obligations in advance.