The six-hour clock starts before you know anything happened

Organisations usually come to me about CERT-In’s directions expecting a compliance exercise: forms, a portal registration, a policy document. I stop them there. The 2022 directions are an engineering problem first, and the engineering has to be solved months before any incident happens.

The demands: from the moment you notice an incident — not confirm it, not scope it — you have six hours to report it. Logs retained for 180 days, within Indian jurisdiction. Clocks synchronised to NTP so every timestamp agrees. A named point of contact who answers when the regulator calls.

CERT-In compliance consultant — six-hour reporting readiness by Sanjay Seth

Here is the uncomfortable part. You cannot report what you did not detect. If your monitoring is patchy, your “six hours” becomes six hours plus the four days it took someone to notice the breach. That is why, as a CERT-In compliance consultant, I spend most of my time on detection architecture and log pipelines — not on the reporting form. The form takes twenty minutes. The capability to fill it in accurately takes design work.

What the 2022 directions actually demand

CERT-In’s directions of 28 April 2022 are short but dense. Four obligations do most of the damage in practice.

Six-hour incident reporting

Mandatory reporting of specified incidents within six hours of noticing them. The directions list twenty incident types — targeted scanning, unauthorised access, phishing, ransomware, malware, website defacement, data breach, data leak, DDoS, and others. Reports go to CERT-In via email or the incident reporting portal, in a specified format, with follow-up details as they emerge.

180-day log retention, in India

All ICT system logs must be maintained for a rolling period of 180 days, stored within Indian jurisdiction. “Rolling” is the word people miss. On any given day, an auditor or CERT-In itself can ask for logs covering the past 180 days, and the answer has to be yes.

NTP synchronisation

All ICT systems must synchronise their clocks — to NIC’s NTP servers or servers traceable to NPLI. This sounds trivial until you correlate a VPN authentication failure with a database alert and find the timestamps eleven minutes apart. Unsynchronised clocks destroy timelines.

Designated point of contact

You must designate a point of contact to liaise with CERT-In. When an incident is live, CERT-In may request additional information, and someone authorised, informed and reachable has to respond — including outside business hours.

Why the six-hour window is a design problem first

I have built and audited networks since 1993; the pattern in Indian enterprises is consistent. Logging exists, but it is scattered, inconsistent and quietly expiring. Firewall logs rotate off the box in a week. Windows event logs wrap around. Cloud audit trails live in a region nobody chose deliberately.

In that state, six hours is unachievable no matter how good your policy document is. The sequence that works runs the other way:

  • Detection first. Someone — human or machine — must watch centralised, correlated telemetry around the clock, so that “noticing” happens in minutes, not days.
  • Classification second. A triage playbook mapping what you see onto CERT-In’s twenty incident types, so the on-call person is not improvising a legal judgement at 3 a.m.
  • Reporting third. A runbook with the portal details, report format, approval chain and evidence bundle pre-staged, so submission is mechanical.

Only the third item is paperwork. When a company tells me they have “handled CERT-In compliance” because they wrote a policy, I ask: show me the last incident where you went from detection to a submitted report in under six hours. Silence is the usual answer.

Designing the 180-day log retention

This is where most CERT-In audit readiness work happens. Three design questions matter.

What to collect

At minimum: firewall and perimeter logs, VPN and remote-access authentication, DNS queries, DHCP leases, proxy and web-gateway logs, endpoint and EDR telemetry, identity-provider events, email security logs, and audit trails from business-critical applications and databases. My test: could I reconstruct an attacker’s path from initial access to exfiltration using these logs alone? If not, something is missing.

Where to keep it in India

The jurisdiction requirement trips up cloud-first organisations. If your SIEM or log store runs in a foreign region, you are non-compliant. The fix is architectural: pin the log platform and its storage to Indian regions, verify the failover region too, and get the vendor’s data-residency commitment in writing. For on-premises estates, a centralised log server in an Indian data centre works — but size it for 180 days of peak volume, not average.

How to prove 180 days

Auditors do not take your word for it. They ask for retention configuration, a query against logs 170 days old, and alerts for log-source silence. I build a monthly retention check into every engagement: pick a date 90-plus days back, pull the logs, file the output. The proof exists before anyone asks. Tamper-evidence matters too: logs an administrator can silently delete are not evidence.

What auditors and regulators ask for in practice

