CERT-In’s 180-day logs and clock sync: what your network has to do

Three short rules with a lot behind them

On 28 April 2022 CERT-In, India’s national cyber incident response agency, issued Directions under section 70B(6) of the IT Act. They apply to service providers, intermediaries, data centres, body corporates and government organisations, and they took effect 60 days after issue. As of October 2026 they are still in force.

Three of the Directions shape how an IT estate is built:

• Synchronise the clocks of all ICT systems to the NTP servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), or to servers traceable to them.
• Report the incident types listed in the Directions’ Annexure I to CERT-In within six hours of noticing them.
• Enable logs on all ICT systems and keep them securely for a rolling 180 days, within Indian jurisdiction, ready to hand to CERT-In with an incident report or when asked.

Each sentence is short. Meeting it across firewalls, branch routers, servers, cloud accounts and SaaS platforms is an engineering project, and the three depend on each other.

Why the clocks come first

An investigation is a story told in timestamps. A login on the VPN, a new administrator in the directory, a burst of file reads, a large upload through the firewall: put in order, those four lines describe an intrusion. Out of order, they describe nothing anyone can act on.

Clocks drift. A device that has lost its time source, or never had one, can be minutes out within weeks. Move one system’s clock in the example below and watch the story change.

This is why time sync sits at the top of the Directions. Logs from systems that disagree about the time cannot be correlated with confidence, and an investigation built on them can reach the wrong conclusion.

A time design that holds up

1. Run your own internal time serversPoint two or three internal NTP servers at the NIC and NPL servers, using the server names those bodies publish, and point every device at your internal servers. Hundreds of devices then depend on a few well-watched sources, not on the internet.
2. Cover every class of deviceFirewalls, switches, routers, SD-WAN edges, wireless controllers, hypervisors, servers, storage and security appliances all keep their own clocks. Configure each one, including the out-of-band management network.
3. Check the cloud separatelyCloud virtual machines usually take time from the provider’s own service. The Directions let organisations spread across geographies use another accurate source that does not deviate from NIC and NPL; confirm with your compliance team how that applies to your cloud estate.
4. Log in a single, explicit time zoneRecord timestamps with their offset, or in UTC, and keep one convention across the estate. A mix of local times and UTC is a second source of disorder.
5. Watch for driftMonitor each device’s offset from your time servers and alert when it passes a threshold you set. A clock that quietly fails is only discovered during the incident that needed it.

180 days of logs, kept in India

The Directions say all ICT systems. In practice that means the systems that see who connected, what changed and what moved: perimeter and branch firewalls, VPN gateways, routers and SD-WAN edges, DNS and DHCP, the directory and identity provider, servers and hypervisors, email, endpoint security, and the audit logs of cloud and SaaS platforms.

Device-local storage rarely holds 180 days and disappears with the device. The workable pattern is central collection:

• Forward logs from every system to a central collector or SIEM hosted in India, whether on-premises or in an Indian cloud region.
• Check SaaS and cloud platforms: many keep audit logs for a shorter period, or store them outside India by default, so export them to your own store.
• Protect the store as evidence. Use separate administrator credentials, restrict deletion, and keep a write-once or immutable copy, so an attacker who reaches the network cannot erase their tracks.
• Set retention to delete on schedule after 180 days, or after any longer period your other obligations require, and record the setting.
• Size the storage from real volumes. Measure a week of logs from each system and project it forward, with headroom for the busy periods when incidents tend to happen.

Six hours starts before the incident

Six hours from noticing an incident is not long. In that window a team has to confirm what happened, decide that it is reportable and send the report, often at night.

That is only possible when the groundwork exists: logs already central and searchable, clocks already agreeing, a named Point of Contact registered with CERT-In as the Directions require, and a short runbook that says who decides and who sends. The Directions list CERT-In’s email, phone and fax channels for reports; keep them in the runbook so nobody has to search for them during an incident.

Six hours is not enough time to start collecting logs. It is enough time to read logs you already have.

A short readiness check

• Do you have an inventory of every ICT system that produces logs, including cloud and SaaS?
• Does every system take time from your internal servers, and are those synced to NIC or NPL?
• Is someone alerted when a device’s clock drifts?
• Do logs from every system reach a central store in India, and can you search 180 days back today?
• Could an administrator account on the production network delete those logs?
• Is your CERT-In Point of Contact registered and current, and does the runbook name who reports?

A ‘no’ anywhere is the place to start.