CERT-In log retention: keeping 180 days of logs, in India

The Directions issued by CERT-In on 28 April 2022 under section 70B(6) of the IT Act include a short sentence with large consequences: service providers, intermediaries, data centres, body corporates and government organisations must enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days, within Indian jurisdiction. The logs must be provided to CERT-In along with an incident report, or when CERT-In orders them.

What counts as an ICT system

In practice, anything that runs or carries your service: servers and virtual machines, containers and Kubernetes clusters, databases, firewalls, VPNs, load balancers, DNS, identity providers and single sign-on, email, and the cloud control plane itself. Application logs matter too, because they show what a user or an attacker actually did.

Where teams usually fall short

• Default retention is shorter than 180 days in many tools and services. Logs simply expire before anyone notices.
• Cloud audit logs are kept only in the provider's short default history, rather than exported to storage you control.
• Network devices, VPNs and SaaS tools log to their own consoles, with their own retention, and nobody collects them.
• Logs are kept, but in a region outside India.
• Logs can be changed or deleted by the same administrators whose actions they record.

Setting 180 days on the main clouds

AWS

CloudTrail's event history in the console covers 90 days of management events. Create a trail that delivers to an S3 bucket in an Indian region (ap-south-1 Mumbai or ap-south-2 Hyderabad), with a lifecycle rule that keeps objects for at least 180 days. Set CloudWatch Logs groups' retention to 180 days or more; the default for a new log group is never expire, but many teams set shorter values to save money. Turn on S3 Object Lock or a restrictive bucket policy so the logs can't be altered.

Microsoft Azure

The Activity Log is kept for 90 days by default. Add a diagnostic setting to send it, and resource logs, to a Log Analytics workspace or storage account in Central India, South India or West India, and set retention to at least 180 days. Use immutable storage policies on the archive account.

Google Cloud

Admin Activity audit logs are kept for 400 days in the _Required bucket, but Data Access logs and other logs go to the _Default bucket with 30 days' retention. Create a log bucket in asia-south1 (Mumbai) or asia-south2 (Delhi), route logs to it with a sink, set retention to 180 days or more, and lock the bucket's retention policy if you need it immutable.

Keeping logs secure

Maintaining logs securely means more than storing them. Restrict who can read them (logs often contain personal data and secrets), separate the people who can delete them from the people whose actions they record, and use write-once storage where your platform offers it. Encrypt them at rest, and record who accessed them.

Clocks: why NTP is part of the same problem

Logs from different systems are only useful together if their timestamps agree. The same Directions require clocks to be synchronised with the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or with time sources traceable to them. Check this on servers, network devices and anything that keeps its own time.

Cost: keep 180 days without paying for 180 days of fast search

Retention doesn't have to mean expensive hot storage. Keep recent logs (say 14 to 30 days) in your search tool, and archive everything to object storage in India for the full 180 days, where it costs a small fraction as much. You can load archived logs back when an investigation needs them. Dropping pure noise such as health-check lines before it's stored cuts the bill further without losing anything investigators need.

A worked example: a SaaS company on AWS

Consider a SaaS company in Bengaluru running on AWS in Mumbai, with Kubernetes, a managed PostgreSQL database, Cloudflare in front, Google Workspace for staff and GitHub for code. Its logs live in at least six places: CloudTrail, CloudWatch Logs for the cluster and database, the Kubernetes audit log, Cloudflare's logs, Google Workspace's admin and login audit logs, and GitHub's audit log. Each has its own default retention, and several are far shorter than 180 days or depend on the plan.

A practical setup sends all of them to one place: an S3 bucket in ap-south-1 with a lifecycle rule moving objects to a cheaper storage class after 30 days and deleting them after, say, 200 days, with Object Lock to stop changes. CloudTrail and CloudWatch export there directly; Cloudflare Logpush can deliver to S3; Workspace and GitHub audit logs can be pulled on a schedule through their APIs or a log collector. Search covers the last few weeks; the archive covers the rest.

Common mistakes

• Assuming the cloud provider keeps logs long enough. Default histories are often 30 or 90 days.
• Keeping logs, but only from production servers, not from identity, network, VPN and SaaS tools where many incidents start.
• Storing the archive in a region outside India by default, for example a bucket created in us-east-1.
• Letting the same administrators who could cause an incident delete the logs that would show it.
• Never testing a restore, then finding during an incident that old logs are in a format nobody can read quickly.

How to verify

Pick a date about 170 days ago and try to answer a specific question from the logs: who signed in to the cloud console that day, which IP addresses reached the VPN, what the firewall blocked. If you can answer it within an hour, from storage in India, for every system on your inventory, you're in good shape. Record the test, because it's exactly the evidence an auditor asks for.

Checklist

• An inventory of every ICT system that produces logs, including SaaS, network and identity.
• Logging enabled on each, including cloud audit logs.
• Retention of at least 180 days, checked in each tool, not assumed.
• A copy of the logs stored in an Indian region.
• Write-once storage or equivalent protection against changes and deletion.
• Clocks synchronised to NIC or NPL, or a traceable source.
• A tested way to export the logs for a time window, to hand to CERT-In.

This guide summarises the Directions. Read the current text and CERT-In's FAQs on cert-in.org.in, which discuss specific situations such as logs held by providers outside India, and check sector regulators' rules, which can be stricter.