CERT-In's 6-hour incident reporting rule: what businesses need in place

This article is general information to help you prepare. It is not legal advice. For decisions about your organisation’s obligations, consult a qualified legal adviser and the official CERT-In documents linked below.

What the Directions are

The Indian Computer Emergency Response Team (CERT-In) is the national agency for responding to cyber security incidents. As the Directions themselves set out, under sub-section (6) of section 70B of the Information Technology Act, 2000, it can call for information and issue directions to service providers, intermediaries, data centres, body corporate and others.

On 28 April 2022 CERT-In used that power to issue the Cyber Security Directions No. 20(3)/2022-CERT-In on information security practices and the reporting of cyber incidents. The Directions took effect 60 days after issue. A further order of 27 June 2022 moved the effective date to 25 September 2022 for micro, small and medium enterprises, and for two subscriber-validation items applying to data centres, VPS, cloud and VPN providers.

In May 2022 CERT-In published Frequently Asked Questions on the Directions. The FAQs state that they are not a legal document and do not replace or amend the IT Act or the CERT-In Rules, 2013, but they are the clearest official explanation of how the Directions are meant to work. All of these documents are listed on CERT-In’s Directions page.

Who the Directions apply to

The Directions address service providers, intermediaries, data centres, body corporate and Government organisations. Some provisions apply only to specific groups, such as VPS, cloud and VPN service providers, and virtual asset service providers.

The FAQs clarify the reach:

“Body corporate” takes its meaning from section 43A of the IT Act: any company, including a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities (FAQ 25).
Individual citizens are not covered (FAQ 7).
Foreign entities: the FAQs say the Directions apply to any entity in the matter of cyber incidents and cyber security incidents (FAQ 26), and that providers offering services to users in India must designate a Point of Contact even without a physical presence here (FAQ 29).

In other words, an ordinary Indian business running a website, app or internal IT systems should assume the incident-reporting, logging and clock-synchronisation requirements apply to it.

The six main requirements

The Directions contain six numbered requirements. The first four apply broadly; the last two are sector-specific.

#	Requirement	Applies to
(i)	Synchronise all ICT system clocks with NTP servers of NIC or NPL, or sources traceable to them	All covered entities
(ii)	Report incidents of the listed types to CERT-In within 6 hours of noticing them or being told of them	All covered entities
(iii)	Provide information or assistance when CERT-In directs, and designate a Point of Contact	All covered entities
(iv)	Enable logs of all ICT systems and keep them securely for a rolling 180 days within Indian jurisdiction	All covered entities
(v)	Register and keep specified subscriber details for 5 years	Data centres, VPS, cloud and VPN service providers
(vi)	Keep KYC and transaction records for 5 years	Virtual asset service providers, exchanges and custodian wallet providers

Reporting within 6 hours

The clock starts when you notice an incident or are made aware of it. Reports can be sent to CERT-In by email (incident@cert-in.org.in), phone (1800-11-4949) or fax (1800-11-6969), and the reporting formats are published on the CERT-In website.

The FAQs add practical detail:

If you do not have every detail required by the incident reporting form within six hours, report what you have and send the rest later within a reasonable time (FAQ 30).
When several parties are affected, for example a business and its outsourced hosting provider, any entity that notices the incident must report it. The FAQs say the obligation cannot be transferred or indemnified away by contract (FAQ 13).
The statutory duty to report overrides confidentiality clauses in contracts, by virtue of section 81 of the IT Act (FAQ 22).
Reporting a vulnerability on its own, unconnected with an incident, is not currently mandatory (FAQ 15).

Reportable incident types

Annexure I of the Directions lists twenty categories. In summary, they are:

Targeted scanning or probing of critical networks or systems
Compromise of critical systems or information
Unauthorised access to IT systems or data
Website defacement, or intrusion and unauthorised changes such as inserting malicious code or links
Malicious code: viruses, worms, Trojans, bots, spyware, ransomware, cryptominers
Attacks on servers such as database, mail and DNS, and on network devices such as routers
Identity theft, spoofing and phishing
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 and e-commerce
Data breach
Data leak
Attacks on IoT devices and associated systems
Attacks or incidents affecting digital payment systems
Attacks through malicious mobile apps
Fake mobile apps
Unauthorised access to social media accounts
Attacks or suspicious activity affecting cloud systems
Attacks or suspicious activity affecting big data, blockchain, virtual assets, robotics, 3D/4D printing, additive manufacturing and drones
Attacks or suspicious activity affecting AI and machine learning systems

