Cybersecurity directions from CERT-In: How Indian enterprises should strengthen logging and incident response

In 2025, India recorded nearly 28.15 lakh (approximately USD 29k) cybercrime incidents when compared to 22.68 lakh (approximately USD 23.5k) in 2024. Ransomware attacks impacted manufacturing firms, hospitals, financial institutions, and government entities alike. India's attack surface is expanding faster than its defenses. For enterprises, the question is no longer whether a breach will occur, but how quickly it will be detected, contained, and reported. This is precisely the gap that Indian Computer Emergency Response Team's (CERT-In) 2022 directions are designed to close.

Why CERT-In's directions matter now more than ever

The CERT-In functions as the nation's nodal agency for cybersecurity incident response, operating under the Ministry of Electronics and Information Technology (MeitY). For years, its guidelines were largely advisory in nature. The April 2022 directions changed that.

CERT-In issued these directions after identifying critical gaps in incident analysis—primary information was often missing or not readily available for investigations. Most incidents were either going unreported, reported too late, or reported without the contextual data needed for meaningful analysis.

Three years after the directions came into force, its relevance has only deepened. The convergence of AI-powered attacks, ransomware-as-a-service models, supply chain compromises, and the explosion of India's digital payment infrastructure has created an environment where rapid detection and response are existential capabilities. These directions expand the scope of mandatory reporting to include attacks on the emerging technologies such as AI, ML blockchain, and the IoT.

For enterprises, understanding and operationalizing these directions is no longer optional. The regulatory environment is undergoing a philosophical transformation from perfunctory checklists to evidence-based audits that require objective, operational proof of security effectiveness. Non-compliance carries penalties including imprisonment of up to one year and fines reaching ₹1 crore (approximately USD 10m).

A summary of the CERT-In directions: What is required

The CERT-In directions, issued under Section 70B(6) of the Information Technology Act, 2000, apply broadly to service providers, intermediaries, data centers, corporations, and government organizations (essentially any entity operating digital infrastructure in India or processing data of Indian users).

Here are the major requirements enterprises need to understand:

1. Mandatory 6-hour incident reporting

All service providers, intermediaries, data centers, and government organizations must report specified cybersecurity incidents to CERT-In within six hours of noticing them or being notified.

• Trigger: The clock starts upon awareness, not after a full investigation is completed.
• Scope: The list of reportable incidents is extensive, including data breaches, malware/ransomware attacks, targeted scanning of critical systems, and attacks on emerging technologies like AI, ML, and blockchain.

2. 180-day log retention

Organizations are required to maintain logs of all their information and communication technology (ICT) systems for a rolling period of 180 days.

• Availability: These logs must be made available to CERT-In during incident analysis or upon request.
• Jurisdiction: While logs can be stored outside India, a copy must be maintained or accessible within Indian jurisdiction.

3. Synchronization of system clocks

To ensure accurate forensic analysis across different networks, entities must synchronize their ICT system clocks with the National Time Protocol (NTP) provided by the National Informatics Centre (NIC) or National Physical Laboratory (NPL).

4. Mandatory annual cybersecurity audits

Entities must conduct an annual audit of their ICT infrastructure.

• Empaneled auditors: These audits must be performed by auditors from CERT-In's empaneled list, rather than general IT auditors.
• Evidence-based: Modern audit guidelines require proof (such as system logs, patch records, and forensics) rather than just procedural documentation.

5. Appointment of key personnel

• Point of contact (POC): Organizations must designate and provide CERT-In with the details of a POC to interface with the agency.
• Chief information security officer (CISO): Government entities are specifically required to nominate a CISO and a dedicated cybersecurity team to manage incident response and policy enforcement.

6. Extended data retention for specific sectors

Specific types of service providers have additional retention mandates:

• VPN and cloud providers: Data centers, VPS, VPN, and cloud service providers must maintain accurate subscriber registration details (names, IPs, registration timestamps, and purpose of service) for five years or longer.
• Virtual asset or crypto providers: Virtual asset service providers must maintain KYC records and transaction logs for five years to ensure financial accountability.

Why compliance is harder than it looks

The intent behind the directions is sound. The execution, however, exposes deep structural challenges across Indian enterprises.

The 6-hour window is deceptively short

Six hours sounds reasonable. In practice, it requires an enterprise to detect an incident, classify it, assess its scope, engage the right stakeholders, complete a structured report, and submit it while simultaneously trying to contain the breach. Without prebuilt playbooks, automated alerting, and clearly assigned roles, this timeline is nearly impossible to meet consistently. For context, the EU's GDPR allows 72 hours; the US CIRCIA framework allows 24 to 72 hours depending on the severity. India's six-hour window is among the strictest in the world.

Log management at scale is operationally complex

Most enterprises run heterogeneous environments spanning on-premises infrastructure, multi-cloud deployments, SaaS applications, endpoint devices, and third-party integrations. Maintaining consistent, tamper-proof logging across hybrid environments while retaining data for 180 days within Indian jurisdiction creates significant operational and storage challenges.