CERT-In after an incident, or an auditor running a readiness review — the questions cluster predictably:

  • Who is your designated point of contact, and when did you last verify the details work?
  • Show me an incident report you have filed — or your dry-run of one.
  • Pull logs from a date 120 days ago. Right now, in front of me.
  • Show me your NTP configuration and the offset on a sample of systems.
  • Walk me through your last incident from detection to closure, with timestamps.
  • How do you decide which incidents are reportable, and who signs that decision?

Every one of these is answerable if the engineering was done; none from a policy binder. The sanjayseth.com homepage and my background show how I work — hands-on with your engineers, not from a slide deck.

Incident classification: the judgement nobody can automate

The twenty incident types sound precise until a real event lands. Is an employee clicking a credential-phishing link a “phishing attack” or “unauthorised access”? That call has legal consequences, and it often lands at 3 a.m.

My rule, and the one I teach every client: when in doubt, report. An over-report costs thirty minutes. A missed report that CERT-In later learns about costs you credibility, and the directions carry penal provisions under the IT Act. I build a decision tree for each client — grey-zone examples from their own environment, pre-discussed, so the on-call engineer’s call has been made once, calmly, in advance.

How I run a CERT-In readiness engagement

Gap analysis

I map your current state against every clause of the directions: what you log, where it lives, how long it survives, who would notice an incident, and how reporting would happen on a Sunday night. The output is a blunt gap list, ranked by what would fail first.

Log-pipeline design

I architect the collection, centralisation and retention layer — source inventory, storage sizing for 180 days, Indian-jurisdiction placement, integrity controls and the NTP hierarchy. This is where three decades of firewall and network work pays for itself.

Reporting runbook

A short, tested document: the classification decision tree, CERT-In’s channels and report format, the internal approval chain with named deputies, and the evidence-bundle checklist. Short enough to use at 3 a.m., complete enough to satisfy an auditor.

Tabletop drill

We run a simulated incident against the clock — a ransomware detonation on a Friday evening, say — and execute the full chain: detect, classify, draft the report, submit to a mock portal, answer follow-ups. The drill always finds something the documentation missed.

Keeping it running after the consultant leaves

Readiness is perishable. Log sources change, people move roles, retention quietly fills up. The six-hour clock does not care that your SOC analyst resigned in March.

If you want this run for you, my team at PJ Networks does exactly that. Our compliance services keep the CERT-In obligations — retention verification, audit evidence, reporting runbooks — current as your estate evolves, and our 24×7 SOC monitoring in India provides the continuous detection layer that makes six-hour reporting survivable rather than aspirational. The SOC watches; the compliance team proves. You sleep.

Frequently asked questions

Which organisations must comply with CERT-In’s directions?

The directions apply broadly: service providers, intermediaries, data centres, body corporates and government organisations operating in India. In practice, if your organisation runs ICT systems or handles data in India, assume you are in scope. There is no meaningful small-company exemption.

What happens if we miss the six-hour reporting window?

Non-compliance with CERT-In’s directions can attract action under Section 70B of the IT Act, including imprisonment up to one year or a fine. Beyond the legal exposure, a missed or late report damages your standing with the regulator at exactly the moment you may need their assistance with an active incident.

Do our cloud logs need to be stored in India?

Yes. The 180-day retention obligation requires logs to be maintained within Indian jurisdiction. If your cloud or SIEM platform stores logs in a foreign region, you must re-architect to Indian regions — including any failover region — and obtain the vendor’s data-residency commitment in writing.

What logs must be retained for 180 days?

Logs of all ICT systems: firewalls and perimeter devices, VPN and remote access, DNS and DHCP, proxies and web gateways, endpoints, identity and authentication systems, email security, and audit trails of business-critical applications and databases. The practical test is whether you could reconstruct an attacker’s full path through your estate from these logs alone.

Do we need a SIEM to comply?

Not strictly — a well-run centralised log server with proper retention and access controls can satisfy the letter of the directions. But without correlation and alerting, you will not detect incidents fast enough to meet the six-hour window. For any estate beyond a handful of systems, a SIEM or an equivalent managed detection layer is the practical requirement, even if not the legal one.

How long does CERT-In readiness take?

For a mid-sized enterprise with reasonable existing infrastructure, a full readiness engagement — gap analysis, log-pipeline design, runbook and tabletop drill — typically runs six to ten weeks. Building the 180-day retention history itself takes, unavoidably, 180 days, so the earlier the pipeline goes live, the sooner you are fully defensible.

Start before the clock does

The worst moment to design your CERT-In reporting process is during the incident you have to report. If you want an honest assessment of where your estate stands — logs, retention, detection, the lot — book a working session and I will tell you plainly what would survive an audit and what would not. Based in Delhi, working with enterprises across India.