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 does not cover it, because it filters most of the estate out at the collection layer by design. Retention and detection are different requirements with different volume profiles.
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.”
That sentence contains two obligations. 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, by showing a store and a 180-day window. Enablement — whether logging is on across the whole estate — is the obligation that is rarely assessed, and it fails without producing a symptom.
A SIEM is a detection platform. Its capacity planning, licensing and scaling rest on one assumption: ingest the events with security value and exclude the rest. For detection, that is correct practice.
The consequence is that general application logs, web service logs, routine transaction records and high-volume system events are filtered at the collection layer before reaching the SIEM. That filtering is deliberate, and it is 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 establishes what warrants investigation. Direction (iv) requires a record of what occurred. One platform rarely serves both requirements efficiently.
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 remaining eight — web, database, mail, FTP and proxy servers, critical-system event logs, application logs and ATM switch logs — come from the operational estate. CERT-In also states that the list is not exhaustive, which places the additional sector-specific sources within scope. For a bank that reaches core banking, payment switching, digital channels and the databases underneath them.
The same answer closes with a line that runs against standard SIEM tuning:
“From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded.”
Common practice retains failed and denied events and samples or discards successful ones, because successful events carry the bulk of the volume and the smallest share of alerts. Sampling successful events is a cost control, and it conflicts with the requirement above.
The distinction determines investigations. Credential-based intrusion produces successful authentications. Misuse by an authorised user produces successful queries. Exfiltration usually appears as permitted outbound traffic. Failed events establish that an attempt occurred; successful events establish 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 logs generated by ICT systems and 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. Where a security team states that the current SIEM already covers the requirement, one of two things is the case:
The first puts the compliance position at risk. The second puts the commercial position under review. Both lead to the same conclusion: retention and detection are different requirements, and detection-rate storage of everything serves neither efficiently.
Liability extends to individuals. 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 results from their neglect. The available defence is proof of all due diligence.
The reporting window 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 surface during incident response rather than during a scheduled review.
It sits 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. A logging gap cannot be closed retrospectively. Enabling a source establishes visibility from that point and writes no record for the prior 180 days.
A SIEM holding security logs well past 180 days makes the requirement appear satisfied. The SIEM holds the logs it was tuned to ingest, and that tuning excludes most of the estate. The retention window is real and the coverage beneath it is a filtered subset.
CERT-In’s obligation is enablement across all ICT systems, which is the half that is rarely measured.
CERT-In names all three sources. The third is rarely tested in advance and is the first one an incident requires.
Secure60 operates the retention and the detection on one architecture. Log Management collects the whole estate — application, web, database, transaction, rather than a detection-filtered slice — and holds it for the full 180 days at retention economics rather than SIEM licensing rates. The SIEM then runs detection on that same data, in the same schema and the same console, which produces both investigation capability and the complete record without paying detection rates for storage or operating two disconnected stores. Our delivery infrastructure in India via Rackcorp means the 180 days can sit within Indian jurisdiction. Secure60 holds ISO 27001:2022 certification.
Does our SIEM already satisfy CERT-In's 180-day rule?
Usually not, and the coverage is rarely measured. A SIEM filters events at the collection layer to keep detection volume and licensing within budget, 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 does CERT-In require to be 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 states that the list is not exhaustive. Eight of the ten categories are operational logs rather than security-appliance logs.
Who is personally liable if the logs aren't there?
Liability is not 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 produces visibility from that point forward and does not reconstruct the previous 180 days. The window most relevant to a long-dwell intrusion is the one that cannot be recovered, which is why enablement precedes the incident.
Why not keep everything in the SIEM?
It is possible, at 50 to 100 times the volume detection requires, at SIEM licensing rates, on data with no detection value. Regulatory retention and security detection are different requirements with different volume profiles, and 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.
