When we assess organisations against the CERT-In Directions, we rarely find that the company ignored them completely. What we find instead is a pattern of small, understandable gaps. Each looks minor on its own. Together they leave the company unable to show that it is compliant, and, more importantly, unable to investigate an incident properly when one happens.

Here are the five gaps we encounter most often, why they matter, and how to close them without a large project.

Gap 1: Log retention that is partial or unverified

The Directions require logs of all ICT systems to be enabled and retained for a rolling 180 days, within Indian jurisdiction. Most organisations believe they comply. When we ask to see the evidence, the picture changes.

Typical findings include firewall logs retained for 30 days because of storage cost, application logs that exist only on the server and are overwritten when the disk fills, cloud audit trails left on default retention, and SaaS tools whose logs are never exported.

How to close it: Build a log source register listing every system, the type of log, where it is stored, how long it is kept, and who owns it. Centralise logs into a SIEM or a low-cost log archive. Use tiered storage so that older logs go to cheaper storage but remain retrievable. Verify the storage location is within India. Then test: pick a random system and ask the team to retrieve a log entry from 150 days ago.

Gap 2: Time synchronisation that is inconsistent

The Directions require clocks to be synchronised with the NTP servers of the National Informatics Centre or National Physical Laboratory, or with sources traceable to them. In many environments, servers point at different public time sources, network devices are never configured, and cloud instances use provider defaults.

This sounds trivial, but during an investigation a five-minute drift between systems can make an attack timeline impossible to reconstruct.

How to close it: Choose one authoritative time configuration. Push it through configuration management to servers, network equipment, appliances and cloud images. Record the source in your standards. Add a periodic check to your compliance monitoring that flags devices out of tolerance.

Gap 3: Incident reporting with no operational workflow

The six-hour reporting requirement is the best-known part of the Directions, but the gap is rarely knowledge. It is process. Companies have a policy sentence saying that incidents will be reported to CERT-In, with no defined owner, no template and no tested route.

How to close it: Create a one-page reporting procedure. Name the role that decides whether an event is reportable, the role that files, and a backup for each. Prepare a draft report template with the fields CERT-In expects. Record the time at which an incident was first noticed in your ticketing system as a mandatory field, because that timestamp is your proof of timely reporting.

Gap 4: No clear point of contact

The Directions call for a designated point of contact to interact with CERT-In. Some organisations name a person who left the company a year ago. Others name a shared mailbox nobody monitors. During a real incident, CERT-In may need to reach you, and you may need to be reachable around the clock.

How to close it: Designate a primary and an alternate contact, with phone numbers that are actually answered outside office hours. Review the details quarterly and after any organisational change. Put the review on the calendar so it does not rely on memory.

Gap 5: Third parties outside the compliance picture

Your obligations do not stop at your network boundary. Managed service providers, cloud platforms, payment processors and software vendors often hold the logs or detect the events that trigger your reporting duty. Contracts frequently say nothing about how quickly they must tell you, what information they must provide, or where they store logs.

How to close it: Review contracts for your most critical suppliers. Add clauses covering prompt notification, cooperation during investigations, log access and data location. For suppliers that cannot agree, document the risk and consider compensating controls, such as taking logs into your own environment.

Why these gaps persist

There are three common reasons. First, ownership is unclear: IT assumes Security handles it, Security assumes Legal does, and Legal assumes the technical teams are on top of it. Second, the requirements are scattered across a long document and are read once, at launch, then forgotten. Third, there is no recurring test. Nobody checks whether the controls still work six months later.

The fix for all three is the same: assign a named owner, convert each requirement into a specific control with evidence, and review that evidence on a schedule.

A simple evidence pack

An auditor or regulator will not be satisfied by statements alone. Prepare a small evidence pack:

  • The log source register with retention periods and storage locations.
  • Screenshots or exports showing NTP configuration across a sample of systems.
  • The incident reporting procedure and a recent test record.
  • The designated contact details with a review date.
  • Extracts from supplier contracts covering notification and log access.

If you can assemble this in an afternoon, you are in good shape. If it takes two weeks, you have found your priorities.

Take the next step

F9 Infotech runs focused CERT-In gap assessments that test these five areas and produce a short, prioritised remediation list. Request our CERT-In compliance checklist, or ask for a quick review of your current position.

This article is general information, not legal advice. Confirm current requirements with qualified counsel.