Can You Actually Report a Cyber Incident in Six Hours?

The CERT-In directions issued in 2022 introduced a requirement that reads, at first glance, like a paperwork problem: certain cyber incidents must be reported within six hours of being noticed.

Teams read that, note it, and move on. Then something happens on a Saturday evening, and they discover that six hours is not a paperwork problem at all. It is a test of whether four different things already existed, and by then it is far too late to build any of them.

This is what those four things are.

What actually has to be reported?

The directions carry an annexure listing the incident types that must be reported. It is broader than most people assume, and worth reading in full rather than from a summary, but the shape of it includes things like:

• Targeted scanning and probing of critical systems
• Unauthorised access to systems or data
• Compromise of critical systems or information
• Defacement of a website, or intrusions into a website
• Malicious code attacks, including ransomware
• Attacks on servers such as database, mail and DNS, and on network devices
• Identity theft, spoofing and phishing attacks
• Denial of service and distributed denial of service attacks
• Attacks on applications, on IoT devices, and on cloud, big data and blockchain systems
• Data breach and data leak

Two things follow from that list.

Reportable is a wider net than damaging. Targeted scanning is on the list. A great deal of what your systems experience daily is untargeted internet noise, and telling the difference is a judgement call somebody has to be equipped to make quickly.

The list is not only about breaches. A denial of service attempt, a defacement, a phishing campaign using your brand: these are all in scope and none of them look like the classic incident people prepare for.

When does the six hours start?

On noticing. Not on confirming, not on understanding, and not on containing.

That distinction is the whole difficulty. The instinct of every good engineer is to find out what happened before telling anyone, and that instinct is directly at odds with a clock that started when the first person saw something odd.

Two practical consequences:

An initial report is not a full report. You are not expected to have finished the forensics. You are expected to have reported. Waiting for certainty is the most common way this deadline gets missed, and it is missed by careful people rather than careless ones.

Noticing has to be recorded. If nobody wrote down when the alert fired or when the customer email arrived, then the start of the window is a matter of memory. Your incident channel timestamps are the record, which is a good reason for the first action to be opening one.

What else do the directions require, beyond reporting?

This is the half that gets skipped, and the half that is quietly load-bearing when an incident actually happens.

Synchronised clocks

ICT system clocks are expected to be synchronised to the Network Time Protocol servers of NIC or NPL, or to servers traceable to them.

This sounds like an administrative detail and it is not. When you are reconstructing a sequence across an application server, a load balancer, a database and a WAF, and the clocks disagree by ninety seconds, the order of events becomes an argument rather than a fact. Everything you say in the report rests on that ordering.

Logs kept for 180 days, within India

The expectation is a rolling 180 days of logs, maintained securely and held within Indian jurisdiction.

Two failure modes we see regularly. Retention set to thirty days because that is the default and nobody revisited it, which means an incident discovered in month three has no evidence behind it. And logs shipped to an aggregator that processes outside India, which collides with the jurisdiction expectation and with the data localisation question at the same time.

Check both numbers, in every log destination, not just the main one.

A named point of contact

Somebody has to be designated, and their details kept current with CERT-In. This is five minutes of work that goes undone for years, and the moment it matters is the moment nobody has time to sort it out.

Records held by service providers

Data centres, virtual private server providers, cloud providers and VPN providers carry their own obligations around customer registration records and retention. If you operate any of those, or you resell them, that duty is yours as well as your provider's.

Why is six hours hard in practice?

Not because six hours is short. Because of what has to happen inside it.

Somebody has to notice. If your alerting is noisy, the signal is already buried. A team that has learned to ignore its alerts has effectively extended its detection time to whenever a customer complains, which can be days. Alert quality is an incident response control, not a comfort feature.

Somebody has to decide it is reportable. At 11pm on a Saturday, the engineer looking at it needs to know whether this is one of the listed types and whether they are allowed to escalate without waking three people first. If that decision has no owner, it defaults to nobody, and nobody is slow.

Somebody has to write it. Which systems, which data, when it started, what has been done. If that means logging into four consoles and correlating by hand, six hours evaporates. If it means opening a runbook that says where each answer lives, it does not.

Somebody has to submit it. Through the correct channel, with the right contact details, from a person who has done it before or at least read how.

Four steps, four different people in most organisations, on a weekend. That is the actual problem.

What has to exist beforehand?

Short list. All of it is cheap before an incident and impossible during one.

A written trigger. A page that says: if you see any of these, this is potentially reportable, escalate now rather than investigating first. Attach the annexure list. Do not make an engineer interpret a regulation at midnight.

A named decider with a deputy. One person who declares an incident reportable, and one who does it when the first is unreachable. Named, with phone numbers, in a document people can find without VPN access, because the incident might be the VPN.

A pre-filled report template. Everything that is always true about your organisation already filled in. What varies is the incident. Assembling the fixed parts under pressure is wasted time.

A log map. One page: what is logged, where it lives, how long it is kept, and how to search it. This is the document that turns four hours of console archaeology into twenty minutes.

The contact details, verified. Someone should confirm annually that the registered point of contact is a person who still works there.

How do you know any of this works?

You rehearse it, and the rehearsal does not need to be elaborate.

Pick a scenario from the annexure. Unauthorised access to a database, say. Set a timer. Then, without touching production, answer in order:

1. How would we have noticed? Which alert, and does it currently fire?
2. Who declares this reportable, and can we reach them right now?
3. Which logs tell us what happened, and are they still within retention?
4. Can we state which systems and which data were involved?
5. Who submits, and do they have the credentials to do it?

Most teams stop at question three the first time. That is the point of the exercise: it finds the gap on a Tuesday afternoon rather than during an incident, and every gap it finds is cheap to close from here.

Run it once a quarter. It takes an hour and it is the only way to know whether the plan is a plan or a document.

What does this have to do with how you build?

More than it looks, and this is where the compliance requirement and the engineering practice stop being separate conversations.

Every question in that rehearsal is answered by something you either built in or did not. Retention was configured or it was left at the default. Clocks were synchronised or they drifted. Logs went to a place you control or to a vendor you have not checked. Alerts were tuned or they were ignored.

None of those decisions were made during an incident. They were made during ordinary work, mostly by accident, and the incident is when you find out what was chosen. That is the argument for treating the security posture as part of the build rather than as a review that happens afterwards.

The short version

Six hours is not a writing deadline. It is a test of whether you can notice, decide, reconstruct and submit, and only the last of those four is paperwork.

Build the trigger, name the decider, map the logs, fix the retention, check the clocks. Then rehearse it once and find out which of the five you got wrong, while finding out is free.

This is engineering guidance, not legal advice. The directions and their annexures are amended over time; read the current text and take your compliance position from counsel. What is stable is that the preparation has to exist before the clock starts, which is what this post is about.