CERT-In's 6-hour incident reporting rule: what to do on day one

By Akash Sengar · 6 October 2026 · 6 min read

What the directions say

On 28 April 2022, the Indian Computer Emergency Response Team (CERT-In) issued directions under section 70B(6) of the Information Technology Act, 2000 on information security practices and the reporting of cyber incidents. They took effect 60 days after issue. CERT-In also published FAQs on the directions, which answer most of the practical questions people ask.

Four requirements matter most for a typical business:

• Report within six hours. Incidents of the listed types must be reported to CERT-In within six hours of noticing them or being told about them.
• Keep logs for 180 days in India. Logs of all ICT systems must be enabled and kept securely for a rolling 180 days within Indian jurisdiction, and provided to CERT-In when asked.
• Synchronise clocks. System clocks must be synchronised to the Network Time Protocol (NTP) servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or to NTP servers traceable to them.
• Name a point of contact. Each organisation must designate a point of contact to interface with CERT-In and share the details.

The directions also set obligations for data centres, VPN, cloud and VPS providers and virtual asset service providers. This guide focuses on what applies to an ordinary business.

Who must report

The directions apply to service providers, intermediaries, data centres, body corporates and government organisations. In practice, a company registered in India that runs IT systems is a body corporate and is in scope. If your business is small, the size of the organisation does not change the obligation.

If you use managed service providers, cloud platforms or outsourced IT, agree in writing who notices, who decides and who files the report. The duty sits with your organisation even when a supplier runs the system.

Which incidents count

Annexure I of the directions lists the incident types that must be reported. In summary, they are:

• Targeted scanning or probing of critical networks and systems
• Compromise of critical systems or information, and unauthorised access to IT systems or data
• Defacement of, or intrusion into, a website, and unauthorised changes such as inserting malicious code or links to external websites
• Malicious code attacks, including viruses, worms, Trojans, bots, spyware, ransomware and cryptominers
• Attacks on servers (such as database, mail and DNS) and network devices (such as routers)
• Identity theft, spoofing and phishing attacks
• Denial-of-service and distributed denial-of-service attacks
• Attacks on critical infrastructure, SCADA and operational technology systems, and wireless networks
• Attacks on applications such as e-governance, e-commerce and others
• Data breaches and data leaks
• Attacks on Internet of Things devices and associated systems, networks, software and servers
• Attacks or incidents affecting digital payment systems
• Attacks through malicious mobile apps, and fake mobile apps
• Unauthorised access to social media accounts
• Attacks or malicious or suspicious activity affecting cloud systems, servers, software or applications
• Attacks or suspicious activity affecting systems related to big data, blockchain, virtual assets, virtual asset exchanges, custodian wallets, robotics, 3D and 4D printing, additive manufacturing and drones
• Attacks or suspicious activity affecting systems related to artificial intelligence and machine learning

The list is broad. A phishing email that leads to a compromised mailbox, a ransomware infection on one laptop, or unauthorised access to your company's social media account all fall inside it. When in doubt, read the exact wording in the directions and report.

How to report

CERT-In's website gives the reporting formats and contact details, including the email address incident@cert-in.org.in. Check the website for the current form and channels before you need them, and save them in your incident plan.

You will not know everything in the first six hours. CERT-In's FAQs say an organisation can report with the information available at the time and send further details later. A useful first report says:

1. Who you are, and the name and contact details of your point of contact
2. What happened, in plain words, and which incident type it appears to be
3. When it was noticed, and when it is believed to have started, with time zone
4. Which systems, accounts or data are affected, as far as you know
5. What you have done so far (for example, isolated a device or reset credentials)

Keep a copy of what you sent and when. If personal data is involved, the Digital Personal Data Protection Act, 2023 and its Rules set a separate breach-intimation duty to the Data Protection Board and to affected people. Reporting to CERT-In does not replace it. For fraud involving money, the national cybercrime helpline is 1930.

180-day logs

The logging requirement is where most small organisations find gaps. "Logs of all ICT systems" covers more than servers. Think about firewall and VPN logs, Microsoft 365 or Google Workspace sign-in and audit logs, endpoint protection consoles, DNS and web server logs, and cloud platform logs.

• List each log source and where its logs are stored today.
• Check its default retention. Many SaaS consoles keep some logs for less than 180 days unless you change a setting, buy a higher plan or export them.
• Where retention is short, export logs to storage you control, located in India, with access limited to a few named people.
• Protect logs from tampering: separate admin accounts, write-once or versioned storage where possible, and alerts on deletion.

Clock synchronisation

Reports and logs are only useful if their timestamps agree. Point your domain controllers, firewalls, servers and network devices at the NTP servers of NIC or NPL, or at servers traceable to them. The directions allow organisations whose infrastructure spans several countries to use another accurate standard time source, as long as it does not deviate from NPL and NIC. Most laptops take their time from the domain or from the operating system's defaults; check that those chains are correct.

First-day checklist

Print this, or keep it where people can find it without the systems that may be affected.

1. Write down the time you noticed the incident. The six-hour clock starts now.
2. Call your incident lead and your point of contact for CERT-In.
3. Contain without destroying evidence: disconnect affected devices from the network rather than wiping or switching them off where you can.
4. Reset passwords and revoke sessions for affected accounts, from a clean device.
5. Preserve logs now: export the relevant firewall, sign-in, mail and endpoint logs before they roll over.
6. Decide whether the incident is one of the listed types. If yes, or if unsure, prepare the report.
7. File the initial report to CERT-In within six hours, with what you know. Save a copy.
8. Check whether personal data is involved and start the DPDP assessment in parallel.
9. Keep a timeline of every action, who took it and when.
10. Brief leadership, and agree who speaks to clients, staff and the press.

Our first-hour incident checklist covers containment in more detail.

Prepare before you need it

Six hours is not long when the person who knows the systems is travelling. A short preparation exercise makes it realistic:

• Designate the point of contact and a deputy, and share the details with CERT-In as the directions require.
• Write a one-page incident plan: who decides, who reports, who contains, and how to reach each other if email is down.
• Fix log retention and clock synchronisation now, so the evidence exists when you need it.
• Keep a report template filled in with your organisation's details.
• Run a tabletop exercise once a year: walk through a phishing or ransomware scenario against the clock.

None of this needs expensive tools. It needs decisions made in advance, written down, and tested once.

This guide is general guidance, not legal advice.