By Xhield Team · May 10, 2026 · 10 min read
Tags: CERT-In Log Retention Compliance Enterprise Security India Cybersecurity VAPT Audit Readiness CISO
Here's a situation that plays out more often than anyone wants to admit.
A CISO at a mid-sized Indian fintech gets a call from their compliance team. CERT-In has flagged them following a breach investigation at a partner organisation. Auditors want 180 days of logs from all ICT systems. The CISO turns to their IT team. The response: "We have logs from the main application servers. The staging environment logs rolled over after 30 days. The cloud instances the dev team was using — we're not sure those were logging at all."
The breach didn't even originate from their systems. But the audit exposure? Very real.
This is not an edge case. It's the default state for most Indian enterprises right now — and CERT-In's 180-day log retention rule is the compliance requirement most likely to catch organisations off-guard.
What the Rule Actually Says
CERT-In's directions, issued April 2022 and enforceable since June 2022, require all service providers, intermediaries, data centres, body corporates, and government organisations to:
"mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days within Indian jurisdiction."
Five words carry most of the weight here: "all their ICT systems."
Not your production servers. Not your managed infrastructure. All of it.
That includes cloud instances, containerised workloads, network devices, endpoints, SaaS platforms your teams are using, third-party integrations, and — critically — anything that touches your organisation's data or network, whether IT formally manages it or not.
The Gap Nobody Talks About
If you ask most IT managers whether they're logging, the answer is yes. And they're right — for the systems they know about.
The problem is the systems they don't know about.
We covered Shadow IT in detail in a previous post, but it's worth revisiting here through a compliance lens. Every unmanaged asset — the developer's AWS instance, the forgotten subdomain, the SaaS tool a team adopted without IT approval — is almost certainly not logging in any way that satisfies CERT-In.
And here's where it gets uncomfortable: the 180-day log requirement applies to your actual operational environment, not just the systems on your asset register.
If a breach occurs through an unmanaged asset and you have no logs from it, you don't just have a detection gap. You have an evidence gap. You cannot characterise the incident. You cannot meet the 6-hour reporting window with any accuracy. And you cannot demonstrate to auditors that you have complied with the directions.
That's a compounded failure — one security, one compliance.
Why 180 Days Is Harder Than It Sounds
Even for fully managed infrastructure, 180 days of log retention is non-trivial. Here's where enterprises consistently stumble:
1. Default log rotation settings
Most systems, by default, are not configured to retain logs for 180 days. Linux systems often rotate logs every 7–30 days. Cloud provider default logging policies vary — AWS CloudTrail retains 90 days of event history by default. Azure Monitor's default retention is 31 days. Without explicit configuration, logs are gone long before the 180-day requirement is met.
2. Cost-driven log deletion
Storage isn't free. Organisations that centralise logs in SIEM platforms often implement aggressive retention policies to control costs — 30 days, 60 days, 90 days. Nobody went back and updated those policies when CERT-In came into effect. The result is technically non-compliant infrastructure that looks compliant on paper because no one has done the audit.
3. The "log it somewhere" fallacy
Many organisations believe that because logs exist somewhere, they're compliant. But CERT-In requires logs to be retained within Indian jurisdiction. If your log aggregation pipeline is sending data to a US-based SIEM instance — even temporarily — you have a jurisdictional compliance issue, not just a retention one.
4. Ephemeral workloads
Containerised environments, serverless functions, and auto-scaling groups create workloads that spin up and spin down in minutes. If you're not explicitly shipping logs from ephemeral workloads to a persistent store before they terminate, those logs are gone. Permanently.
5. Third-party and SaaS platforms
Your teams are using Slack, Notion, Jira, GitHub, and dozens of other SaaS tools. Each of those platforms generates logs relevant to your organisation's security posture. Whether those logs are accessible, whether they can be exported, and whether they're retained for 180 days is almost entirely dependent on your subscription tier — not your internal policy.
Enterprise plans on most SaaS platforms provide audit log access. Standard and free tiers typically don't — or provide only 30–90 days. If your organisation is on a free or mid-tier plan for any business-critical SaaS tool, assume you have a log retention gap.
What an Auditor Will Actually Look For
CERT-In auditors — empanelled under the CERT-In guidelines — are not just checking whether a log retention policy document exists. They're checking whether logs actually exist.
Specifically, expect scrutiny on:
Coverage — Can you demonstrate that every ICT system is generating logs? Auditors will ask for a list of systems and cross-reference it against evidence of active logging. Any gaps in coverage are findings.
Retention period — Can you produce logs from 180 days ago for a given system? Not "our policy says 180 days" — the actual logs. Organisations that discover their SIEM was rolling over logs at 90 days only find out during this exercise.
Integrity — Are logs tamper-evident? CERT-In's directions emphasise secure storage. Logs that can be modified by an administrator without an audit trail are a concern.
Jurisdictional compliance — Are logs stored within India? If you're using a global SIEM solution, where is the data physically sitting? This is increasingly a focus area as auditors become more technically sophisticated.
Incident correlation — In the event of a breach, can you reconstruct what happened using your logs? A 180-day retention policy that produces logs nobody knows how to query is a compliance box-tick, not a security capability.
The CERT-In Audit Readiness Gap for Indian Enterprises
Let's be specific about where most organisations sit right now.
Large enterprises — banks, telcos, large IT services firms — have generally invested in SIEM infrastructure and have some form of log management. Their gaps tend to be coverage (Shadow IT, cloud sprawl) and jurisdiction (global SIEM deployments).
Mid-sized enterprises — the sweet spot of India's digital economy — are frequently in a more precarious position. They've grown quickly, adopted cloud infrastructure and SaaS tools rapidly, and often have IT teams that are stretched thin managing operations. Log retention policy, if it exists at all, was often set years ago and hasn't been revisited. These organisations are at the highest risk of a significant audit finding.
MSMEs — now subject to mandatory annual audits from September 2025 — are largely starting from zero. Many don't have centralised logging at all. For them, CERT-In compliance isn't a gap to close, it's an infrastructure to build.
What Actually Fixes This
The good news is that this is a solvable problem — but it requires treating log retention as an infrastructure problem, not a policy problem.
Start with discovery, not configuration. Before you can ensure you're logging everything, you need to know what everything is. Run an external attack surface assessment to identify all assets operating under your organisation's domain, IP ranges, and ASN. The delta between that list and your official asset register is your logging coverage gap.
Audit your current retention settings. Pull the actual retention configuration from your SIEM, your cloud logging services (CloudTrail, Azure Monitor, GCP Cloud Logging), and your on-premise log management. Not the policy document — the actual settings. You will almost certainly find mismatches.
Fix default configurations. Explicitly configure 180-day retention across all logging infrastructure. In AWS, this means CloudTrail log file validation and an S3 lifecycle policy set to 180+ days. In Azure, it means adjusting the Log Analytics workspace retention setting. This is a configuration change, not a project — it takes hours, not weeks.
Instrument ephemeral workloads. Implement log shipping from containers and serverless functions to a persistent log store before they terminate. In Kubernetes environments, a centralised logging agent (Fluentd, Fluent Bit) deployed as a DaemonSet is the standard approach.
Resolve your SaaS audit log coverage. Audit which SaaS platforms your organisation uses, what tier you're on, and what log access that provides. For business-critical platforms, the upgrade cost to get audit log access is almost certainly less than the compliance exposure.
Ensure Indian jurisdiction. If you're using a global SIEM or log management platform, verify that Indian data is being stored in an Indian region. Most major providers — AWS, Azure, Google Cloud — have Indian regions. This is a configuration and data routing decision, not a vendor change.
The Harder Conversation
Here's what the 180-day log retention rule is really about, underneath the compliance language.
CERT-In's directions were written in response to a real pattern: Indian organisations were experiencing breaches and couldn't reconstruct what happened, couldn't identify the scope of compromise, and couldn't notify affected parties accurately — because they simply didn't have the evidence.
The log retention requirement is an attempt to ensure that when a breach occurs, organisations have the raw material to understand it. The 6-hour reporting window assumes you can characterise an incident quickly. You cannot characterise an incident quickly if you don't have logs.
This means compliance and security capability are actually the same thing here. Organisations that genuinely meet the log retention requirement — real 180-day coverage, across their actual attack surface, stored securely in-jurisdiction — are also organisations that are genuinely better positioned to detect, investigate, and respond to incidents.
The ones who will fail an audit are usually also the ones who would struggle most in the event of an actual breach. The audit is revealing a real gap, not creating a bureaucratic one.
A Simple Audit Readiness Check
Before your next empanelled audit, run through these five questions honestly:
- Do I have a complete, up-to-date list of every ICT system my organisation operates — including cloud, SaaS, and Shadow IT?
- For each system on that list, am I actively generating and shipping logs to a central store?
- Are those logs retained for a minimum of 180 days — not by policy, but by verified configuration?
- Is all log data stored within Indian jurisdiction?
- If a breach occurred six months ago through an asset I didn't know existed, would I have the logs to reconstruct what happened?
If the answer to any of these is "I don't know" or "no" — you have work to do before an auditor asks the same questions.
Where Xhield Fits In
The first and most foundational step — knowing what you actually have — is where most organisations get stuck. You can't instrument what you don't know exists.
At xhield.tech, we build continuous attack surface intelligence that gives you an external view of your organisation's actual footprint — every subdomain, cloud asset, and exposed service that responds under your name, whether IT manages it or not. That visibility is the starting point for real CERT-In log coverage.
If you're preparing for an audit or trying to understand how your actual attack surface compares to your asset register, let's talk.
Related reading: