CERT-In Log Retention and Backup: What Indian Businesses Need to Keep

Most conversations about CERT-In compliance start in the wrong place — with a scramble for a document to show an auditor. The directions issued in April 2022 are not really a paperwork exercise. They ask for two operational things: that you can tell someone quickly when an incident happens, and that you still have the records to explain what happened afterwards. Both of those depend on infrastructure decisions you either made years ago or have not made yet.

What the directions actually ask for

The Indian Computer Emergency Response Team issued its directions in April 2022 under section 70B(6) of the Information Technology Act, 2000. They apply broadly — service providers, intermediaries, data centres, body corporates and government organisations. The obligations most businesses need to plan around are:

• Report specified incidents within six hours of noticing them or being told about them. Six hours is not long enough to first work out who is responsible for reporting.
• Enable logs on all ICT systems and retain them for a rolling 180 days, maintained securely and within Indian jurisdiction.
• Synchronise system clocks to NTP servers operated by NIC or NPL, or to servers traceable to them.
• Designate a point of contact for CERT-In correspondence.
• Data centre, VPS, cloud and VPN service providers additionally hold subscriber and customer records for five years.

Read that list as an operations checklist rather than a legal one. Every item fails in the same way: nobody owns it, so nobody notices it has stopped working.

The 180-day log requirement is not your backup

This is the most common misreading we correct. Logs and backups answer different questions. A backup answers "can we get the data back". Logs answer "what happened, in what order, and to which account". You can have a perfect backup and still be unable to explain an incident, which is exactly the position that makes a six-hour report impossible to write honestly.

They do overlap in one important way, though. If your logs live only on the machine that generated them, an attacker who reaches that machine can clear them — and clearing logs is standard practice, not an exotic technique. Log retention that survives the incident it is supposed to document has to be a copy somewhere the compromised system cannot reach. That is the same architectural requirement as an off-site backup copy, and in practice it is solved with the same thinking.

Where offices usually fall short

When we audit an environment against this, the gaps are consistent:

• Logs are on by default but rotate long before 180 days. Windows Event Log and most network devices overwrite the oldest entries once the file hits a size limit. On a busy firewall that can be days, not months.
• Nothing is centralised. Logs exist on twelve devices and no one place, so reconstructing a timeline means twelve separate exports under time pressure.
• Clocks disagree. Without synchronisation, correlating events across systems produces a timeline that cannot be defended. This is why the NTP clause is in the directions at all.
• Retention is on the same box as production. If ransomware reaches the server, it reaches the evidence.
• Nobody is named. There is no designated contact, so the six-hour clock is spent deciding who makes the call.

What "maintained securely" implies in practice

The directions do not prescribe a product, which is deliberate — but the intent is clear enough to design against. In practice it means centralised collection so logs leave the device that produced them, retention that genuinely covers 180 days rather than nominally being enabled, storage inside India if that is a requirement for your data, access control so logs cannot be quietly edited, and monitoring of the collection itself so a silent failure is noticed in days rather than during an investigation.

The last one is the most frequently skipped. A log collector that stopped six weeks ago looks exactly like a working one until you go looking.

How this connects to the DPDP Act

The Digital Personal Data Protection Act, 2023 pushes in the same direction from a different angle. It places obligations on organisations handling personal data to apply reasonable security safeguards and to notify breaches. You cannot notify a breach you cannot describe, and you cannot describe one without records. The practical consequence is that the log and backup work you do for CERT-In is most of the groundwork for DPDP as well — which is a better argument for funding it than either regulation makes on its own.

Because obligations and timelines under both frameworks continue to be clarified, confirm the current position for your specific organisation with your legal or compliance advisor rather than treating this article as a compliance opinion.

A reasonable order to tackle it

1. Name the point of contact, and make sure that person knows they hold it.
2. Synchronise clocks across servers, firewalls and switches to a traceable source.
3. Work out what your current log retention actually is, per device. Measure it, do not assume it.
4. Centralise collection so logs leave the device, then confirm 180 days is genuinely covered.
5. Get retention off the production estate, so an incident cannot delete its own evidence.
6. Write down the six-hour reporting steps while nothing is on fire.
7. Test a restore, so the backup half of the story is proven and not assumed.

None of this is expensive relative to what it protects. It is mostly unglamorous configuration that has never been anyone's specific job.

Where Decoding IT fits

We design and run this for businesses across Delhi NCR from our Gurugram office — centralised logging with retention that holds, clock synchronisation, off-estate copies, and documented restore tests you can show an auditor or a customer. It usually sits alongside our data backup services in Gurugram, because the two problems share an architecture and it is wasteful to solve them twice. If you would rather someone else carried the monitoring and the evidence trail day to day, that is in scope on GigaExtend.

If you are not sure where your logs currently stand, that is a short assessment rather than a project. Talk to our Gurugram team and we will tell you what you actually have.