CERT-In Compliance: What Every Organization in India Needs to Know

Understanding CERT-In Compliance Requirements in India

In April 2022, the Indian Computer Emergency Response Team issued a directive that fundamentally changed how organizations approach cybersecurity incident management. The CERT-In compliance requirements India’s regulated enterprises must now meet are among the most stringent globally, with timelines that leave little room for improvisation.

For compliance leaders at banks, NBFCs, insurance companies, pharmaceutical firms, and IT service providers, these requirements layer on top of sector-specific regulations from RBI, SEBI, and IRDAI. The challenge is not just understanding what CERT-In mandates. It is building operational processes that can actually deliver compliance under pressure, when a cyber incident is unfolding in real time.

This guide breaks down every major requirement, explains who it applies to, and provides a practical framework for building an incident response process that meets the six-hour reporting threshold without collapsing under its own complexity.

CERT-In’s Role and Authority in India’s Cybersecurity Framework

CERT-In operates under the Ministry of Electronics and Information Technology as India’s national nodal agency for cybersecurity incident response. Its authority derives from the Information Technology Act, 2000, specifically Section 70B, which empowers it to collect, analyze, and disseminate information on cyber incidents.

The agency’s mandate extends beyond advisory functions. CERT-In has the legal authority to call for information from service providers, intermediaries, and data centers regarding cyber incidents. Non-compliance can attract penalties under the IT Act, including potential imprisonment for individuals responsible for obstruction or non-furnishing of information.

Scope of Authority

CERT-In’s directives apply to a broad range of entities. These include service providers, intermediaries, data centers, body corporates, and government organizations. For regulated industries, this creates a dual reporting environment. A bank experiencing a data breach must notify both RBI under its master directions and CERT-In under the April 2022 directive. The timelines and information requirements differ, which demands careful process design.

The agency also maintains coordination relationships with sectoral regulators. However, notification to one does not satisfy the obligation to the other. Each regulator expects direct reporting through its specified channels and formats.

The April 2022 Directive: A Complete Breakdown

The directive issued on April 28, 2022, came into effect on June 28, 2022. It introduced requirements that many organizations found challenging to implement within the sixty-day window. Understanding the full scope of these requirements is essential for compliance leaders who may have implemented initial workarounds that need revisiting.

Entities Covered

The directive applies to service providers, intermediaries, data centers, body corporates, and government organizations. In practice, this captures virtually every enterprise operating digital infrastructure in India. Cloud service providers, managed security service providers, VPN providers, and virtual private server providers face additional specific obligations.

For regulated enterprises in BFSI, pharma, and healthcare, the directive applies regardless of whether the organization considers itself primarily a “technology” company. Any entity that operates information systems, computer resources, or provides services over the internet falls within scope.

Reportable Incident Categories

CERT-In specified twenty categories of incidents that must be reported. These range from obvious events like targeted scanning and malicious code attacks to less intuitive categories like website defacements and unauthorized access to social media accounts. The full list includes:

The breadth of these categories means that most security events detected by a mature security operations center will trigger reporting obligations. Organizations cannot selectively report only “serious” incidents. The directive requires reporting of any incident falling within these categories, regardless of perceived severity.

The Six-Hour Incident Reporting Obligation

The most demanding requirement in the directive is the six-hour window for incident reporting. This timeline begins from the moment the organization becomes aware of an incident, not from the moment containment is complete or the full scope is understood.

What “Awareness” Means

CERT-In has clarified that awareness means the point at which the organization’s systems or personnel detect an incident. For organizations with 24/7 security operations centers, this is straightforward. For others, the clock starts when the incident is detected, even if the relevant compliance team is not immediately informed.

This creates operational pressure to ensure that incident detection triggers compliance workflows immediately. A delay of even a few hours between SOC detection and compliance team notification can consume half the available reporting window.

Information Required in Initial Report

The initial report need not be exhaustive. CERT-In acknowledges that full forensic analysis takes time. However, the initial notification must include the nature of the incident, systems affected, initial assessment of impact, and preliminary details about the attack vector if known.

Subsequent reports with additional details can follow as the investigation progresses. The key is establishing initial contact within the six-hour window with whatever information is available at that point.

Reporting Channels

Reports must be submitted through CERT-In’s designated channels. The agency accepts reports via email at incident@cert-in.org.in, through its online portal, and via phone for urgent matters. Regulated enterprises should establish which channel works best for their incident response process and ensure contact details are current.

Consider an NBFC that discovers unauthorized access to its loan management system at 2 AM on a Saturday. The six-hour clock is already running. If the incident response playbook does not include pre-drafted notification templates and clear escalation paths to personnel authorized to report externally, meeting the deadline becomes a scramble rather than a process.

Log Retention Requirements: The 180-Day Mandate

Beyond incident reporting, the directive mandates that all entities maintain logs of their ICT systems for a rolling period of 180 days. These logs must be maintained within Indian jurisdiction and provided to CERT-In upon request.

Scope of Logs Required

The directive does not specify precise log categories, which has created interpretation challenges. However, guidance from CERT-In indicates that logs should enable reconstruction of events during a cyber incident. This practically means firewall logs, system logs, application logs, authentication logs, and network flow data.

For regulated enterprises already subject to RBI or SEBI cybersecurity frameworks, the log retention requirements overlap significantly with existing obligations. The additional consideration is ensuring logs are stored in a manner that allows rapid retrieval and handover to CERT-In if requested during an investigation.

Jurisdictional Storage Requirement

