Cyber breach rules: what Indian startups must report and when

CERT-In is the Indian Computer Emergency Response Team. It sits under the Ministry of Electronics and Information Technology (MeitY) and is the national agency for cyber incidents. Its powers come from section 70B of the Information Technology Act, 2000. When a company is hacked, CERT-In is the body that expects to hear about it, collect technical details and help contain the damage.

For a startup the rules matter because the duty is not limited to big banks. As of November 2026, the directions apply to service providers, intermediaries, data centres, body corporates and government organisations, which in plain terms means almost any company that runs software or holds user data. A crypto exchange, a lending app and a food delivery platform all fall inside that wide net.

A live case is Unocoin, an Indian crypto exchange that halted its services after finding unauthorised access to its systems in November 2026, and said it was rebuilding its servers.

CERT-In issued a set of directions on 28 April 2022 under section 70B(6) of the IT Act. They took effect on 27 June 2022, about two months later. They remain the main reference as of November 2026, though anyone relying on them should check the current text, since agencies can amend directions.

The directions ask covered entities to do a handful of concrete things.

• Report listed cyber incidents to CERT-In within six hours of noticing them or being told about them.
• Keep logs of their information and communication technology systems for a rolling period of 180 days, stored within India's jurisdiction.
• Hand over those logs to CERT-In along with an incident report, or whenever CERT-In asks for them.
• Sync system clocks to the time servers of the National Informatics Centre or the National Physical Laboratory, so logs from different firms line up.
• Name a point of contact for CERT-In, who can be reached for follow-up.
• Virtual asset service providers, such as crypto exchanges and wallet providers, must also keep customer know-your-customer records and transaction records for five years.

The directions come with an annexure listing the kinds of incident that must be reported. Commentators count about twenty types, up from the eleven in the older CERT-In rules. The list is about the type of event, not the size of the loss, so a small company can still be covered.

Typical examples on the list include targeted scanning or probing of systems, compromise of critical systems, unauthorised access to a system or to data, website defacement, malicious code attacks such as ransomware, attacks on servers and applications, identity theft and spoofing, data breaches and data leaks, and attacks on cloud computing and mobile apps. Attacks on digital payment systems and on artificial intelligence systems also appear on the list.

The clock starts when the company notices the incident or is told about it, not when the attack began. That matters because attackers often sit inside systems for days. A firm that finds a breach on a Monday morning has until that afternoon to send a first report, even if it does not yet know what was taken.

Reports go to CERT-In through its email address, phone line or online form, with whatever facts are known. Many law firms read the six-hour window as a time to give a first alert, with fuller detail to follow once the team learns more. Companies usually keep an incident response plan so that someone knows who files the report and what it contains.

The rule has drawn criticism from industry for being tight, and some firms have asked for longer windows or exemptions. Even so, as of November 2026 the six-hour figure is the one in force.

The Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 add a second duty. The Rules were notified on 13 November 2025 and come into force in phases over about 18 months, so most duties bite from around May 2027. Once in force, a company that holds personal data, called a data fiduciary, must tell the Data Protection Board of India and each affected person when a personal data breach happens.

Commentators describe a two-step process: an intimation to the Board without delay, then a fuller report that explains what happened, why, and what was done. Reports commonly put the detailed report at 72 hours, with the Board able to extend that on request. Unlike the European law, the Indian text has no risk threshold, so any personal data breach is within scope. Check the final Rules for the exact timings.

The two regimes are separate. A leak of customer names and phone numbers could trigger a CERT-In report within six hours and, once the DPDP Rules apply, a notice to the Board and users as well.

CERT-In can seek information and issue directions, and non-compliance with its directions can be punished with imprisonment of up to one year, a fine or both, under section 70B(7) of the IT Act. Beyond the formal penalty, regulators and customers judge a company by how fast and how openly it responds.

The DPDP Act has its own penalty scale. It allows the Board to impose monetary penalties that run to hundreds of crores of rupees for failing to take reasonable security safeguards or to notify a breach. Amounts depend on the nature of the breach, so a company should read the schedule to the Act rather than rely on a headline figure.

Most of the work is preparation. A short list of habits makes a six-hour deadline possible rather than painful.

• Write an incident response plan that names who decides, who files with CERT-In and who speaks to customers.
• Turn on logging for servers, applications, databases and cloud accounts, and store the logs for at least 180 days inside India.
• Map where personal data sits, so that after a breach the team can say whose data was touched.
• Keep the CERT-In contact details and reporting form where on-call engineers can find them at night.
• Run a drill once a year so the first real report is not the first attempt.
• Ask vendors and cloud providers to promise fast notice if they are hit, since their incident can become the startup's incident.

CERT-In is not the only body that wants to hear about an incident. Banks, payment firms and other regulated entities have their own reporting lines. The Reserve Bank of India sets cyber incident reporting duties for banks, payment system operators and some non-bank lenders, and the securities regulator SEBI does the same for stock brokers, exchanges and similar firms. A fintech may therefore need to send reports to CERT-In and to its sector regulator, each with its own format and deadline.

This layering is a common source of confusion. A startup should list every regulator that supervises it, note each deadline in its incident plan, and assign one person to track them all. Law firms generally advise reading the six-hour CERT-In rule as the floor, since a sector rule may be tighter.

When a startup says it has suspended services after unauthorised access, a few questions help. Did the company say it informed CERT-In? Was customer money or personal data involved, or only internal systems? Is the firm rebuilding from scratch or just resetting passwords? How long does it expect to be offline?

A short outage with a clean rebuild is a very different story from a leak of identity documents. Statements about 'no evidence of data loss' early on often change as forensic work finishes. This is general information, not legal advice, so a company facing a real incident should check with a lawyer and a cyber security professional.