CERT-In 6-Hour Incident Reporting — How to Comply, Step by Step
CERT-In's Direction No. 20(3)/2022-CERT-In, in force since 28 June 2022, requires covered entities to report specified cyber incidents within 6 hours of becoming aware of them, keep ICT system clocks synchronised to Indian time servers, retain logs for a rolling 180 days within India, and respond to CERT-In information requests within 6 hours. It applies broadly — service providers, intermediaries, data centres and body corporates — and the penalty for most organisations isn't a fine so much as scrambling to build the reporting pipeline for the first time during an actual incident. Here is how to have it ready before that happens.
Steps
Step 1 — Know exactly what must be reported: CERT-In's Annexure A lists specific reportable categories: attacks on servers (mail, database, DNS) and network devices (routers), identity theft/web-jacking/spoofing/phishing attacks, denial-of-service and distributed denial-of-service attacks, attacks on critical infrastructure/SCADA/operational technology systems and wireless networks, and attacks on applications such as e-governance and e-commerce systems. Map this list against your actual systems now, not during an incident — knowing in advance which of your systems fall into a reportable category removes the debate at the worst possible moment.
Print or pin Annexure A's categories somewhere your security team actually references it
Map each category to a specific system or system type in your environment
When in doubt about whether something is reportable, the safer default is to report
Step 2 — Synchronise all ICT system clocks: The Direction mandates synchronising system clocks to the Network Time Protocol servers of NIC or NPL. This sounds minor but is foundational — every downstream requirement (proving when an incident started, correlating logs across systems, demonstrating the 6-hour clock was met) depends on your timestamps actually being accurate and consistent across your entire estate.
Audit which systems are currently synced to what NTP source — assumptions here are usually wrong
Point everything at NIC/NPL NTP servers specifically, not a generic public NTP pool
Re-verify sync periodically — clock drift on unmonitored systems is common
Step 3 — Set up 180-day log retention, stored in India: Logs for ICT systems must be maintained for a rolling 180 days and stored within India — this is where a SIEM (like IBM QRadar) earns its place, since centralising and retaining logs at this scale manually is impractical. Confirm explicitly, in writing if using a cloud-hosted platform, that log storage is physically located in India, not just that the vendor has an India presence.
If using QRadar on Cloud or any SaaS SIEM, get the storage region confirmed in writing
Retention should be verified periodically, not assumed to be working since setup
Build retention into new-system onboarding as a standing checklist item
Step 4 — Build the detection-to-report pipeline: Reporting within 6 hours of "becoming aware" only works if you become aware quickly in the first place — this is why the Direction and a SIEM/monitoring programme are practically inseparable for most mid-size and large organisations. Wire your detection tooling (SIEM correlation, EDR/XDR alerts, manual reports from staff) into a single intake point that starts the 6-hour clock the moment something reportable is confirmed.
Define "becoming aware" internally as a specific, documented trigger — a confirmed alert, not a rumour
A single intake point (not three different channels) avoids the clock starting inconsistently
Test the pipeline with a simulated event before you need it for real
Step 5 — Name an owner and pre-build the report format: Designate a specific person or small team as the CERT-In reporting owner, with a named backup for when they're unavailable — "IT team" is not an owner. Pre-build the report template so the 6-hour window is spent gathering incident-specific facts, not figuring out what CERT-In's report format requires from scratch.
Name a primary and backup owner explicitly, with contact details documented
Pre-fill the report template with your organisation's static details in advance
Keep CERT-In's current reporting channel and format bookmarked and current — formats can change
Step 6 — Rehearse the workflow and prepare for information requests: The Direction also requires responding to CERT-In's information requests within 6 hours of receipt — a second clock separate from the initial incident report. Run at least one tabletop exercise simulating a reportable incident end to end, from detection through the filed report, to find gaps in the pipeline while there's no real incident on the line.
Run the tabletop with the actual named owner, not a stand-in, so gaps surface for real
Time the exercise — if detection-to-report takes close to 6 hours in a drill, a real incident will likely miss the window
Revisit the exercise annually or after any major infrastructure change
Frequently Asked Questions
What happens if we miss the 6-hour reporting window?
CERT-In's Direction gives it authority to call for information and take action against non-compliant entities; the practical risk for most Indian organisations is regulatory and reputational exposure alongside the fact that a delayed report usually means a delayed and less effective response to the incident itself. The 6-hour requirement exists because speed genuinely limits breach impact — treating it as a compliance checkbox rather than an operational capability misses the point.
Does this apply to small businesses, or only large enterprises?
The Direction's language covers "service providers, intermediaries, data centres, body corporates and Government organisations" broadly, without an explicit small-business carve-out — if you operate any of the systems in the reportable categories (a website, a mail server, a database of customer data), the obligation applies regardless of company size. In practice, enforcement focus and audit scrutiny concentrate on larger and regulated entities, but the underlying reporting obligation is not scoped to enterprise size.
What exactly counts as "becoming aware" of an incident?
CERT-In has not published a rigid technical definition, which is why organisations need to define it internally and document that definition — most compliance guidance treats it as the point a confirmed, credible indicator reaches someone with authority to act, not the first raw alert or rumour. Defining this clearly in advance is what prevents the 6-hour clock becoming a dispute during an actual incident.
Do we need a SIEM specifically, or can we comply without one?
The Direction does not name any specific product, but the 180-day retention and rapid-detection requirements are difficult to meet reliably at any real scale without centralised log management and correlation — which is functionally what a SIEM does. Very small environments with few systems can sometimes meet the letter of the requirement manually; anything beyond that scale typically needs the tooling to make the obligation practically achievable rather than theoretically true.
Talk to us about mapping CERT-In compliance to a SIEM deployment — WhatsApp +91 98119 98370 for a compliance + tooling assessment.