areena gLast updated: October 26, 2026
Cybersecurity incidents never unfold on a convenient schedule. They surface when businesses least expect them and can leave teams struggling to respond while their systems, operations, and sensitive information remain at risk.
If CERT-In’s Directions apply to your organisation, the pressure is even greater. The limited time available to assess the incident, assign responsibilities, gather information, and decide the next steps makes the first few hours critical. The CERT-In six-hour reporting window puts you on the clock from the moment an incident comes to notice.
Responding within the six-hour window is not just about technical expertise. It is also about coordination. A defined incident response plan helps SMBs move from uncertainty to coordinated action during the first six hours.
What the CERT-In Directions Require
The six-hour reporting requirement comes from the directions issued by the Indian Computer Emergency Response Team (CERT-In) on 28 April 2022, under sub-section (6) of Section 70B of the Information Technology Act, 2000. The Directions came into force in late June 2022, sixty days from the date of issue.
They apply to service providers, intermediaries, data centres, body corporates, and government organisations. There is no exemption based on the size of the organisation, which means small and medium businesses fall squarely within their scope.
Covered entities must report specified cybersecurity incidents to CERT-In within six hours of noticing them or being brought to notice about them. Failure to comply can invite punitive action under sub-section (7) of Section 70B of the IT Act, apart from consequences under other applicable laws.
Go Beyond CERT-In Compliance with Mitigata
Get expert-led audits, actionable security insights, continuous threat monitoring, and integrated cyber risk protection, all under one roof.
When the Six-Hour Clock Starts
The clock starts when the organisation becomes aware of a reportable incident, whether its own team notices it or a third party brings it to the organisation’s attention. The organisation does not need to complete its investigation before reporting. CERT-In’s official FAQs confirm that entities may report with the information available at the time and share additional details later within a reasonable time.
To meet the deadline, SMBs must record when they first become aware of a cybersecurity incident, escalate it to the designated incident lead, and assess whether it falls within the reporting requirement.
These steps depend on clear responsibilities and a defined process for handling incident alerts. An incident response plan should establish who receives the initial alert, who assesses its significance, and who coordinates reporting. These responsibilities should be agreed before an incident occurs, rather than being decided during a crisis.
What Counts as Reportable
Annexure I of the Directions lists twenty types of cybersecurity incidents that must be mandatorily reported. These cover a wide range of events affecting systems, networks, applications, and data, including:
- Unauthorised access to IT systems or data.
- Data breaches and data leaks.
- Ransomware and other malicious code attacks, such as viruses, worms, trojans, bots, and cryptominers.
- Website defacement and unauthorised changes to websites, such as inserting malicious code or links to external sites.
- Attacks on servers such as database, mail, and DNS servers, and on network devices such as routers.
- Attacks on cloud computing systems, servers, software, and applications.
- Identity theft, spoofing, and phishing attacks.
- Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks.
- Attacks or incidents affecting digital payment systems.
- Attacks through malicious mobile apps and fake mobile apps.
- Unauthorised access to social media accounts.
Small businesses must assess incidents against CERT-In’s specified categories rather than relying only on their internal incident severity levels. An event classified as moderate by an internal team may still require reporting if it falls within a reportable category.
The incident’s full extent may also be unclear when it is first discovered. For instance, suspicious account activity may indicate unauthorised access, but the team may not yet know which systems were affected. The initial assessment should focus on the available evidence and whether the incident meets the reporting criteria.
When information is incomplete, the organisation should not wait for the investigation to finish. It must report the available information within the required timeframe and provide additional details as and when they become available.
The First Six Hours: A Working Playbook
Hour 0 to 1: Contain and Assign
The first hour should establish control over the response. The team needs to identify who leads the incident, who assesses the technical evidence, and who handles reporting and business decisions.
The responsibilities below can be assigned to existing employees in an SMB, even where there is no dedicated security operations team.
| Role | Primary Responsibility |
|---|---|
| IT Manager / Incident Lead | Record the time of awareness, coordinate the response, and assign responsibilities. |
| IT / Security Team | Assess the incident, preserve relevant evidence, and begin containment. |
| Business Owner / Management | Assess business impact and support critical response decisions. |
| Reporting Contact | Assess reporting obligations and coordinate communication with CERT-In. |
| External IT / Security Provider | Supply relevant incident details, logs, and technical support. |
One Partner for CERT-In Compliance & Complete Cyber Protection
From security assessments and compliance expertise to 24/7 threat monitoring and cyber insurance, Mitigata brings it all together.
One person may hold more than one role in a smaller organisation. What matters is that the ownership of every responsibility is clear, and that everyone knows whom to contact when an incident happens.
During the first hour, the team must identify potentially affected systems and accounts, preserve relevant logs, and begin appropriate containment measures. Isolating a compromised endpoint or disabling a compromised account can help limit the damage, provided these actions are coordinated with the response lead and do not destroy evidence.
The team must not make assumptions about the incident’s scope based on the first alert alone. Initial findings, actions taken, and decisions made should be documented as the response progresses.
Hour 1 to 6: Report to CERT-In and Notify Leadership
Once responsibilities are assigned, the incident lead must coordinate the reporting process while technical investigation and containment continue. Reporting should not be left to the final hour. It should begin as soon as the essential facts are in hand.
The reporting contact should gather the information available, including:
- The incident category and a description of what was observed.
- The date and time the incident was noticed or brought to the organisation’s attention.
- The affected systems, applications, accounts, or infrastructure identified so far.
- The known or suspected business and operational impact.
- Relevant technical evidence and indicators available at the time.
- Containment measures taken and the current status of the incident.
The information may be incomplete, especially during the early stages of an attack. The reporting contact should distinguish confirmed facts from preliminary findings and clearly identify details that remain unknown.
CERT-In accepts incident reports through the following official channels:
- The Incident Reporting Form available on the CERT-In website (www.cert-in.org.in).
- Email to incident@cert-in.org.in.
- Phone on 1800-11-4949.
- Fax on 1800-11-6969.
These details, along with the current reporting format published on the CERT-In website, should be recorded in the incident response plan so that the people responsible for reporting can reach them without searching during a crisis.
The Directions also require every covered entity to designate a Point of Contact, share the contact’s details with CERT-In in the format prescribed in Annexure II, and keep those details updated. All communication from CERT-In is routed through this contact, so the role must always have a current owner.
Leadership must receive updates on the incident’s known impact, containment measures, operational risks, and reporting status. This allows management to make informed decisions about business continuity, external assistance, and communication with relevant stakeholders.
The incident lead must also maintain a record of the time from when the incident was identified to the time when the reporting was completed. This builds a timeline that supports subsequent investigation and review.
Log Retention and Evidence
An incident response plan depends on access to reliable evidence. Logs help establish how an attacker gained access, which accounts or systems were involved, what actions occurred, and whether the incident extended beyond the initially affected device.
CERT-In’s Directions require covered entities to enable logs across all their information and communication technology (ICT) systems and maintain them securely for a rolling period of 180 days within Indian jurisdiction. CERT-In’s FAQs also permit storing logs outside India, provided they can be produced to CERT-In within a reasonable time. These logs must be provided to CERT-In along with incident reporting or when directed.
For SMBs, relevant sources may include:
- Identity and access management systems.
- Endpoints, servers, and security tools.
- Firewalls and network infrastructure.
- Email platforms and email security systems.
- Cloud services and business applications.
Log availability should not be assumed. Some systems may retain records for only a limited period, while others may depend on settings managed by a third-party provider. Organisations should understand where their logs are stored, how long they remain available, and who can retrieve them during an incident.
The evidence must be preserved in a way that avoids unnecessary alteration or loss. The incident team should document relevant timestamps, systems examined, actions taken, and the people involved. Consistent timestamps matter here as well. The Directions require covered entities to synchronise their system clocks with the Network Time Protocol (NTP) servers of NIC or NPL, or with servers traceable to them, which also helps investigators reconstruct the sequence of events accurately.
For SMBs using external IT or security providers, the incident response plan should establish how the provider will supply logs and technical information during an incident. Depending on a provider without a clear escalation process can delay the investigation and leave gaps in the reporting process.
Test the Plan Before You Need It
A plan that exists only on paper may leave critical gaps undiscovered until it matters most. SMBs should walk through the plan periodically using a simple tabletop exercise. Simulate a reportable incident, confirm that every role holder knows their responsibility, verify that the CERT-In reporting details and the Point of Contact information are current, and check that the required logs are actually retrievable. Each test will surface small gaps that are far easier to fix in peacetime than during a live incident.
Conclusion
The CERT-In six-hour reporting deadline leaves little room for confusion over responsibilities, missing information, or delayed decisions.
For SMBs, an effective incident response plan is not just about meeting CERT-In’s reporting requirements. It is about knowing who takes charge, what information needs to be gathered, and how the team works together when an incident occurs.
Mitigata helps organisations build CERT-In readiness by organising incident workflows, log retention, reporting evidence, and response ownership. With the right structure in place, your team can move through the first six hours with fewer blind spots and less manual coordination.
Simplify CERT-In Compliance. Strengthen Your Cyber Defences.
Navigate CERT-In requirements with expert assessments, remediation support, and ongoing cyber risk management.
FAQs
What is the CERT-In six-hour reporting requirement?
CERT-In’s Directions of 28 April 2022 require covered entities to report specified cybersecurity incidents within six hours of noticing them or being brought to notice about them. The requirement applies to the incidents listed in Annexure I of the Directions.
Which cybersecurity incidents must be reported to CERT-In?
Annexure I lists twenty categories of reportable incidents. Common examples include unauthorised access, data breaches or leaks, ransomware and other malicious code attacks, website defacement, phishing, denial of service attacks, and incidents affecting digital payment systems.
How can an organisation report an incident to CERT-In?
Incidents can be reported using the Incident Reporting Form on www.cert-in.org.in, by email to incident@cert-in.org.in, by phone on 1800-11-4949, or by fax on 1800-11-6969.
What is the CERT-In 180-day log retention requirement?
Covered organisations must enable logs across all their ICT systems and retain 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 directed.
What should an SMB do if it cannot confirm the full extent of a cybersecurity incident within six hours?
The organisation should report the information available within the required timeframe rather than wait for the investigation to be completed. Additional information can be provided later, within a reasonable time, as it becomes available.
akshit k
Pratyasha