CERT-In directions: what Indian businesses have to do about incident reporting

CERT-In, the national computer emergency response team, issues directions requiring organisations to report specified cyber incidents within a short window and to retain logs. The reporting requirement gets the attention. The log requirement is the one that decides whether you can comply.

Why the reporting window is an engineering problem

The window is short by design. That means the work cannot start when the incident does. If your logs sit on individual machines, are not time-synchronised, and are retained for however long each system defaults to, then reconstructing what happened will take longer than the window allows, regardless of how capable your responders are.

So the useful framing is this: compliance with the reporting requirement is achieved months earlier, by making incidents reconstructable.

The three things to fix first

Centralise logging. Endpoint, server, firewall, identity and cloud logs need to arrive somewhere central. Without that, an investigation means visiting machines, and some of them will be the machines you cannot trust.

Synchronise time. This sounds trivial and repeatedly is not. Logs from systems with drifting clocks cannot be correlated, and a timeline you cannot correlate is not a timeline. Point everything at a reliable time source and check that it took.

Set retention deliberately. Default retention on most systems is far shorter than the obligation. Decide the period, apply it, and confirm it is actually being kept rather than rolling over.

What counts as an incident

The directions specify categories, and they are broader than most businesses assume. It is not only ransomware and data theft. Unauthorised access, defacement, malicious code, identity compromise and attacks on infrastructure all appear. The practical consequence is that you need a decision process rather than a judgement call in the moment.

Write down who decides whether something is reportable, who prepares the report, and who signs it off. Test that the named people are reachable outside office hours, because incidents rarely respect them.

What a report needs

At minimum you will need to describe what happened, when, what was affected, and what you did. Every one of those depends on evidence you either collected or did not. This is why detection matters as much as prevention: an intrusion nobody noticed produces no timeline at all.

The preparation checklist

Centralised logging in place, with the sources you actually care about connected rather than the ones that were easy. Time synchronisation verified. Retention set to the required period and confirmed. An escalation path with named people and out-of-hours contact details. A rehearsed process, run once against a hypothetical incident so the gaps surface on a quiet Tuesday rather than during a real one.

Alerting configured so a compromise is noticed. This is the step most businesses skip, and it makes everything downstream of it theoretical.

Where this overlaps with other work

Almost everything above is also what the DPDP Act needs for breach notification, what a customer security questionnaire asks about, and what a cyber insurance application wants to see. It is genuinely one body of work with several audiences, which is a good argument for doing it properly once.