CERT-In Rules: What Indian SaaS Firms Must Do

Quick answer: CERT-In's directions of 28 April 2022 require Indian companies, SaaS firms included, to report listed cyber incidents within 6 hours, keep ICT system logs for a rolling 180 days, synchronise clocks to NIC or NPL time sources, and name a point of contact. There is no "CERT-In certification" for SaaS apps; CERT-In empanels auditors instead. Practical tooling means log management or SIEM (ManageEngine Log360, Wazuh, Elastic, Splunk) plus on-call software (PagerDuty, Squadcast).

How we researched this: We read the CERT-In Directions dated 28 April 2022 and CERT-In's May 2022 FAQ on them, CERT-In's Comprehensive Cyber Security Audit Policy Guidelines (25 July 2025) and its empanelled-auditor list, a PIB release on CERT-In, the DPDP Rules, 2025 on meity.gov.in, and vendor pricing and product pages for PagerDuty, SolarWinds Incident Response (Squadcast), Atlassian's Opsgenie migration notice, Better Stack, Elastic, Wazuh and ManageEngine. Facts are as checked in October 2026. This is a guide for buyers, not legal advice.

The six duties in the 28 April 2022 Directions

The Directions were issued by CERT-In, under MeitY, using its power under sub-section (6) of section 70B of the Information Technology Act, 2000. They are addressed to "service providers, intermediaries, data centres, body corporate and Government organisations". CERT-In's FAQ explains that "body corporate" has the section 43A meaning: any company, and it includes a firm, sole proprietorship or other association of individuals engaged in commercial or professional activities. So a three-person Pune agency is in scope as much as a listed SaaS company. The Directions became effective 60 days after issue.

The FAQ states that non-compliance may attract the penal provisions of section 70B(7) of the IT Act, which it quotes as imprisonment for up to one year or a fine of up to one lakh rupees or both, and adds that the power "will be exercised reasonably and on occasions when the non-compliance is deliberate". Two further FAQ answers are worth a read by your legal lead. Reporting is not transferable: any entity that notices an incident must report it, and the obligation cannot be contracted away or indemnified. And the statutory duty overrides contractual confidentiality clauses, so a customer NDA is not a reason to stay quiet. The FAQ also says the Directions apply to any entity in matters of cyber incidents, including foreign firms that serve Indian users.

The 6-hour clock in practice

Annexure I lists 20 incident types. Several are bread and butter for a SaaS team: unauthorised access of IT systems or data, malicious code including ransomware, attacks on servers such as database, mail and DNS, identity theft, spoofing and phishing, denial-of-service attacks, attacks on applications such as e-commerce, data breach, data leak, attacks affecting digital payment systems, and malicious or suspicious activities affecting cloud computing systems, servers, software or applications. Reports go to incident@cert-in.org.in, phone 1800-11-4949 or fax 1800-11-6969, and the forms are published on cert-in.org.in.

You do not need a complete picture in six hours. The FAQ says entities may provide information to the extent available at the time of reporting, with additional information reported later within a reasonable time. It also says the incidents that must be reported within the stipulated six hours include data breaches or leaks, large-scale or frequent intrusions, severe attacks such as DoS, DDoS, intrusion or ransomware, and incidents affecting the safety of human beings.

A second clock may run beside it. Under the DPDP Rules, 2025, Rule 7, a Data Fiduciary that becomes aware of a personal data breach must tell each affected person without delay, tell the Data Protection Board without delay, and give the Board updated details within 72 hours (or a longer period the Board allows). Those provisions come into force 18 months after the Rules' publication of 13 November 2025, which we calculate as 13 May 2027, whereas the CERT-In duty is already in force. Our guide to DPDP Act compliance software covers Rule 7. A single runbook can serve both:

1. Hour 0 to 1: the on-call engineer confirms the alert, opens an incident record, and pages the incident lead.
2. Hour 1 to 4: contain the issue, capture evidence, and decide whether the event fits an Annexure I type.
3. By hour 6: the named Point of Contact files the CERT-In report with whatever is known.
4. Within 72 hours (from 2027): send the detailed update to the Board if personal data is involved; follow up with CERT-In with further facts.
5. Afterwards: a written post-incident review, with log excerpts preserved.

Logs: what, how long and where

