CERT-In Log Retention: What Organizations Need to Know

CERT-In Log Retention Requirements: Understanding the 180-Day Mandate

When CERT-In issued its Directions under Section 70B of the IT Act in April 2022, the CERT-In log retention requirements became one of the most operationally demanding mandates for India’s regulated enterprises. The directive requires all entities to maintain logs of their ICT systems for a rolling period of 180 days, stored within Indian jurisdiction, and to furnish them to CERT-In when requested during incident investigation or compliance verification.

For compliance leaders at banks, NBFCs, insurance companies, capital market intermediaries, and IT services firms, this requirement does not exist in isolation. It overlaps with and sometimes conflicts with log management expectations from RBI, SEBI, and IRDAI. The challenge is not merely storing logs. It is building a log retention architecture that satisfies multiple regulators without duplicating effort or creating governance gaps.

What the 180-Day Log Retention Directive Requires

The CERT-In Directions of 28 April 2022 specify that all service providers, intermediaries, data centres, body corporates, and government organizations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days. These logs must be maintained within Indian jurisdiction and shall be provided to CERT-In along with reporting of any incident or when ordered to do so.

The directive is notable for its breadth. Unlike sector-specific regulations that apply to particular entity types, this applies to virtually every organization operating ICT infrastructure in India. The 180-day window is a minimum, not a ceiling. Organizations subject to sectoral regulators may need to retain certain log categories for longer periods based on those regulators’ specific requirements.

The obligation is continuous. You cannot retain logs selectively or purge them before the 180-day window closes. The rolling nature means that at any given point, you must have at least the preceding 180 days of logs available, intact, and producible on demand.

Scope of Applicability

Consider a mid-sized NBFC that operates core banking systems, customer-facing mobile applications, internal collaboration tools, and cloud infrastructure across multiple providers. Every one of these systems generates logs that fall under the directive’s scope. The NBFC cannot choose which systems to cover. The mandate is comprehensive across all ICT infrastructure the entity operates or uses.

This is particularly relevant for organizations that use third-party managed services or cloud providers. The responsibility to maintain and produce logs remains with the entity, regardless of where the infrastructure is hosted. Contractual arrangements with service providers must explicitly address log availability, format, and jurisdictional storage.

Which Logs Must Be Retained Under CERT-In Requirements

The directive does not provide an exhaustive list of log types, which creates both flexibility and ambiguity. However, CERT-In’s subsequent FAQs and enforcement posture make clear that the following categories are squarely within scope.

Network and Perimeter Logs

Firewall logs capturing traffic allowed and denied across network boundaries form the foundational layer. These include source and destination IP addresses, ports, protocols, timestamps, and actions taken. For organizations with multiple perimeter points, including cloud-based firewalls, web application firewalls, and on-premise appliances, each must generate and retain logs independently.

Intrusion Detection and Prevention System (IDS/IPS) logs must be retained with full alert context. This includes signature matches, anomaly detections, and any automated response actions. These logs are particularly critical during incident investigation, as they often provide the earliest indicators of compromise.

System and Server Logs

Operating system event logs from all servers, including authentication events, privilege escalation, service starts and stops, and system errors, fall within scope. For Windows environments, this means Security, System, and Application event logs at minimum. For Linux/Unix systems, syslog, auth.log, and kernel logs are essential.

Database server logs capturing query execution, schema changes, administrative actions, and connection events must also be retained. For regulated enterprises handling sensitive financial or personal data, these logs serve a dual purpose: satisfying CERT-In requirements while also providing audit trails for data access governance under DPDP Act requirements.

Application and Access Logs

Application-level logs from customer-facing systems, internal business applications, and APIs must capture user actions, authentication attempts (successful and failed), session management events, and data access patterns. Access logs from web servers, application gateways, and reverse proxies recording all HTTP/HTTPS requests with timestamps, source IPs, requested resources, and response codes are equally important.

VPN and remote access logs deserve particular attention. With distributed workforces now standard across Indian enterprises, these logs capture the boundary between external networks and internal resources. Connection timestamps, user identities, source locations, duration, and bandwidth usage must all be preserved.

Email and Communication Logs

Email server logs capturing message metadata (sender, recipient, timestamp, subject lines, attachment presence) must be retained. This does not necessarily mean retaining email content, but the transactional metadata that would allow reconstruction of communication patterns during an investigation.

