If your organisation operates in India or serves Indian users from abroad, there is a set of cybersecurity obligations you are expected to meet whether or not anyone has told you about them. They come from CERT-In, and for many businesses they are the most concrete, enforceable security rules they’re subject to.
Here’s what they are, who they apply to, and what “being ready” actually means.
What is CERT-In?
The Indian Computer Emergency Response Team (CERT-In) is the country’s national nodal agency for cybersecurity incident response. It operates under the Ministry of Electronics and Information Technology (MeitY) and draws its statutory authority from Section 70B of the Information Technology Act, 2000.
On 28 April 2022, CERT-In issued a set of directions, formally Direction No. 20(3)/2022-CERT-In, and widely known simply as the “CERT-In Directions 2022” or the “6-hour rule.” They came into force on 28 June 2022, after a 60-day transition period, and remain the operative framework today.
Who is in scope?
The directions are deliberately broad. They apply to service providers, intermediaries, data centres, body corporates, and government organisations. They also name specific categories explicitly: Virtual Private Server (VPS) providers, cloud service providers, VPN service providers, and virtual asset service, exchange, and custodian wallet providers.
Crucially, the directions are not limited to a defined list of sectors. If you run ICT systems in India, the starting assumption should be that you are in scope until you’ve confirmed otherwise.
The core obligations
There are four obligations that apply broadly across covered entities:
- Report specified cyber incidents within 6 hours. Once you notice a reportable incident or are made aware of one, you have six hours to report it to CERT-In in the prescribed format. You don’t need a completed root-cause analysis; you report what you know within the window and follow up with detail. If you don’t have everything in six hours, you report to the extent you can and supplement afterwards.
- Synchronise system clocks to an approved NTP source. All ICT system clocks must be synchronised to the Network Time Protocol (NTP) server of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL). Accurate, consistent timestamps are what make forensic reconstruction possible after an incident.
- Maintain ICT system logs for 180 days, within India. Logs of all ICT systems must be enabled and retained for a rolling 180-day period, stored within Indian jurisdiction and made available to CERT-In on request.
- Designate a point of contact and respond to CERT-In. Covered entities are expected to nominate a point of contact to interface with CERT-In and to respond to its orders and requests for information.
What has to be reported
The directions list the reportable incident types in an annexure. It is a wide net, and it goes well beyond “we were breached.” Reportable categories include, among others: unauthorised access and targeted scanning or probing of systems; defacement; malicious code, ransomware, and cryptominers; data breaches and data leaks; identity theft, phishing, and fake mobile apps; denial-of-service and distributed denial-of-service attacks; attacks on IoT devices; and attacks on infrastructure such as servers, network appliances, and critical systems.
Because the list is broad, the practical question is rarely “is this reportable?” and more often “did we notice it in time to report within six hours?”
Extended retention for certain providers
Beyond the 180-day logging rule, specific provider categories carry a heavier retention burden:
- Data centres, VPS providers, cloud service providers, and VPN service providers must register and retain accurate subscriber and customer information, including validated names, the period of hire, IP addresses allotted, contact and address details, purpose of service, and ownership pattern for five years after any cancellation or withdrawal of registration.
- Virtual asset service, exchange, and custodian wallet providers must maintain KYC information and financial transaction records for five years.
Penalties for non-compliance
Non-compliance is addressed under Section 70B(7) of the IT Act, and can attract imprisonment of up to one year, a fine of up to ₹1,00,000 (one lakh), or both. In practice, the more material risks for most organisations are regulatory scrutiny, sectoral consequences from bodies such as the RBI, SEBI, or IRDAI, and the operational and reputational fallout of an incident handled badly.
How it overlaps with the DPDP Act
The CERT-In directions don’t exist in isolation. India’s Digital Personal Data Protection Act, 2023 introduces a parallel duty to notify personal-data breaches to the Data Protection Board. A single incident can therefore trigger obligations to more than one authority, on different timelines and with different thresholds. The sensible approach is to align your security and privacy workflows so that notifications are consistent in fact, scope, and timing rather than running them as two disconnected processes.
(The specifics of the DPDP breach-notification regime continue to be operationalised through rules — confirm the current position before building your notification playbook around it.)
A practical readiness checklist
You don’t comply with CERT-In by writing a policy. You comply by having the operational capability to detect, report, and prove. In practice that means:
- Confirm scope. Map your systems, data flows, and providers, and establish which obligations apply to you.
- Get logging right. Centralise logs, meet the 180-day retention rule within Indian jurisdiction, and store critical logs so they can’t be quietly altered.
- Sync your clocks. Point ICT systems at an approved NTP source and alert on drift — otherwise your evidence won’t line up.
- Build a six-hour reporting capability. Six hours is not much time to notice an incident, let alone report it. That deadline is really a detection requirement in disguise.
- Name your point of contact and write the runbook. Decide in advance who reports, in what format, and how, so nobody is improvising during an incident.
- Align with DPDP. Where an incident is also a personal-data breach, make sure both notifications flow from one coordinated process.
The organisations that struggle with CERT-In aren’t usually the ones who don’t know the rules. They’re the ones who can’t see their own environment quickly enough to act inside a six-hour window. Compliance here is downstream of visibility.
Meeting these directions depends on the security operations underneath them: centralised logging, retention, time synchronisation, and detection fast enough to report inside six hours. That foundation is exactly what ForshSec helps organisations set up. If CERT-In readiness is on your list, we’re happy to help you scope it.