Direction (iv) says logs of all ICT systems for a rolling period of 180 days, maintained within Indian jurisdiction. CERT-In's FAQ gives some nuance. On which logs, it lists examples: firewall logs, IPS logs, SIEM logs, web, database, mail, FTP and proxy server logs, event logs of critical systems, application logs, SSH logs, VPN logs, noting the list is not exhaustive and that both successful and unsuccessful events should be recorded. On location, one answer says logs may be stored outside India as long as the obligation to produce them to CERT-In is met in a reasonable time, while another says a service provider offering services to users in India needs to enable and maintain logs and records of financial transactions in Indian jurisdiction. Those answers are not identical, so if you are a regulated or payments business, assume the stricter reading and keep the logs in India. Our guide to MeitY-empanelled cloud providers covers Indian regions and RBI's payment-data rule.

Also check retention against other rules. DPDP Rule 6(1)(e) requires a Data Fiduciary to retain relevant logs and personal data for one year to detect unauthorised access, unless another law requires otherwise, and Rule 8(3) requires personal data, associated traffic data and logs of processing to be retained for a minimum of one year for specified purposes. So for systems that touch personal data, plan for a year, not 180 days. A quick sizing check: a service producing 20 GB of logs a day needs about 3.6 TB for 180 days (20 x 180) and 7.3 TB for a year, before compression. Keep the clocks right: log lines with wrong timestamps are nearly useless, which is why CERT-In's FAQ stresses time synchronisation, and says systems need not be set to IST as long as time zone information is recorded.

Tools: logs, SIEM and on-call

None of these products is "CERT-In certified". Choose by whether it can retain logs for the periods above, where the data sits, and how quickly it pages a human.

Prices are as shown on each vendor's pricing page in October 2026 and in US dollars. Better Stack's Responder licence is shown at $29 per month billed annually ($34 monthly), and its pricing is built with calculators, so ask for a quote at your volume.

One timing point matters for buyers of on-call software. Atlassian's migration notice says Opsgenie reached end of sale on 4 June 2025, that existing customers can keep using it until 5 April 2027, and that it will then be shut down, with its capabilities moving to Jira Service Management. If your on-call rota still sits in Opsgenie, plan the move before April 2027. For uptime checks and status pages, see our guide to uptime monitoring and status page tools, and for monitoring costs read observability tools and Datadog alternatives.

"CERT-In certified" and what auditors do

You will see SaaS vendors claim to be "CERT-In certified" or "CERT-In audited". CERT-In does not certify applications. Its Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) explain that CERT-In empanels Information Security Auditing Organisations to undertake audits, including vulnerability assessments and penetration testing, of computer systems, networks and applications. The guidelines apply to empanelled auditors and to auditee organisations in both public and private sectors. A PIB release on CERT-In's 2025 work says 231 cybersecurity audit organisations are empanelled, and the list is published on cert-in.org.in. RBI's payment-data FAQ separately says the System Audit Report must come from a CERT-In empanelled auditor.

So when a vendor says "CERT-In audited", ask: which empanelled auditor, what scope, which date, and can we see the report summary? The guidelines also say auditee organisations should use the snapshot information of empanelled auditors published on CERT-In's website to match their requirements to an auditor's competence, and should verify the credentials of the people deployed. Compare that with SOC 2 and ISO 27001 reports in our guide to SOC 2 and ISO 27001 automation for Indian SaaS, and see the cybersecurity category for vendors.

A 30-day plan for a small SaaS team

• Week 1: name the CERT-In Point of Contact and a deputy; send Annexure II details to CERT-In; set every server and container to a conforming NTP source; list your ICT systems and which logs each produces.
• Week 2: centralise logs in one store; set 180-day retention (a year for systems touching personal data); restrict access and alert on tampering.
• Week 3: set up on-call paging with a schedule, escalation and a test page; write the Annexure I decision tree on one page.
• Week 4: run a tabletop exercise: simulate a ransomware alert at 2 a.m. and time how long until the report is filed. Fix the gaps and repeat quarterly.

Who can start small? The duty covers "all" ICT systems, so almost every business has something to log; what changes is the scale of tooling. A five-person agency would typically start with the audit logs in its cloud suite, a calendar reminder to export them and a free paging app, rather than a SIEM, and should confirm the approach with its legal adviser.

FAQs