The following table summarizes log categories with their retention context:

Storage and Integrity Considerations for CERT-In Log Retention

Retaining logs for 180 days creates a significant storage challenge, particularly for large enterprises generating terabytes of log data daily. The directive’s requirement that logs be maintained within Indian jurisdiction adds a constraint that affects architecture decisions for organizations with global cloud deployments.

Jurisdictional Storage

All logs must reside on infrastructure located within India. For organizations using hyperscale cloud providers, this means configuring log storage buckets, blob stores, or managed SIEM instances in Indian regions specifically. Multi-region log aggregation architectures must ensure that the canonical copy, the one you would produce to CERT-In, remains within Indian borders.

Consider an insurance company running workloads across AWS Mumbai and Singapore regions for disaster recovery. Application logs generated in the Singapore region must be replicated to Indian storage within a timeframe that ensures no gaps in the 180-day rolling window. Architectural decisions around log shipping latency, deduplication, and failover handling directly affect compliance posture.

Log Integrity and Tamper Evidence

Logs that can be modified after generation have limited evidentiary value. While the CERT-In directive does not prescribe specific integrity mechanisms, the implicit requirement is clear: logs must be trustworthy when produced. This means implementing write-once storage, cryptographic hashing of log entries, or centralized log management systems that prevent modification after ingestion.

Chain of custody matters. If CERT-In requests logs during an incident investigation, your ability to demonstrate that the logs are complete and unaltered from the point of generation determines their utility. Organizations should implement log forwarding to centralized, immutable storage as close to real-time as possible. Relying on logs stored locally on the systems that generated them creates both integrity and availability risks.

Availability and Retrieval

The directive requires that logs be “provided” to CERT-In upon request. This implies they must be retrievable within a reasonable timeframe. Archiving logs to cold storage tiers that require days to retrieve may technically satisfy the retention requirement but creates practical problems during incident response, where CERT-In expects rapid cooperation.

A tiered storage strategy works well here: hot storage for the most recent 30 days of logs (for internal security operations and immediate incident response), warm storage for 30 to 180 days (rapidly retrievable for regulatory requests), and cold storage beyond 180 days for logs that sectoral regulators require you to keep longer.

How CERT-In Log Retention Intersects with RBI and SEBI Cybersecurity Requirements

For BFSI entities, CERT-In’s 180-day log retention requirement does not operate in a vacuum. It layers on top of existing obligations from sectoral regulators that have their own log management expectations, sometimes with different parameters.

RBI’s Cybersecurity Framework and IT Governance Guidelines

RBI’s Cybersecurity Framework for banks (issued in 2016 and subsequently updated) requires banks to maintain logs and monitor them for anomalies. The RBI IT framework for NBFC and banks requires maintenance of audit trails for all critical systems. While RBI does not always specify an exact retention period matching CERT-In’s 180 days, its expectations around incident investigation, forensic readiness, and supervisory examination effectively require log availability well beyond six months.

RBI’s Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices requires regulated entities to ensure that logs are available for forensic investigation purposes. In practice, RBI examiners during IT inspections request logs going back 12 months or more for critical systems. This means banks and NBFCs should treat 180 days as a floor, not a target.

SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF)

SEBI’s CSCRF, applicable to market infrastructure institutions, stock brokers, depositories, and other regulated intermediaries, explicitly requires log retention for audit trail purposes. The framework mandates that logs be maintained for periods that allow effective investigation of security incidents and market irregularities.

For capital market entities, the intersection creates a practical challenge. SEBI expects logs to support market surveillance and trading pattern analysis, which means application-level logs from trading systems and order management systems need richer context than what CERT-In’s infrastructure-focused directive might imply. A stock broker must retain not just firewall and server logs for CERT-In purposes, but also detailed application logs that show user actions within trading platforms for SEBI purposes, all within the same governance framework.

The Overlap Challenge

Consider a private sector bank managing compliance across RBI’s IT governance framework, CERT-In’s 180-day directive, and (if it has capital market operations) SEBI’s CSCRF simultaneously. This creates three structural challenges that most risk functions are not equipped to handle independently.

First, retention periods differ. CERT-In mandates 180 days minimum. RBI examiners expect longer. SEBI may require specific log types for even longer periods tied to market investigation timelines. The log retention policy must account for the longest applicable period per log category, not a single blanket policy.

