CERT-In 6-Hour Rule: Cyber Incident Readiness Checklist

Quick answer: Under the CERT-In directions issued in 2022, organisations in India must report specified cyber incidents to CERT-In within 6 hours of noticing them, keep system logs for 180 days and sync system clocks using NTP. The checklist below shows what to put in place so your team can meet that timeline.

A cyber incident rarely arrives at a convenient time. It shows up on a Friday evening as a strange login alert, a locked file server or a website that suddenly redirects visitors somewhere else. For organisations in India, what happens in the next few hours is not just a technical matter. It is a legal one.

Since 2022, CERT-In, the national agency for cyber security incident response, has required most organisations to report specified cyber incidents within six hours of noticing them. Many teams know this rule exists. Far fewer have tested whether they can actually meet it. This guide explains what the rule asks for and gives a practical checklist to help your organisation get ready before an incident happens, not during one.

What the CERT-In directions require

On 28 April 2022, CERT-In issued directions under Section 70B(6) of the Information Technology Act, 2000. They came into force in late June 2022 and apply broadly: service providers, intermediaries, data centres, body corporates and government organisations operating in India.

The main obligations are:

• Report within six hours. Specified cyber incidents must be reported to CERT-In within six hours of being noticed or brought to your attention.
• Keep logs for 180 days. Logs of all ICT systems must be enabled and kept securely for a rolling period of 180 days, within Indian jurisdiction.
• Synchronise system clocks. Systems must sync time with the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or with servers traceable to them.
• Name a point of contact. Each organisation must designate a point of contact to coordinate with CERT-In and share the details with the agency.
• Additional records for some providers. Data centres, cloud service providers and VPN providers must keep certain subscriber records for five years.

Non-compliance can attract action under Section 70B(7) of the IT Act, which provides for imprisonment of up to one year, a fine of up to one lakh rupees, or both.

Which incidents need to be reported

The directions list the types of incidents that must be reported. They are wider than many teams expect. The list includes, among others:

• Targeted scanning or probing of critical networks and systems
• Compromise of critical systems or information
• Unauthorised access to IT systems or data
• Defacement of a website, or intrusion into a website with unauthorised changes such as inserting malicious code or links
• Malicious code attacks, including ransomware, viruses and worms
• Attacks on servers such as database, mail and DNS servers, and on network devices such as routers
• Identity theft, spoofing and phishing attacks
• Denial of service (DoS) and distributed denial of service (DDoS) attacks
• Data breaches and data leaks
• Attacks on cloud platforms, IoT devices and applications such as e-governance and e-commerce systems

The practical point is simple. If your team would only escalate a full ransomware outage, you are likely under-reporting. A defaced page on a public website or a confirmed phishing compromise of an official mailbox can also fall within scope.

Why six hours is harder than it sounds

Six hours is enough time to send a report. It is not much time to work out what happened. Most organisations lose those hours in three places.

1. Nobody knows who decides

An alert reaches the IT helpdesk, which forwards it to a vendor, who waits for approval from someone who is in a meeting. By the time a senior person looks at it, half the window is gone. Decision rights need to be written down in advance.

2. The evidence is not there

If firewall, server and application logs are not enabled, or are overwritten after a few days, the team cannot answer basic questions: when did it start, which systems are affected, and is it still going on? This is why the 180-day log requirement matters as much as the reporting deadline.

3. Timestamps do not match

When the firewall, the web server and the database each keep a different time, rebuilding the order of events becomes slow and unreliable. Clock synchronisation sounds minor, but it saves hours during an investigation.

A practical readiness checklist

The following checklist is written for IT heads, department nodal officers and business owners. Each item can be checked off before an incident happens.

Governance and people

• Designate the CERT-In point of contact and a named backup, and confirm the details have been shared with CERT-In.
• Write a one-page escalation matrix: who is informed first, who decides whether an event is reportable, and who submits the report.
• Make sure the decision-maker can be reached outside office hours, including weekends and holidays.
• Add incident reporting duties and timelines to contracts with your IT vendors, hosting providers and AMC partners.

Logging and time

• Enable logging on firewalls, VPNs, servers, domain controllers, email systems, web applications and cloud consoles.
• Store logs for at least 180 days in India, in a place an attacker cannot easily delete them, such as a central log server or SIEM.
• Point all servers and network devices to NIC or NPL NTP servers and check once a quarter that clocks stay in sync.
• Test that you can actually search and export logs quickly. Stored logs that nobody can read in a crisis do not help.

Detection and response

• Keep an up-to-date inventory of servers, applications, domains and public IP addresses. You cannot report what you cannot identify.
• Set alerts for high-risk events such as new admin accounts, repeated failed logins, unusual outbound traffic and changes to website files.
• Prepare a short incident report template with the fields CERT-In asks for, so the first report is a matter of filling in facts.
• Keep offline or immutable backups of critical systems and test a restore at least twice a year.

Practice

• Run a tabletop exercise at least once a year. Pick a realistic scenario, such as a defaced citizen portal or a ransomware alert, and time how long it takes to reach a reporting decision.
• After every real or simulated incident, record what slowed the team down and fix it.

How the DPDP Rules add to this

CERT-In reporting is not the only obligation to plan for. The Digital Personal Data Protection Rules, 2025 were notified on 14 November 2025. Most operational duties for data fiduciaries, including security safeguards and personal data breach reporting, apply after an 18-month transition, which means around May 2027.

Once in force, a personal data breach must be reported to the Data Protection Board and to affected individuals without delay, with a detailed report to the Board within 72 hours. The Rules also expect certain logs to be kept for at least one year. Penalties under the DPDP Act can reach up to ₹250 crore for failing to take reasonable security safeguards.

For most organisations this means one incident may trigger two separate reports on different timelines: CERT-In within six hours, and the Data Protection Board within 72 hours if personal data is involved. It is sensible to build one incident process that covers both, rather than two parallel ones.

Frequently asked questions

Does the six-hour rule apply to small businesses?

The directions apply to body corporates, which includes private companies of all sizes, along with service providers, data centres, intermediaries and government organisations. Smaller organisations are not exempt, although what is expected in practice is proportionate to their systems.

Do we need to know everything before reporting?

No. The first report should contain what is known at that point. Further details can follow as the investigation progresses. Waiting for a complete picture is one of the most common reasons organisations miss the deadline.

How do we report an incident to CERT-In?

CERT-In accepts incident reports by email, phone and through its website, using the formats it publishes. Check the current contact details and reporting format on the official CERT-In website and keep them in your incident plan.

Can our IT vendor report on our behalf?

A vendor can help prepare and submit the report, but the obligation stays with your organisation. Contracts should state who does what and how fast the vendor must inform you.

How Affix Center can help

Meeting the six-hour rule depends on preparation: clear roles, reliable logs, synchronised systems and a team that has practised the process. Affix Center works with government departments and enterprises across India on security assessments, log management, monitoring and incident readiness as part of our cybersecurity and resilience services. For organisations that also need round-the-clock monitoring and support, our IT operations and managed services team can help keep systems watched and documented, and our cloud and infrastructure team can help set up secure, compliant log storage.

Our security monitoring services cover log collection and SIEM, threat detection, and alerting and response.

If you would like a review of how ready your organisation is today, get in touch with our team.

This article is for general information and is not legal advice. Please refer to the official CERT-In directions and the DPDP Rules, 2025 for the full text of each obligation.