19 Oct 2026
A Cyber Incident Can Become a Compliance Issue in Hours
A ransomware attack, data leak, unauthorised system access, or major service disruption can quickly become a business-critical incident. For organisations operating in India, responding to the threat is only one part of the process. Certain cyber incidents must also be reported to the Indian Computer Emergency Response Team (CERT-In) within a defined timeframe.
Under CERT-In’s Directions dated 28 April 2022, specified cyber incidents must be reported within six hours of noticing the incident or being informed about it. The Directions also cover ICT system log retention, time synchronisation, and the designation of a point of contact.
For businesses searching for CERT-In guidelines, the practical challenge is turning these requirements into a process that works outside office hours, across multiple systems, and during a high-pressure security incident.
This guide explains the CERT-In 6-hour rule, what organisations should prepare, how the 180-day log retention requirement works, and how to build a practical CERT-In compliance checklist.
Understand the rules behind cyber incident reporting in India
The Indian Computer Emergency Response Team, commonly known as CERT-In, is India’s national agency for responding to specified cybersecurity incidents and coordinating cybersecurity response activities. The agency issued its Cyber Security Directions on 28 April 2022 under Section 70B(6) of the Information Technology Act, 2000.
The Directions address several operational requirements, including:
The Directions became effective on 27 June 2022. Businesses should read the official CERT-In Directions and the associated FAQs for the precise scope and interpretation of these requirements.
The requirements are relevant to service providers, intermediaries, data centres, body corporates, and government organisations within the scope of the Directions. Companies should assess their specific obligations rather than assuming that only large enterprises or cybersecurity providers are covered.
Start the reporting process as soon as a reportable incident is identified
The CERT-In 6-hour rule requires covered entities to report specified cyber incidents to CERT-In within six hours of noticing them or being informed about them.
The key operational point is that the reporting window is linked to awareness of the incident. An organisation should not wait for a lengthy internal investigation, a final root-cause analysis, or a complete damage assessment before deciding how to meet its reporting obligation.
CERT-In’s official FAQs clarify that organisations can provide the information available at the time of reporting and submit additional information later within a reasonable time.
This means an effective process should prioritise timely initial reporting, followed by evidence gathering and appropriate updates.
Example: A company detects ransomware activity on a business server at 10:00 AM. If the incident falls within the applicable reporting criteria, the organisation should treat 10:00 AM as the start of its response timeline and work to meet the reporting deadline. It should not automatically wait until the forensic investigation is complete.
The precise reportability of an event depends on the Directions and the applicable CERT-In FAQs.
Know the incidents your response team should recognise
Annexure I of the Directions lists categories of cyber incidents. CERT-In’s FAQs provide further clarification on incidents that meet the criteria for reporting within six hours, including incidents of a severe nature, data breaches or data leaks, large-scale or frequently occurring incidents, and incidents affecting human safety.
Examples of relevant incident types in the Directions include:
This is an illustrative overview, not a substitute for the complete list and reporting criteria. Not every security alert automatically meets the same reporting threshold. Security teams should map their incident classification process to Annexure I and the official FAQs.
Action to take: Build an incident classification matrix that identifies the incident types, escalation triggers, decision owner, and reporting steps. Make sure analysts know when to escalate a suspected incident instead of waiting for certainty.
Check the scope across your organisation and service providers
The Directions cover service providers, intermediaries, data centres, body corporates, and government organisations. Their application is not limited to companies that sell cybersecurity products or operate a dedicated Security Operations Centre.
Depending on the organisation and its services, relevant teams may include:
Organisations should also consider incidents affecting data or infrastructure hosted by a third party. CERT-In’s FAQs address incidents affecting data stored in third-party systems, so businesses should not assume that outsourcing hosting or software removes the need to assess their own reporting responsibilities.
Action to take: Document which internal team is accountable for reporting, who can approve submissions, and how incidents involving vendors are escalated.
Prepare a repeatable workflow before an incident happens
A documented process helps security teams act quickly without sacrificing accuracy.
Establish a clear route for employees, monitoring tools, service providers, and security analysts to report suspected incidents.
Record the time the incident was noticed or brought to the organisation’s attention. Preserve relevant alerts and evidence.
Use the CERT-In Directions and official FAQs to assess the incident type and applicable reporting criteria.
If the situation is uncertain, escalate it promptly to the designated security and compliance decision-makers. Avoid allowing a long internal approval chain to delay action.
Collect the information that is reasonably available, such as:
Do not invent details or state unverified assumptions as established facts. Clearly distinguish confirmed information from preliminary findings.
Use the current official CERT-In reporting method and form referenced on its website. The Directions identify email, telephone, and fax as reporting channels, but organisations should verify the current details and instructions before an incident occurs.
Where the incident is reportable, provide the information available at the time rather than waiting for every investigative detail.
Continue collecting logs, analysing the scope, containing the threat, and documenting response decisions.
Where additional information is required, provide appropriate updates to CERT-In in line with its instructions and applicable requirements.
After containment, identify the root cause, fix the exploited weakness, review access controls, and record lessons learned.
Update the incident response playbook based on the incident and any gaps found in reporting, escalation, evidence collection, or decision-making.
Keep the logs you may need to investigate and report an incident
The Directions require covered entities to enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days, with the logs maintained within Indian jurisdiction. The logs must be provided to CERT-In along with incident reporting or when required under an applicable direction.
The practical implications go beyond simply keeping application logs on one server.
Organisations should assess logging coverage across relevant systems, which may include:
The exact logging design will depend on the organisation’s technology environment. The key is to ensure that required logs are enabled, protected from unauthorised alteration or deletion, retained for the required period, and accessible when needed.
Important: Log retention is not the same as keeping a backup of business data. Logs are records of system activity that help reconstruct events, understand access, and support investigations.
Reliable timestamps support a credible incident timeline
The Directions require covered entities to synchronise ICT system clocks with the Network Time Protocol (NTP) servers of the National Informatics Centre (NIC), the National Physical Laboratory (NPL), or servers traceable to these sources. The Directions include a provision for entities with infrastructure spanning multiple geographies to use other accurate and standard time sources, provided their time source does not deviate from the designated government sources.
Accurate timestamps are important when analysts need to correlate events across endpoints, applications, identity systems, firewalls, and cloud platforms.
Without consistent timestamps, a security team may struggle to determine:
Action to take: Verify your time-source configuration, monitor clock drift, and document how synchronisation is managed across systems.
Turn regulatory requirements into verifiable controls
Use this checklist to assess operational readiness. It is a practical starting point, not a legal certification or guarantee of compliance.
Small process gaps can cause major delays during an incident
Teams may delay reporting because they want to confirm every technical detail first. CERT-In’s FAQs explain that available information can be submitted initially and additional information provided later within a reasonable time.
A failed login, a malware alert, and a confirmed data leak may require different investigation and escalation paths. Classify events against the applicable reporting criteria instead of relying on a single generic severity label.
A retention setting is not sufficient if logs are missing, inaccessible, stored in the wrong location, or deleted before the required period ends. Test retrieval and verify the configuration.
If the only reporting owner is unavailable during a weekend or public holiday, a response can be delayed. Assign backups and make the escalation process accessible to the teams that may detect incidents first.
Cloud, hosting, and security providers may support detection and response, but an organisation should define its own responsibilities, escalation paths, and reporting decisions.
Improve monitoring, incident preparedness, and security governance
Meeting CERT-In requirements involves people, processes, and technology. A company may need better visibility into its systems, clearer incident escalation, stronger security monitoring, or a more structured governance programme.
FlyingStars offers cybersecurity services that may support parts of this work:
These services may help strengthen operational readiness depending on your requirements and service scope. They should not be treated as a guarantee of CERT-In compliance or a substitute for an organisation’s own legal and reporting responsibilities.
Planning your incident response process? Review your monitoring coverage, reporting ownership, and log retention controls, then discuss the gaps with the appropriate security and compliance stakeholders.
Conclusion: Prepare Your Process Before the Six-Hour Window Starts
CERT-In incident reporting is most manageable when organisations prepare before an incident occurs. A documented reporting workflow, clear ownership, reliable system logs, accurate timestamps, and tested escalation procedures can help teams act quickly when a reportable incident is identified.
Start by reviewing the official Directions and FAQs, then assess your reporting process and 180-day log retention controls. Assign accountable owners, test the process, and update it when your infrastructure or response arrangements change.
For Indian companies, the goal is not just to understand the CERT-In 6-hour rule. It is to make sure the people, evidence, and procedures needed for a timely response are ready when they are needed.
It is the requirement under the 28 April 2022 Directions to report specified cyber incidents to CERT-In within six hours of noticing them or being informed about them. The applicable incident categories and reporting criteria should be checked against the official Directions and FAQs.
Not every alert automatically qualifies as a reportable incident under the same criteria. CERT-In’s FAQs clarify the types of incidents and criteria relevant to the six-hour requirement. Organisations should classify incidents using the official guidance and escalate uncertainty promptly.
Covered entities must enable ICT system logs and maintain them securely for a rolling period of 180 days within Indian jurisdiction. The logs must be provided to CERT-In along with incident reporting or when required under an applicable direction.
The Directions cover service providers, intermediaries, data centres, body corporates, and government organisations within their scope. Companies should assess how the requirements apply to their activities and systems.
CERT-In’s official FAQs state that entities may provide the information available at the time of reporting and submit additional information later within a reasonable time. The lack of a complete forensic report should not automatically delay an otherwise required initial report.
CERT-In’s FAQs address incidents affecting data stored in third-party systems and explain that the Directions apply to entities in respect of incident reporting. Organisations should establish clear escalation and reporting processes for incidents involving vendors or hosted services.
Consistent timestamps help correlate system activity and reconstruct incident timelines. The Directions specify synchronisation with NIC or NPL NTP sources, or traceable sources, with provisions for certain geographically distributed infrastructures.
Maintain an incident response playbook, assign reporting owners and backups, classify reportable incidents, enable and retain logs, verify time synchronisation, and practise the reporting workflow through tabletop exercises.
