If your organisation operates in India, one rule should shape how your security operations run: when a qualifying cyber incident is detected, you have six hours to report it to CERT-In. Not six hours to solve it. Six hours to notice it, classify it, and file the notification.
It’s one of the strictest incident-reporting windows in the world, and it puts real pressure on how fast a security team can move. This guide explains what the rule actually requires, and then breaks down — practically — what SOC providers in India need to do to keep their clients inside that window.
What is CERT-In’s 6-hour reporting rule?
CERT-In (the Indian Computer Emergency Response Team) is India’s national nodal agency for cyber security incidents, operating under Section 70B of the IT Act, 2000. On 28 April 2022 it issued directions — effective from 27 June 2022 — that made incident reporting time-bound for the first time.
The core requirement is simple to state: specified cyber incidents must be reported to CERT-In within six hours of noticing them, or of being made aware of them. Before these directions, entities only had to report “within a reasonable time.” Now there’s a hard clock.
A few things make the rule sharper than people expect:
- It covers around 20 categories of incident. Ransomware, unauthorised access, data breaches and leaks, DDoS and DoS attacks, phishing and spoofing, attacks on servers, databases and applications, supply-chain compromises, and attacks on IoT and OT systems all fall in scope.
- A prescribed reporting format. Reports use CERT-In’s format (commonly referenced as Annexure A), which is essentially built around five questions: who is reporting, when it was detected, what happened, what was affected, and what has been done so far.
- You don’t need perfect forensics. You can file an initial report inside six hours with the information you have, flag unknowns as “under investigation,” and supplement it as facts stabilise.
The rule also comes bundled with supporting obligations that directly affect how a SOC is built:
- 180-day log retention, in India. Logs of all ICT systems must be maintained securely for a rolling 180-day period, kept within Indian jurisdiction, and provided to CERT-In when you report an incident or on request.
- Clock synchronisation. System clocks must sync to NTP sources traceable to NIC or NPL, so timestamps across logs and reports are consistent — critical for forensic accuracy.
- A designated point of contact. Every covered entity must appoint a POC to interface with CERT-In and keep those details current.
Failure to comply carries penalties under Section 70B(7) of the IT Act — imprisonment of up to one year and/or a fine of up to ₹1 lakh, with proposed amendments seeking to raise the fine significantly. Treat the current figure as a floor, not a ceiling.
The detail that matters most: when the clock starts
The six hours run from the moment a qualifying incident is noticed – not from when it happened, and not from when your investigation concludes.
And “noticing” isn’t confined to the CISO’s desk. A SOC alert, a high-severity monitoring ticket, or a credible third-party disclosure can all start the clock. That’s why the rule is really a detection and operations problem, not a paperwork problem. If your monitoring is slow or noisy, you can burn hours before anyone even realises there’s something reportable — leaving almost no time to actually file.
This is exactly where a Security Operations Centre earns its place.
What SOC providers in India need to do
Meeting the six-hour window consistently isn’t about heroics during an incident. It’s about having the machinery already in place. Here’s what SOC providers in India need to deliver:
1. Continuous 24/7 detection
The clock doesn’t pause for nights, weekends or public holidays. SOC providers need round-the-clock monitoring across the client’s SIEM, endpoints, cloud workloads and identity sources — tuned so a genuine incident surfaces as an actionable alert with severity, asset context and a timestamp, rather than getting lost in noise.
2. Fast triage and classification
Detection is only half the job. Analysts have to quickly separate signal from noise and decide whether an event maps to one of CERT-In’s reportable categories. The cost of a quick internal classification is far lower than the cost of missing the deadline, so triage playbooks should be built to decide fast, with clear thresholds.
3. Log retention and time synchronisation
SOC providers need to architect log collection and retention to meet the 180-day, India-resident requirement, with critical sources on tamper-resistant storage. Synchronised timestamps across all sources keep incident timelines defensible when CERT-In asks for evidence.
4. Ready-to-file reporting artefacts
When an incident is confirmed, the reporting pack shouldn’t be assembled from scratch across emails and chat threads. A good SOC maintains pre-built templates aligned to CERT-In’s format, so the five core questions — who, when, what, what was affected, what was done — can be answered immediately with supporting logs attached.
5. A defined escalation path to the POC
The SOC must know exactly who the client’s CERT-In point of contact is (plus a backup) and escalate to them with a standard pack: what happened, where, when, the evidence, and the actions already taken. For high-severity incidents that means contacting named escalation contacts directly — not just raising a ticket.
6. Rehearsed workflows
The fastest teams treat the six-hour process like a fire drill. Roles are pre-assigned, the incident commander has the authority to declare an incident “reportable” without waiting on a committee, and the workflow is validated through tabletop exercises before it’s ever needed for real.
A simple 6-hour reporting workflow
Put together, the operational flow a SOC should run looks like this:
- Detect and alert — monitoring generates an actionable alert with severity, asset context and a timestamp.
- Triage fast — validate signal vs noise and classify against CERT-In’s reportable categories.
- Estimate impact — gauge blast radius: affected systems, business processes, and whether personal data is involved.
- Escalate to the POC — notify the designated contact and a backup with a standard incident pack.
- Draft in the prescribed format — fill known fields, attach supporting artefacts, mark unknowns clearly.
- Submit and track — file through the official channel, record acknowledgement details, and keep an internal case file for follow-up requests.
The goal is for the six-hour window to be something your SOC is already engineered around — not something anyone scrambles to reconstruct at 3 a.m.
What this means when you choose a SOC provider
Not every provider is built for Indian regulatory reality. When evaluating SOC providers in India for CERT-In readiness, look for:
- India-based, IST-aligned analysts with genuine 24/7 coverage.
- 180-day log retention within India, architected into the engagement.
- A CERT-In reporting workflow baked in — classification, templates and POC escalation, not bolted on afterwards.
- SIEM-agnostic integration with platforms like Microsoft Sentinel, Splunk and IBM QRadar, so you’re not forced into a rip-and-replace.
- Sector alignment to your regulator — RBI, SEBI CSCRF, IRDAI — so evidence is ready when auditors ask.
One clarification worth making: meeting the 6-hour rule is a SOC function, and it’s distinct from what a CERT-In empanelled vendor does. Empanelment authorises a firm to conduct security audits and VAPT — it’s an auditor credential, not a monitoring one. Most regulated enterprises need both: an empanelled auditor for periodic audits, and a SOC provider for the day-to-day detection and reporting that keeps them inside the six-hour window.
The bottom line
CERT-In’s 6-hour rule rewards operational readiness. The organisations that meet it comfortably aren’t the ones with the thickest compliance binders — they’re the ones whose SOC is watching continuously, classifying quickly, and reporting through a workflow that’s already been rehearsed. Get that right, and the six-hour clock stops being a source of panic and becomes something your operations handle quietly in the background.
See where your 6-hour readiness stands
SOCroom runs analyst-led, 24/7 managed SOC operations from Bengaluru — built around CERT-In’s reporting window, 180-day log retention and DPDP-aligned monitoring. Book a free security assessment and we’ll show you where your reporting workflow holds up and where it breaks.
FAQ
What is CERT-In’s 6-hour reporting rule? Under CERT-In’s 2022 directions, covered entities must report specified cyber incidents to CERT-In within six hours of noticing them, or of being made aware of them. It applies to around 20 incident categories and uses CERT-In’s prescribed reporting format.
When does the six-hour clock start? From the moment a qualifying incident is noticed or brought to your attention — including via a SOC alert, an MSSP ticket, or a credible third-party disclosure. It’s tied to awareness, not to when the incident originally occurred.
What do SOC providers in India need to do to meet the rule? Provide continuous 24/7 detection, fast triage and classification against reportable categories, 180-day India-resident log retention with synchronised timestamps, ready-to-file reporting artefacts, and a rehearsed escalation path to the client’s CERT-In point of contact.
Do we need complete forensics before reporting? No. You file an initial report within six hours with the information available, mark unknowns as “under investigation,” and supplement it as the investigation progresses.
Is meeting the 6-hour rule the same as hiring a CERT-In empanelled vendor? No. CERT-In empanelment authorises a firm to conduct security audits and VAPT — it’s an auditor credential. Meeting the 6-hour reporting window is an operational task handled by a SOC provider. Most regulated organisations use both.
