Skip to main content

Open resource, CC BY 4.0

CERT-In directions readiness checklist

The April 2022 directions turned into checks you can actually run, including the log retention and clock sync duties people miss.

Work through it here

This is the artifact, not a preview of it. Tick items off as you go. Progress is kept in this browser and nothing is sent anywhere, so there is no account and no email step.

0 of 25 checksSaved in this browser only

1Applicability and ownership

2Six hour incident reporting

3Log retention, 180 days, inside India

4Time synchronisation

5Evidence and review

Where the facts come from

Nothing here is our opinion dressed up as a rule. Every line traces back to a published source, cited so you can check it.

  • CERT-In Direction 20(3)/2022 dated 28 April 2022
  • The CERT-In FAQ issued 18 May 2022

What people use it for

Checking whether you could actually meet the six hour window today, rather than assuming you could.

Licence

Published under Creative Commons Attribution 4.0. Copy it, cut it about, put it in your own audit pack, sell the work you do with it. Credit Threatsys and you are within the licence. There is no email gate and there never will be.

What the six hours actually starts from

The clock runs from noticing, not from the breach. That distinction does more work than anything else in the Directions. An intrusion that began in March and was noticed in July gives you six hours from July.

The complication is that noticing is rarely one moment. An analyst sees an odd authentication pattern at 21:40. A second correlates it with an outbound transfer at 23:15. Somebody says the word incident at 01:00. In our experience the defensible answer is the first, and organisations that argue for the third in a post-incident review have a bad time.

Build your process around the earliest defensible moment and you never have to make that argument.

What counts as reportable, including the quiet entries

The Directions list twenty categories, and people fixate on the dramatic ones: ransomware, data breach, defacement. The ones that catch organisations out are the quiet entries.

Unauthorised access to social media accounts. Attacks on IoT devices. Malicious code in an application. Identity theft, phishing and fake mobile applications affecting your users.

If you run a consumer platform, a credential stuffing campaign against your login endpoint is reportable. Most teams treat it as noise, because from inside a SOC it looks like noise. That is a compliance failure sitting in an alert queue right now.

The practical fix is to translate the categories into your own alert vocabulary in advance, so a triaging analyst at 02:00 can recognise a reportable event without reading the law.

The logs requirement, where audits actually fail

180 days of logs, maintained within India, produced when CERT-In asks. This clause fails more audits than the reporting one.

Coverage is the first problem. Many organisations hold 180 days of firewall logs and thirty days of the application logs anyone would actually need to reconstruct an intrusion. Retention against the wrong systems is expensive and useless.

Location is the second. If the retention lives in a cloud region outside India, you are not compliant regardless of how good the logs are. This is a configuration change rather than a purchase, and it is regularly the cheapest finding to close on the whole list.

Service providers carry additional duties. Data centre, VPS, cloud and VPN providers hold customer records for five years after the customer leaves. Virtual asset service providers carry KYC and transaction record duties.

What a working capability looks like

Four things, and none of them are technology.

A named decision maker with a named deputy, both reachable out of hours, both authorised to say this is reportable without convening anybody. If that decision needs three people on a call, you will not make six hours.

A pre-written template with the fields CERT-In asks for, held somewhere reachable when your own systems may be the thing compromised. We have watched an organisation lose ninety minutes because the plan was on the file server that had just been encrypted.

A triage rule in your own vocabulary. Any confirmed unauthorised access to a production database is a rule an analyst can apply at 02:00. Data breach is not.

One rehearsal a year where somebody is actually woken up. The failure modes only appear when people are tired and the on-call rota is wrong.

Not sure where to start?

Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.