Second, production formats vary. CERT-In may request logs in raw format for technical analysis. RBI supervisors may expect summarized reports derived from logs. SEBI surveillance teams may need logs correlated with specific transaction identifiers. A single log retention infrastructure must serve multiple consumption patterns.

Third, accountability structures differ. CERT-In requests flow through the designated CISO or incident response function. RBI examination requests come through the compliance function. SEBI requests may route through the compliance officer or the designated technology officer. Without a unified compliance tracking mechanism, requests can fall through gaps between functions.

Building a Log Retention Process That Satisfies Multiple Regulators

Given these overlapping requirements, the goal is to build a log retention process that is regulator-agnostic at the infrastructure layer while being regulator-specific at the governance and production layer.

Unified Log Collection and Storage

Regardless of which regulator ultimately requests the logs, the collection and storage infrastructure should be singular. All logs from all systems flow into a centralized, immutable log management platform. Deduplication, normalization, and indexing happen once. This eliminates the common failure mode where different teams maintain separate log stores for different regulatory purposes, creating inconsistencies and gaps.

The storage layer must satisfy the most stringent requirement across all applicable regulators. For most BFSI entities, this means retention well beyond 180 days for critical system logs, Indian jurisdictional storage, integrity controls, and rapid retrieval capability.

Policy-Driven Retention Rules

Rather than applying a flat 180-day retention period across all logs, implement a policy engine that applies regulator-specific retention rules per log category. Firewall logs might be retained for 180 days per CERT-In requirements. Core banking system audit logs might be retained for five years per RBI expectations. Trading system logs might follow SEBI’s prescribed periods.

This policy-driven approach requires a comprehensive mapping between log sources, log categories, applicable regulations, and retention periods. Maintaining this mapping manually in spreadsheets is feasible for small organizations with limited infrastructure. For enterprises operating hundreds of systems across multiple business lines, each subject to different regulatory regimes, this mapping needs to be managed within a structured compliance platform.

Platforms like eQomply that consolidate regulatory requirements across CERT-In, RBI, SEBI, and IRDAI into unified compliance workflows can help risk teams maintain this mapping without creating parallel tracking mechanisms for each regulator. The ability to trace a specific log retention requirement back to its regulatory source, track compliance status, and produce evidence of adherence during examinations becomes particularly valuable when facing simultaneous audits from multiple regulators.

Incident Response Integration

Log retention exists primarily to support incident investigation. The connection between your log retention infrastructure and your CERT-In six-hour incident reporting process must be explicit and tested. When an incident triggers the six-hour reporting obligation, the responding team must be able to access, analyze, and extract relevant logs immediately, not after filing retrieval requests with the infrastructure team.

Regular drills that simulate CERT-In requesting logs for a specific time window across specific systems will expose retrieval latency issues, format problems, and integrity gaps before they become compliance failures during actual incidents.

Evidence of Compliance

Retaining logs is necessary but not sufficient. You must also demonstrate to regulators that you have a process for retaining logs, that the process operates continuously, and that you can produce logs on demand. This means maintaining documented policies, configuration evidence showing log forwarding is active, periodic validation reports confirming log completeness, and records of any gaps or failures in log collection with remediation actions taken.

During RBI IT examinations or SEBI inspections, examiners increasingly ask not just “show me the logs” but “show me how you ensure logs are always being collected and retained.” The process evidence matters as much as the logs themselves.

Operationalizing Compliance Across Regulatory Mandates

The CERT-In 180-day log retention requirement, when viewed alongside sectoral regulatory expectations, is ultimately a test of operational maturity. Organizations that treat it as a standalone infrastructure project, deploying a SIEM and configuring retention policies, address the surface requirement. Organizations that embed it within a broader regulatory compliance architecture, where log retention is one control among many that must be tracked, evidenced, and reported across multiple regulatory relationships, build durable compliance posture.

For compliance leaders and CISOs at regulated Indian enterprises, the question is whether your current GRC infrastructure allows you to manage CERT-In log retention requirements alongside RBI, SEBI, and IRDAI obligations within a single governance framework, or whether each regulatory mandate lives in its own silo, creating duplication, inconsistency, and blind spots.

If you are evaluating how to consolidate multi-regulator compliance tracking, including CERT-In directives, into a unified framework purpose-built for Indian regulatory complexity, a brief conversation with our team can help you assess where your current gaps are and what a structured approach looks like in practice.