CERT-In log retention: 180 days in-country without unaffordable storage

The CERT-In Directions require logs of all ICT systems to be maintained securely for a rolling 180 days within Indian jurisdiction. Most organisations respond by asking their SIEM vendor for a quote to extend retention across the estate, receive a number with two commas in it, and stall.

That number is real, and it is also avoidable. The requirement is a retention and residency obligation, not an indexing obligation — and conflating the two is what makes it expensive.

What the obligation actually says#

Two clauses matter. Logs of all ICT systems must be maintained securely for a rolling period of 180 days, and they must be maintained within Indian jurisdiction. They must be provided to CERT-In along with a reported incident, or when ordered.

Read carefully, that is a preservation duty with a production duty attached. It says nothing about query latency. A log retrieved from archive storage in four hours satisfies a production order exactly as well as one returned from a hot index in four seconds.

Your security operations team needs fast search. Your regulator needs the records to exist, to be unaltered, and to be producible. Those are different requirements with different cost profiles, and designing one system to satisfy both at the strictest level is where the money goes.

Three tiers#

Hot — 7 to 14 days, indexed and searchable. This is where investigation happens and it is the expensive tier, typically an order of magnitude more per gigabyte than the alternatives. Keep it short. Almost all incident investigation touches the last fortnight; the cases that need older data are rare enough to tolerate a slower path.

Warm — to 90 days, compressed object storage in an Indian region. Queryable on demand with a few minutes of latency, usually via an external table or a rehydration step. Costs roughly a twentieth of hot storage. This tier covers the "we found something in week six, what happened in week two" case without paying index prices for it.

Cold — to 180 days and beyond, archive-class with immutability enabled. Retrieval takes hours, which is unacceptable for investigation and entirely acceptable for a regulatory production order. This is the tier that satisfies the letter of the obligation, and it is close to free at the volumes most organisations generate.

Ingest
  ├─► Hot index (7–14d)         search in seconds     ~₹₹₹₹ per GB
  ├─► Warm object store (90d)   search in minutes     ~₹₹ per GB
  └─► Cold archive (180d+)      retrieval in hours    ~₹ per GB
                                immutability ON

One client running a citizen services platform had been quoted for extending SIEM licensing across the full estate. The tiered design met the same obligation at approximately a fifth of that figure, and gave them 90 days of practical searchability rather than the 30 they had before.

Immutability is the part that matters#

Retention without immutability is an assertion. Retention with immutability is evidence.

If logs can be altered or deleted by anyone with administrative access — including an attacker who has obtained it — then their value as a record of what happened is exactly zero at the moment you most need it. Every major cloud provider offers object-lock or equivalent write-once storage; enable it on the cold tier and set the retention period to match the obligation.

Two configuration details are worth getting right:

• Set the lock at the bucket level with a default retention period, not per object. Per-object locking depends on the writer setting it correctly every time, which eventually it will not.
• Deny the delete and lock-modification permissions at organisation level, not just in the role policy. If a compromised administrator can turn off immutability, it is not immutability.

The residency question people get wrong#

The requirement does not prohibit foreign cloud. It requires the logs be retained within Indian jurisdiction.

The pattern that works: run workloads wherever the architecture calls for it, and replicate logs into an Indian region with restricted access and immutability. All major hyperscalers offer Indian regions. What is not acceptable is logs held solely outside India with no in-country copy — which is the default for a lot of SaaS-heavy estates, because the SaaS product decides where its logs live.

That last point is the one to check. Verify where your SIEM actually stores data rather than trusting the contract's data residency clause. Those differ more often than not, particularly with vendors who added an Indian region after you signed. Ask for the storage region of the specific tenant, in writing.

The same question applies to every SaaS product generating logs you would need after an incident: identity provider, code hosting, ticketing, endpoint agent. Each one is a potential gap, and each is easier to fix at renewal than under a production order.

What counts as "all ICT systems"#

Broader than most scoping exercises assume. In practice we scope to anything that would be relevant to reconstructing an incident:

Volume is dominated by the first four. Application and database logs are usually smaller than expected and disproportionately useful, because they are the layer at which "what did the attacker actually take" gets answered.

Clock synchronisation, since it lives here#

The same directions require all ICT system clocks to synchronise to NPL or NIC NTP servers, or sources traceable to them. This is a five-minute configuration change that is missed for years, and it undermines everything above — a timeline assembled from systems with drifting clocks is not evidence.

Verify it across every system class rather than assuming. Cloud instances, network appliances and virtual machines built from old images are the three that routinely point somewhere else.

Proving the retention, not just performing it#

An obligation you meet but cannot demonstrate is, in an examination, indistinguishable from one you did not meet. Three artefacts close that gap and none is expensive.

A log source register. Every source, its destination tier, its retention period, its storage region and its owner. One table. When CERT-In or an auditor asks what you retain and where, this is the answer, and maintaining it also surfaces the sources that quietly stopped shipping.

Ingestion monitoring with alerting on silence. The most common retention failure is not deletion — it is a source that stopped sending six weeks ago and nobody noticed. Alert on the absence of expected volume per source, not just on errors. A log source that goes quiet is either broken or being suppressed, and both warrant a look.

A quarterly retrieval test. Pick a random date inside the 180-day window, request the logs for one source, and time it. This validates three things at once: that the data is genuinely there, that somebody knows how to retrieve it, and that the retrieval completes within a period you could defend under a production order. Record the result.

That third one takes twenty minutes a quarter and is the only evidence that the architecture works rather than merely existing on a diagram. Organisations that skip it routinely discover, under real pressure, that the archive tier was configured but the retrieval path was never tested and the person who set it up has left.

What to do this month#

Start with measurement rather than procurement. Establish your daily log volume by source, your current retention per tier, and the actual storage region of each SaaS product. That data alone usually reveals that the compliant design costs far less than the quote sitting on the desk — and it tells you which two or three sources account for most of the volume, which is where any optimisation should start.

Expect the volume profile to be lopsided. In most estates, network flow and endpoint telemetry account for the large majority of ingested bytes while contributing least per byte to an investigation. Tiering those two aggressively, and keeping application and identity logs hot for longer, generally produces both a cheaper and a more useful estate than treating every source identically.

Our Cyber Security Advisory practice designs these estates, and the CERT-In framework page sets out the full obligation set including the six-hour reporting window and the subscriber record requirements.