The economics make it worse. Some traditional SIEM platforms charge by the byte ingested, making full log retention expensive at enterprise scale. To cut costs, teams routinely disable noisy data sources or shorten retention windows. This creates the exact blind spots that hinder investigations and fail compliance audits. The trade-off between cost, coverage, and compliance is real, and most organizations are currently losing on at least one front.

Technical and administrative complexity

Beyond logging, the directions carry several layers of technical and administrative complexity that are easy to underestimate.

Clock synchronization across all ICT systems must point to designated Indian NTP servers. It is straightforward for a domestic operation, but complex for multinationals coordinating infrastructure across geographies, particularly given reported uptime and availability issues with some government time servers.

Jurisdictional requirements add another dimension: while logs may be stored globally, a copy must remain accessible within Indian jurisdiction, a non-trivial obligation for companies without a physical presence in the country.

Skill gaps are widespread

India faces a significant cybersecurity talent shortage. Building the internal capability to detect incidents, triage alerts, manage logs, and execute incident response in real time requires skilled analysts, and many enterprises, especially outside the top tier, simply do not have them.

Ambiguity in scope

The broad language of the directions, covering "any entity whatsoever" and "all ICT systems", leaves room for interpretation. What constitutes a reportable incident? Which specific logs are essential? These ambiguities can lead to over-reporting, under-reporting, and inconsistent implementation across business units.

Even the definition of what must be reported remains contested. Some researchers argue that the definitions of a "reportable incident" are too broad, leading to confusion about whether events like routine port scanning or automated bot traffic need to be reported.

Best practices for aligning with CERT-In directions

Meeting the letter and spirit of the directions requires a shift from reactive security to a posture of continuous readiness. Here's how enterprises can build toward that:

Build incident response plans before you need them

Draft and rehearse detailed incident response playbooks that map to CERT-In's list of reportable incident types. Because the directives leave room for interpretation, organizations can supplement CERT-In guidance with established frameworks such as NIST incident response guidance, MITRE mappings, and sector-specific regulatory requirements. Each playbook should define who is responsible for the six-hour submission, what information must be captured, and how the POC engages with CERT-In. Run tabletop exercises and simulations at least twice a year to validate that these plans work under pressure.

Implement centralized and comprehensive log management

Audit your entire IT environment and ensure logging is enabled across all critical systems: firewalls, Active Directory, servers, endpoints, cloud workloads, applications, and network devices. Centralize these logs into a single platform with tamper-evident storage. Structure your retention policies to cover the 180-day rolling window, with geo-fenced storage for India-jurisdiction data where applicable. Establish log integrity controls because logs that can be altered are effectively useless as evidence. Explicitly verify cloud storage regions and retention periods, as default settings often store data outside India or delete it after 30–90 days.

Synchronize clocks immediately

This is one of the most straightforward requirements to implement and one of the most often overlooked. Connect all ICT systems to the NTP servers specified by the NIC or NPL to ensure accurate log correlation across systems. Adopt a Zero Trust architecture that requires continuous authentication and authorization for every access request, which helps limit internal lateral movement during an attack. And mandate MFA for all remote access (VPNs) and administrative account.

Define and train your POC

Designate your CERT-In POC formally, document the role, and ensure the individual has the authority and access required to act within the six-hour window. The POC should have direct lines to the SOC, legal, IT leadership, and communications teams. Backup contacts should be identified for continuity.

Extend compliance obligations to vendors

Review all vendor and partner contracts to include cybersecurity incident notification obligations aligned with CERT-In timelines. Conduct supplier risk assessments and require critical vendors to demonstrate their own logging and incident response capabilities. A breach originating from a third-party does not exempt your enterprise from reporting obligations.

Asset and compliance management

Move beyond checklists by maintaining operational security effectiveness, such as SOC tickets, patch management records showing successful updates, and time-stamped dashboards. Book CERT-In empaneled auditors two to three months in advance of deadlines, as demand for these specialized auditors has increased significantly. Maintain an updated inventory of all authorized hardware and software. You must be able to show their operational security status during an audit.

Preparing for the 6-hour reporting window

Start the reporting process the moment you become aware of an incident, rather than waiting for a full root-cause analysis or technical containment. Maintain a prewritten incident report template (Annexure A) with organizational details (addresses, POC contacts, sector tags) already filled in. Establish an internal escalation process that triggers within the first hour of awareness. Ensure the incident commander has the authority to declare an event "reportable" without waiting for consensus from multiple committees. Designate reporting as a parallel work stream to technical response so it is not delayed by the investigation. Invest in automated alert triage, incident classification, evidence collection, and reporting templates that can be populated rapidly when an incident occurs.

Conclusion

Organizations that build these capabilities do not just become CERT-In compliant. They become genuinely more resilient: Faster to detect, faster to respond, and better positioned to limit the damage when breaches occur. The six-hour clock is always ticking. The question is whether your enterprise is ready when it starts.

Related solutions