Logs must be maintained within Indian jurisdiction. For organizations using global cloud providers, this requires explicit configuration to ensure log storage remains in Indian data centers. The requirement applies even if the primary application infrastructure operates globally.

This creates architecture considerations for multinational enterprises with Indian operations. Logs relating to Indian users, Indian infrastructure, or services provided in India must be retained domestically, even if the global SOC operates from another geography.

VPN and Cloud Provider Obligations

The directive includes specific requirements for Virtual Private Network service providers, Virtual Private Server providers, and cloud service providers. These entities must register certain information about their subscribers and maintain it for five years after service termination.

Information to be Retained

VPN providers must maintain validated names of subscribers, period of hire including dates, IPs allotted to members, email addresses and timestamps, purpose for hiring services, validated addresses and contact numbers, and ownership patterns of subscribers.

For enterprise IT teams, this creates compliance considerations when selecting VPN and cloud providers. Vendors who cannot demonstrate compliance with these requirements create regulatory risk for the subscribing organization.

Impact on Enterprise Procurement

Compliance leaders should incorporate CERT-In requirements into vendor assessment frameworks. Questions about log retention, data localization, and subscriber information maintenance should be standard elements of due diligence for VPN and cloud providers serving Indian operations.

Building an Incident Response Process That Meets CERT-In Requirements

Meeting CERT-In compliance requirements in India demands more than policy documentation. It requires operational processes that can execute under pressure, within tight timeframes, while the organization is simultaneously managing the technical response to a cyber incident.

Establishing Detection-to-Notification Workflows

The six-hour window is the binding constraint around which incident response must be designed. Working backward from this deadline, organizations need to map every handoff between detection, triage, assessment, and notification. Each handoff introduces delay risk.

A practical approach involves creating pre-authorized notification templates for common incident categories. When an incident is detected, the compliance team should be able to populate and submit an initial report within sixty to ninety minutes, reserving the remaining time for escalation and approval if required.

Designating Authorized Reporters

CERT-In expects organizations to designate a Point of Contact responsible for incident reporting. This individual’s details must be registered with CERT-In and kept current. Organizations should ensure backup personnel are also designated, given that incidents do not respect business hours.

The POC should have authority to submit initial notifications without requiring multi-layer approvals that consume the reporting window. Legal and management review can accompany subsequent detailed reports, but the initial notification must go out on time.

Integrating with Sectoral Reporting Obligations

For regulated enterprises, CERT-In reporting exists alongside sectoral requirements. A bank must report to RBI under the Cyber Security Framework for Banks. An insurance company must notify IRDAI. These reports have different formats, timelines, and approval requirements.

Building a unified incident management process that captures information once and generates regulator-specific reports reduces duplication and error risk. Platforms like eQomply that support multi-regulator compliance workflows can help consolidate these processes, ensuring that a single incident triggers parallel workflows for CERT-In, sectoral regulators, and internal stakeholders.

Log Management Infrastructure

The 180-day log retention requirement demands dedicated infrastructure. Organizations should implement centralized log management that aggregates logs from all relevant systems, stores them in Indian-jurisdiction infrastructure, maintains integrity through tamper-evident storage, and enables rapid search and export for CERT-In requests.

For organizations already operating SIEM platforms, this may require configuration adjustments to extend retention periods and ensure storage localization. For others, the requirement may necessitate new infrastructure investment.

Testing Through Tabletop Exercises

The only way to know whether an incident response process will meet the six-hour deadline is to test it before a real incident occurs. Tabletop exercises that simulate realistic scenarios, complete with weekend timing, key personnel unavailability, and ambiguous initial indicators, reveal process gaps that look fine on paper.

Exercises should track actual time elapsed at each stage, from detection through notification. If exercises consistently consume five or more hours, the process has no margin for the complications that real incidents inevitably introduce.

Consequences of Non-Compliance

The IT Act provides for penalties including imprisonment for up to one year and fines for failure to furnish information requested by CERT-In or for obstructing its functions. While prosecutions have been limited to date, the regulatory environment is tightening.

Beyond direct penalties, non-compliance creates downstream risks. Sectoral regulators increasingly cross-reference CERT-In compliance when assessing overall cybersecurity posture. A bank that fails to report an incident to CERT-In may face heightened scrutiny from RBI on the adequacy of its incident management framework.

For organizations handling personal data, the Digital Personal Data Protection Act, 2023 introduces additional breach notification obligations. While DPDP Act timelines and formats differ from CERT-In requirements, the underlying incident response capability is common to both. Investing in robust incident management processes serves compliance across multiple regulatory frameworks.

Moving from Compliance Burden to Operational Readiness

CERT-In’s requirements, while demanding, align with cybersecurity best practices that regulated enterprises should be pursuing regardless of regulatory obligation. The six-hour reporting window forces organizations to build detection and triage capabilities that enable rapid response. The log retention mandate creates forensic capabilities that support both regulatory investigations and internal security improvement.

The organizations that treat CERT-In compliance as a checkbox exercise will find themselves scrambling when incidents occur. Those that use the requirements as a framework for building genuine incident response capability will be better positioned to manage cyber risk, satisfy regulators, and maintain stakeholder trust.

For compliance leaders managing CERT-In obligations alongside RBI, SEBI, IRDAI, and DPDP Act requirements, the challenge is building unified processes that serve multiple regulators without creating operational chaos. Purpose-built GRC platforms can provide the workflow orchestration, evidence management, and reporting capabilities that make this achievable. If your current tools leave you uncertain about meeting the six-hour window, it may be worth exploring how eQomply’s incident management capabilities can help consolidate your regulatory response processes.