The six-hour clock starts when you notice.
Not when you’re ready.
CERT-In’s 2022 direction requires listed cyber security incidents to be reported within 6 hours of noticing them, or of being brought to notice. Most of that window gets spent assembling facts that could have been captured the moment the incident was detected.
This guide sets out what the direction actually says, the workflow that fits inside six hours, and which parts of it can be automated. The obligation is yours — automation shortens the evidence work; it does not transfer the duty.
Six obligations. One of them has a clock.
Direction No. 20(3)/2022-CERT-In, dated 28 April 2022, issued under sub-section (6) of section 70B of the Information Technology Act, 2000, and effective 60 days after issue. It applies to service providers, intermediaries, data centres, body corporate and Government organisations.
Report within 6 hours
Incidents listed in Annexure I must be reported within 6 hours of noticing them or being brought to notice. Reportable to CERT-In by email (incident@cert-in.org.in), phone (1800-11-4949) or fax (1800-11-6969).
Synchronised clocks
All ICT system clocks must sync to the NTP servers of NIC or NPL, or to servers traceable to them. Estates spanning multiple geographies may use another accurate standard time source, provided it does not deviate from NPL and NIC.
180 days of logs, held in India
Logs of all ICT systems must be enabled and maintained securely for a rolling period of 180 days, within Indian jurisdiction — and provided to CERT-In alongside any incident report, or when directed.
A designated point of contact
A PoC must be designated to interface with CERT-In, submitted in the Annexure II format to info@cert-in.org.in and kept updated. Every CERT-In communication seeking information goes to that contact.
Assistance when directed
On order or direction, entities must provide information or assistance in the format specified — up to and including near real-time — within the timeframe specified. Missing it is treated as non-compliance.
Five-year subscriber records
Data centres, VPS providers, cloud service providers and VPN providers must register and hold validated subscriber details for 5 years. Virtual asset providers hold KYC and transaction records for the same period.
The 20 incident types that must be reported.
If an incident falls in this list, the six-hour clock applies. Note the first entry — targeted scanning or probing of critical networks is reportable, well before anything is breached.
Source: Annexure I, Direction No. 20(3)/2022-CERT-In, 28 April 2022. CERT-In publishes methods and formats for reporting on cert-in.org.in and updates them from time to time — check the current format before filing.
Six hours is not the problem. Reconstruction is.
The window is rarely missed because someone forgot to file. It is missed because the facts a filing needs — when it was noticed, what it touched, what was done — are scattered across teams and consoles, and get assembled by hand under pressure.
What has to happen inside the six hours.
A sequence that fits the window — each step producing the input the next one needs, so that the filing is a review rather than a writing exercise.
Notice, and timestamp it
The moment a signal meets the Annexure I definition, record the time of noticing against an NTP-synced clock. This timestamp is the one the deadline is measured from, so it is the one that has to be defensible.
Classify against Annexure I
Decide whether the incident is one of the 20 reportable types. Targeted scanning of critical systems qualifies — the threshold is lower than most escalation policies assume.
Establish scope and data exposure
Determine affected systems, whether personal data was involved, and which principals are implicated. This is also what a DPDP breach assessment needs, so do it once and use it twice.
Preserve and bundle the evidence
Freeze the relevant slice of the 180-day log store, along with indicators, the timeline and actions taken. The direction requires logs to accompany the report or be produced on direction.
Draft in the current CERT-In format
Populate the published reporting format from the evidence trail rather than from memory. Formats are updated from time to time — pull the current one rather than reusing last year's template.
Approve, file, and log the filing
The accountable officer reviews and approves; the report goes to CERT-In through email, phone or fax, from or via the registered point of contact. Log the submission — the filing is itself evidence of compliance.
Automate the assembly. Keep the judgement.
Everything mechanical about a filing — timestamps, scope, evidence, drafting — is machine work. Everything consequential about it stays with a person who is accountable for it.
Machine: capture
Detection time, affected systems, indicators and actions recorded as they happen, not reconstructed later
Machine: assemble
Evidence bundled from the log store; the report pre-filled in the current published format
Human: verify
The responder confirms the classification, the scope and what the narrative says happened
Human: approve & own
The accountable officer signs off and files. The obligation was never delegable
The evidence trail, kept continuously.
Both products below run on Ritam, MatreComm's AIOps engine, entirely on-premises — which matters here, because the log store the direction requires must stay within Indian jurisdiction.
CraftCompliance
Continuous control monitoring, automated evidence and the incident clock armed at detection.
Explore →CraftSecOps
Detection and triage on the same correlation graph as the network, so scope is established once.
Explore →Continuous compliance
The wider picture — audit-readiness held as a state rather than assembled before an audit.
Explore →Frequently asked questions
What is the CERT-In 6-hour reporting rule?
Direction No. 20(3)/2022-CERT-In, issued on 28 April 2022 under sub-section (6) of section 70B of the Information Technology Act, 2000, requires service providers, intermediaries, data centres, body corporate and Government organisations to report the cyber security incidents listed in its Annexure I to CERT-In within 6 hours of noticing them or of being brought to notice.
When does the 6-hour clock start?
At the point of noticing the incident, or of being brought to notice about it — not at the point of confirming its full scope, and not when remediation finishes. This is why the detection timestamp matters: it is the fact the deadline is measured from, and it needs to come from a synchronised clock rather than someone's recollection.
Which incidents must be reported to CERT-In within 6 hours?
Annexure I lists 20 types, including targeted scanning or probing of critical networks and systems, compromise of critical systems, unauthorised access to IT systems or data, website defacement, malicious code attacks including ransomware, attacks on servers and network devices, phishing and identity theft, DoS and DDoS attacks, attacks on critical infrastructure and SCADA, data breach, data leak, attacks on IoT devices, attacks affecting digital payment systems, fake or malicious mobile apps, unauthorised access to social media accounts, and attacks affecting cloud, big data, blockchain, virtual asset, drone, and artificial intelligence and machine learning systems.
How are incidents reported to CERT-In?
The direction names email (incident@cert-in.org.in), phone (1800-11-4949) and fax (1800-11-6969). CERT-In publishes the methods and formats for reporting on cert-in.org.in and updates them from time to time, so the current published format should be used rather than a stored copy. Separately, a designated point of contact must be registered with CERT-In in the Annexure II format and kept updated.
What log retention does CERT-In require?
Logs of all ICT systems must be enabled and maintained securely for a rolling period of 180 days, and maintained within Indian jurisdiction. They must be provided to CERT-In along with the reporting of any incident, or when ordered or directed.
Can CERT-In incident reporting be automated?
The evidence work can be: capturing the detection timestamp against a synchronised clock, correlating affected systems and data exposure, assembling the log evidence, and pre-filling the current reporting format. The judgement and the accountability cannot — classification, verification and approval remain with the people answerable for them, and the reporting obligation stays with the entity rather than transferring to any platform or vendor.
What happens if an incident is not reported within 6 hours?
The direction states that failure to furnish information, or non-compliance with the direction, may invite punitive action under sub-section (7) of section 70B of the IT Act, 2000, and other laws as applicable.
Arm the clock before you need it.
A scoped PoC on your own estate — evidence collection, the incident clock, and a filing rehearsed against your real systems.
Guidance here summarises the published direction and is not legal advice; confirm current formats and obligations with CERT-In and your counsel.