The FAQs include an annexure explaining each category. FAQ 30 also highlights incidents that should be reported within the six hours: severe incidents (such as DoS, DDoS, intrusion or ransomware) on public information infrastructure, data breaches or leaks, large-scale or frequent intrusions into computer resources and websites, and incidents affecting human safety.

Logs for 180 days

All ICT systems must have logging enabled, with logs kept securely for a rolling 180 days and provided to CERT-In with an incident report or on request. The FAQs give useful clarifications:

Examples of relevant logs include firewall, intrusion prevention, SIEM, web, database, mail, FTP, proxy, application, SSH and VPN logs, and event logs of critical systems. Both successful and unsuccessful events should be recorded (FAQ 37).
On location, FAQ 35 says logs may also be stored outside India, provided they can be produced to CERT-In within a reasonable time, while FAQ 36 says service providers offering services to users in India need to maintain logs and records of financial transactions in Indian jurisdiction. Because these two answers need reading together, this is a point to settle with your legal adviser.
Requests for logs come from a CERT-In officer not below the rank of Deputy Secretary to the Government of India (FAQ 38).

Clock synchronisation

Accurate, consistent timestamps let investigators reconstruct what happened across many systems. The Directions require synchronising clocks with NTP servers of the National Informatics Centre (NIC) or National Physical Laboratory (NPL), or with sources traceable to them. Entities spanning several geographies may use another accurate standard time source, provided it does not deviate from NIC and NPL.

According to the FAQs:

Clocks do not have to be set to IST; NTP provides UTC, and the time zone should be recorded alongside the time (FAQ 40).
Workloads in the cloud may continue to use the cloud provider’s native time service (FAQ 42).
The NTP servers listed in the FAQs are samay1.nic.in and samay2.nic.in for NIC, and time.nplindia.org for NPL (FAQ 43).

Point of Contact

Every covered entity must designate a Point of Contact to interface with CERT-In and send the details in the format given in Annexure II of the Directions (name, designation, organisation, office address, email, mobile, office phone and fax) to info@cert-in.org.in, keeping them up to date. CERT-In sends its information requests and directions to this person.

Consequences of non-compliance

Section 70B(7) of the IT Act, quoted in the FAQs, provides for imprisonment of up to one year, a fine of up to one lakh rupees, or both, for failing to provide information or comply with directions. FAQ 23 states that this power will be exercised reasonably, on occasions when non-compliance is deliberate.

A practical readiness checklist

Six hours is short, especially if an incident is noticed late on a Friday. Preparation is what makes the deadline achievable.

People and process

Designate a Point of Contact and a deputy, and send the Annexure II details to CERT-In.
Write a one-page incident procedure: who decides whether an event is reportable, who submits the report, and who informs management.
Map the Annexure I categories to the kinds of alerts your systems actually produce.
Keep CERT-In’s current reporting form and contact details where the on-call person can find them.
Agree with hosting, cloud, SaaS and development vendors how they will tell you about incidents promptly, remembering each party that notices an incident has its own duty to report.
Run a short tabletop exercise at least once a year using a realistic scenario.

Logging

List every ICT system in scope, including cloud services, firewalls, VPNs, servers, databases, applications and email.
Confirm logging is enabled on each, capturing both successful and failed events.
Set retention to at least 180 days and protect logs from tampering or deletion.
Decide, with legal advice, where logs are stored, and confirm you can retrieve and export them quickly.

Time

Point internal NTP servers, network devices and servers at NIC, NPL or a traceable source, or confirm the cloud provider’s time service is in use.
Make sure logs record the time zone.
Monitor for clock drift.

Detection

Make sure alerts for the most likely incidents (unauthorised access, malware, website changes, DDoS, data exposure) reach someone who can act on them at any hour.
Record when each incident was first noticed; that timestamp starts the six-hour window.

Related obligations

Check whether sector regulators or other laws impose their own reporting duties and timelines for the same incident, so that one event triggers all the notifications it needs.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.