CERT-In Direction 20(3)/2022 requires every organisation in India to enable logs across all ICT systems and hold them for a rolling 180 days. A detection-tuned SIEM doesn’t cover it — it filters most of the estate out at the collection layer, by design. Retention and detection are different jobs with different volumes.
CERT-In Direction No. 20(3)/2022, issued on 28 April 2022 under section 70B(6) of the Information Technology Act 2000, applies to every body corporate operating in India, banks included. Direction (iv) reads:
“All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days. These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In.”
There are two obligations in that sentence, and they’re often collapsed into one. The first is enablement — logging turned on across all ICT systems, at source. The second is retention — those logs held for a rolling 180 days and produced on demand.
Most organisations can evidence retention. They can show you a store and a 180-day window. Enablement — whether logging is actually on across the whole estate — is the obligation that rarely gets assessed, and it’s the one that fails quietly.
A SIEM is a detection platform. Its capacity planning, licensing and scaling all rest on one assumption: ingest the events with security value, exclude the rest. For detection, that’s correct practice.
The effect is that general application logs, web service logs, routine transaction records and high-volume system events get filtered at the collection layer, before they ever reach the SIEM. That filtering is deliberate, and it’s usually a licensing decision rather than a technical one.
CERT-In’s requirement is scoped to the full log estate — including the categories a SIEM is built to drop. A SIEM answers what warrants investigation. Direction (iv) answers a different question: what record exists of what occurred. The same box rarely answers both well.
Question 37 of CERT-In’s FAQs on Cyber Security Directions (May 2022) is explicit:
“The logs that should be maintained depend on the sector that the organisation is in, such as Firewall logs, Intrusion Prevention Systems logs, SIEM logs, web / database / mail / FTP / Proxy server logs, Event logs of critical systems, Application logs, ATM switch logs, SSH logs, VPN logs etc. It may be noted that this list of logs is not exhaustive but has been mentioned to provide flavour of logs to be maintained by the relevant teams.”
Ten categories are named. Two are security appliances. The other eight — web, database, mail, FTP and proxy servers, critical-system event logs, application logs and ATM switch logs — come from the operational estate, not the security estate. And CERT-In says the list isn’t exhaustive: you’re directed to work out the additional sources your sector generates. For a bank that reaches core banking, payment switching, digital channels and the databases underneath them.
The same answer closes with a line that undoes standard SIEM tuning:
“From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded.”
Common practice keeps failed and denied events and samples or discards successful ones, because successful events are the bulk of the volume and the smallest share of alerts. That’s a cost control, and it runs against the requirement above.
The distinction decides investigations. Credential-based intrusion produces successful authentications. Misuse by an authorised user produces successful queries. Exfiltration usually shows up as permitted outbound traffic. Failed events tell you an attempt happened; successful events tell you what was reached.
One web page request produces one log entry for the page and another 50 to 100 for static assets — images, stylesheets, scripts, fonts. Detection tooling reads the first and ignores the rest, because the asset requests carry no detection value.
Those entries are still logs generated by ICT systems, and they fall inside Direction (iv). Across the web services, APIs, applications and databases of a typical banking estate, the logs generated run one to two orders of magnitude above the logs a detection-tuned SIEM ingests. Which sets up a fork worth naming plainly. If a security team says the current SIEM already covers the requirement, one of two things is true:
The first puts the compliance position at risk. The second puts the commercial position under review. Both point at the same conclusion — retention and detection are different jobs, and paying detection rates to store everything is rarely the efficient answer to either.
Liability is personal. Section 70B(7) of the IT Act 2000 provides for imprisonment up to one year, a fine up to ₹1 lakh, or both. Section 85 extends liability from the company to individuals — “every person who, at the time the contravention was committed, was in charge of, and was responsible to, the company for the conduct of business of the company” — and section 85(2) reaches any director, manager, secretary or other officer where the contravention is down to their neglect. The defence on offer is proof of all due diligence.
The clock is six hours. Direction (ii) requires cyber incidents to be reported to CERT-In within six hours of being noticed, and Direction (iv) requires the logs alongside that report. Gaps in capture get discovered during incident response, not during a scheduled review.
It’s inside the IS audit. Banks face an annual Information Systems audit. The RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (effective 1 April 2024) governs IS audit and separately requires a log management and retention framework covering system and application logs. CERT-In alignment falls within that scope.
Remediation only runs forwards. You can’t close a logging gap retrospectively. Enabling a source today establishes visibility from today; it writes no record for the prior 180 days.
The assumption that trips up the most careful teams is “our SIEM already covers it.” It’s a reasonable thing to believe — the SIEM holds security logs for well past 180 days, so the box looks ticked. But the SIEM holds the logs it was tuned to ingest, and it was tuned to exclude most of the estate. The retention window is real; the coverage underneath it is a filtered subset. CERT-In’s obligation is enablement across all ICT systems, and that’s the half almost nobody measures.
CERT-In names all three sources. The third question is the one that’s rarely tested — and it’s the one an incident asks first.
Tools hand you a to-do list. We do the list — and run the security behind it. The architecture is the point here: Log Management collects the whole estate — application, web, database, transaction, not a detection-filtered slice — and holds it for the full 180 days at retention economics, not SIEM licensing rates. The SIEM then runs detection on that same data, same schema, same console, so you get investigation and the complete record without paying detection rates to store everything or running two disconnected stores. And because we have delivery infrastructure in India via Rackcorp, the 180 days can sit within Indian jurisdiction. We’re ISO 27001:2022 certified ourselves.
Does our SIEM already satisfy CERT-In's 180-day rule?
Usually not, and it’s rarely checked. A SIEM filters events at the collection layer to keep detection volume and licensing in line, so general application, web and transaction logs are dropped before they land. CERT-In’s scope is the full ICT estate, including the categories a SIEM is configured to exclude.
What exactly does CERT-In want logged?
Question 37 of CERT-In’s FAQ names firewall, IPS, SIEM, web, database, mail, FTP, proxy, critical-system event, application, ATM switch, SSH and VPN logs — and says the list isn’t exhaustive. Eight of the ten categories are operational logs, not security-appliance logs.
Who is personally liable if the logs aren't there?
Liability isn’t limited to the company. Section 85 of the IT Act extends it to any person in charge of the conduct of the business, and section 70B(7) provides for imprisonment up to one year, a fine up to ₹1 lakh, or both. The statutory defence is proof of all due diligence.
Can we backfill the 180 days after enabling a log source?
No. Enabling a source today gives you visibility from today — it doesn’t reconstruct the previous 180 days. The window most relevant to a long-dwell intrusion is exactly the one that can’t be recovered, which is why enablement can’t wait for an incident.
Why not just keep everything in the SIEM?
You can, but you’d be ingesting 50 to 100 times the volume detection needs, at SIEM licensing rates, on data with no detection value. Regulatory retention and security detection are different requirements with different volume profiles; one platform priced for detection is rarely the efficient answer to both.
How does this connect to the RBI IT audit?
The RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (effective 1 April 2024) requires a log management and retention framework covering system and application logs, and mandates an annual IS audit. CERT-In alignment sits inside that audit scope.
