CERT-In's 6-Hour Reporting Rule: Building an Automated Compliance Pipeline

In April 2022, CERT-In (the Indian Computer Emergency Response Team) issued a directive that sent shockwaves through the Indian security community: organisations must report cybersecurity incidents to CERT-In within six hours of becoming aware of them. Not 24 hours. Not 72 hours like GDPR. Six hours — including over weekends and public holidays.

Most organisations responded with a policy update and a shared mailbox. That is not compliance. That is the illusion of compliance, and it will collapse the first time you face a real incident at 2 AM on a Sunday.

What Triggers the 6-Hour Clock

CERT-In's directive covers a broad range of incident types. The categories include targeted scanning of critical networks, compromise of systems, unauthorised access to data or accounts, DDoS attacks, malware deployment, identity theft, spoofing, phishing, rogue mobile apps, and attacks on critical infrastructure. The list is intentionally wide — when in doubt, report.

Critically, the clock starts from when you “become aware” of an incident — not when the incident occurred, and not when your forensic investigation concludes. This means your detection capability directly determines your compliance posture. If your SIEM takes four hours to surface an alert after an attacker exfiltrates data, you have two hours left to report. If your on-call engineer is not paged for six hours after the alert fires, you are already non-compliant.

The Manual Process Problem

A typical manual incident response workflow looks like this: SIEM fires an alert → L1 analyst triages → escalates to L2 → L2 confirms it's a real incident → incident commander declared → legal notified → report drafted → approved by management → submitted to CERT-In. In most organisations, this chain of handoffs takes 8–12 hours under ideal conditions. Under real conditions (weekend, key people on leave, ambiguous alert), it can take days.

The six-hour window assumes a level of operational readiness that most organisations do not have. The only viable path to consistent compliance is automation.

Architecture of an Automated Compliance Pipeline

Stage 1: Detection with Defined Severity Thresholds. Configure your SIEM, EDR, and cloud security tools with pre-defined rules that auto-classify incidents by severity. Critical incidents (confirmed breach, data exfiltration, ransomware deployment) should trigger an automated workflow immediately — no analyst triage required before the clock starts. The workflow can run in parallel with your triage process.

Stage 2: Automated Evidence Collection. At detection time, kick off automated evidence capture: snapshot the affected systems, pull relevant logs (30–60 minutes of context before the detection event), capture network flow data, and lock down the affected accounts or segments. This serves two purposes — it preserves forensic evidence and populates the data fields required for the CERT-In report.

Stage 3: Report Pre-Population. CERT-In provides a structured reporting form. Build a template that maps your detection data to the required fields: incident category, date/time of detection, affected systems, estimated impact, initial indicators of compromise, and mitigation steps taken. Automation should fill 80% of this form from structured detection data, leaving only human-judgment fields for manual completion.

Stage 4: Escalation and Approval Workflow. Time-box human decision points. When an incident is auto-detected, the on-call security lead has 30 minutes to confirm or dismiss. If no response, it auto-escalates to the next level. Approval for CERT-In submission should require a single click with a pre-populated form, not a 60-minute drafting session. Use a collaboration platform (Slack, Teams) with bot integration to surface time-remaining countdowns to key stakeholders.

Stage 5: Automated Submission with Audit Trail. Submit the CERT-In report via their portal or email endpoint automatically upon approval. Capture the submission timestamp, confirmation receipt, and the full report content in an immutable audit log. This log is your compliance evidence — it shows the time from detection to submission, and that is exactly what CERT-In will ask for if they investigate.

Technology Stack Recommendations

For detection and alerting: any modern SIEM (Splunk, Microsoft Sentinel, Elastic Security) with custom detection rules mapped to CERT-In incident categories. For workflow automation: PagerDuty, OpsGenie, or a custom webhook pipeline. For report generation: a simple form-filling service or an LLM-assisted report drafter (with human review) that converts structured detection data into the narrative required by CERT-In. For audit logging: append-only storage (AWS S3 with Object Lock, Azure Immutable Blob Storage) that captures every action with cryptographic timestamps.

What Non-Compliance Actually Costs

CERT-In's 2022 directive carries penalties for non-compliance under the IT Act, including potential imprisonment. More practically, failure to comply undermines your relationship with CERT-In in a future incident where their assistance could be invaluable. Regulators have long memories. The organisations that comply consistently — even for minor incidents — build a track record that pays dividends when they face a serious breach and need regulatory goodwill.

Six hours is an aggressive window. But with the right automation architecture, it is achievable without a 24/7 SOC team. Build the pipeline before you need it — because the incident will not wait for you to get organised.