CERT-In Incident Reporting Six Hours: Direction 20(3)/2022 Runbook

CERT-In incident reporting six hours after detection is a legal obligation under Direction No. 20(3)/2022, issued on 28 April 2022, and the six-hour window is not a guideline — it is a statutory requirement with regulatory consequences for non-compliance. The six-hour window is not a guideline — it is a legal requirement with regulatory consequences for non-compliance. This runbook is the operational playbook we use with our own incident-response retainer clients: what triggers the obligation, how to classify an incident, who to notify, what format to use, and how to document the chain so the regulator can follow it.

The article moves top-down: what the Direction actually requires, the incident-type taxonomy, the step-by-step reporting workflow, the documentation templates, and common failure modes that extend the timeline beyond six hours.

What CERT-In Direction 20(3)/2022 actually requires

The Direction applies to:

• All government organisations and agencies
• All intermediaries, including ISPs, cloud providers, and data centres
• All corporate entities owning, operating, or managing critical information infrastructure
• All body corporates providing digital services to Indian residents

In practice, this covers virtually every Bangalore SaaS, fintech, and BFSI entity.

The six reporting categories

Who must report and to whom

Internal notification chain (0–30 minutes)

1. Detection — SOC, NOC, or engineering team identifies anomalous activity
2. Triage — Duty officer validates the incident against the reporting categories
3. Escalation — CISO or designated security lead is notified
4. Legal / compliance — If personal data is involved, DPDP Act obligations may also trigger

External notification chain (30 minutes – 6 hours)

1. CERT-In — Primary report via the online incident reporting portal or designated email
2. Sectoral regulator — RBI for banks, SEBI for stock brokers, IRDAI for insurers
3. Law enforcement — If criminal activity is suspected (CERT-In may escalate)
4. Affected parties — Customers, partners, or Data Principals as required by contract or DPDP Act

Step-by-step reporting workflow

Step 1: Detection and initial classification (T+0 to T+15 min)

• Confirm the incident is real (not a false positive)
• Map the incident to one of the ten CERT-In categories
• Capture initial timestamps: first observed, first confirmed, systems affected

Step 2: Containment assessment (T+15 to T+45 min)

• Determine scope: how many systems, what data classes, what user populations
• Decide containment strategy: isolate, shut down, or monitor
• Document the decision rationale

Step 3: Draft initial report (T+45 to T+2 hours)

The initial CERT-In report must include:

• Organisation name, CIN, and contact details
• Incident category and brief description
• Date and time of detection
• Systems and data affected
• Initial impact assessment
• Containment measures taken

Step 4: Submit to CERT-In (T+2 to T+4 hours)

• Use the CERT-In online portal at cert-in.org.in (relative URL kept current for indexing)
• Attach supporting logs, screenshots, or network captures
• Retain the acknowledgement number

Step 5: Sectoral and downstream notification (T+4 to T+6 hours)

• RBI: cpcs@rbi.org.in for banks and NBFCs
• SEBI: Through the SEBI portal for Market Infrastructure Institutions
• IRDAI: Through the IRDAI cyber-security reporting channel
• Customer notification: As per contract and DPDP Act timelines

Step 6: Post-incident documentation (T+6 to T+24 hours)

• Full forensic timeline
• Root-cause analysis
• Remediation plan
• Control-gap closure evidence

Documentation templates

Initial report template (CERT-In)

TO: CERT-In Incident Reporting
FROM: [Organisation] Security Operations
DATE: [Date]
INCIDENT ID: [Internal tracking number]

1. INCIDENT CATEGORY: [Select from 10 categories]
2. DETECTION TIME: [ISO 8601 timestamp]
3. AFFECTED SYSTEMS: [Hostname / IP / cloud resource ID]
4. AFFECTED DATA: [Data class, volume, jurisdiction]
5. CONTAINMENT STATUS: [Contained / monitoring / unknown]
6. INITIAL IMPACT: [Availability / confidentiality / integrity]
7. NEXT UPDATE: [Expected time for follow-up report]

Common reporting mistakes

1. Waiting for full forensics before reporting. The six-hour window is for initial notification, not root-cause analysis. Report what you know; update as you learn more.
2. Reporting false positives. Repeated false-positive reporting erodes regulator trust. Build a robust triage process.
3. Forgetting sectoral obligations. CERT-In is the primary channel, but RBI, SEBI, and IRDAI have parallel reporting requirements.
4. Neglecting DPDP overlap. A data breach that triggers CERT-In may also trigger DPDP Act notification to the Data Protection Board.
5. Failing to document the chain of custody. Regulators will ask for evidence that the six-hour window was met. Timestamped logs matter.

Cross-framework mapping

• DPDP Act 2023 — Personal data breaches must be notified to the Data Protection Board “as soon as reasonably practicable.” The six-hour CERT-In window is a de facto standard. See our DPDP Act guide.
• ISO 27001:2022 Annex A 5.24 — Information security incident management planning and preparation. See our ISO 27001 service page.
• SOC 2 CC7.3 — Incident detection and monitoring. See our SOC 2 service page.

Incident response retainer: why six hours is hard without preparation

The organisations that meet the six-hour window consistently share one characteristic: they have an incident-response retainer with a CERT-In empanelled firm. The retainer includes:

• Pre-negotiated escalation contacts
• Pre-authorised forensic access
• Template library pre-customised for the organisation
• Table-top exercises conducted quarterly

Without a retainer, the first two hours are typically spent finding a firm, negotiating an SOW, and granting access. See our IR retainer pricing breakdown for cost and scope.

Incident-type runbooks — sector-specific reporting

The six-hour window applies uniformly, but the content of the report varies by incident type. Below are the four incident archetypes we see most often in Bangalore engagements, with the specific information CERT-In expects in each.

Ransomware / encryption attack

Initial report content priorities: scope of encryption (number of systems, data classes, geographic distribution), threat-actor identification (ransom note, extension pattern, behavioural fingerprint), exfiltration assessment (modern actors steal before encrypting), backup status (intact and verifiably untampered, or compromised). Critical detail to capture in the first report: estimated business impact, including any customer-facing service degradation. Common reporting failure: under-reporting exfiltration scope because forensic analysis is incomplete; the appropriate response is to report what is known and update as analysis progresses.

Business Email Compromise (BEC) and fraudulent wire transfer

Initial report content priorities: attack vector (typically credential phishing followed by inbox-rule manipulation), affected accounts, financial exposure (transferred or attempted-transfer amounts), customer / vendor counterparty involvement. CERT-In-side handling differs from ransomware because BEC often requires coordination with banking partners and law-enforcement liaisons; the initial report should explicitly identify the receiving-bank cooperation needs.

Cloud account compromise

Initial report content priorities: cloud provider (AWS / Azure / GCP), affected account or subscription, IAM-misuse pattern (compromised credentials, role-assumption abuse, federated-identity abuse), blast radius (which resources accessed, which data classes exposed). Cloud-incident reporting is increasingly common in Bangalore SaaS engagements; CERT-In’s coordination expectations include cloud-provider notification timing and data-residency confirmation.

Application compromise (webshell, RCE, supply-chain)

Initial report content priorities: vulnerability exploited (CVE if known, or finding category), affected application, customer-data exposure, persistence mechanism (webshell location, scheduled task, modified binary). Supply-chain compromises specifically (npm / pypi / maven malicious package) require disclosure of the affected package name and version; CERT-In coordinates with the broader CERT community on supply-chain incidents.

Communication templates — internal, customer, and regulator

The six-hour CERT-In notification is one of several communications that must happen in parallel. Each audience requires different content and different timing.

Internal escalation template

Template content includes incident commander identification, affected systems list, current containment status, expected next update time. Internal escalation should reach the CISO or designated security lead within 30 minutes of detection; reaching the CEO and General Counsel typically within the first hour for material incidents.

Customer notification template

Template content includes incident summary in plain language (avoid technical jargon), specific data categories affected, action customer should take (rotate credentials, monitor for suspicious activity), contact channel for questions, expected next update timing. Customer notification timing depends on contractual obligations and DPDP Act requirements; for personal-data breaches, “as soon as reasonably practicable” applies — which in practice means within 24–72 hours of confirmed scope.

Regulator follow-up template

Subsequent CERT-In reports beyond the initial six-hour notification typically follow a defined cadence: 24-hour update with refined scope assessment, 72-hour update with root-cause hypothesis, post-incident report within 30 days with full forensic timeline and remediation roadmap.

Board / investor communication template

Material incidents require board notification, which has different content priorities than regulator reporting. Focus on financial exposure, reputational risk, customer-impact estimate, and remediation plan. Avoid technical detail except where directly relevant to the business impact.

Tabletop exercise scenarios for Bangalore teams

Pre-incident preparation is the single largest factor in actually meeting the six-hour window. Tabletop exercises run quarterly with realistic scenarios materially compress real-incident response time. Below are five scenario templates we use with our retainer clients.

Scenario 1 — Ransomware via compromised vendor remote-access tool. A managed-service-provider’s remote-access tool is compromised; the attacker uses the trusted access path to deploy ransomware across customer environments. Tests vendor-incident coordination, multi-customer impact assessment, and shared-infrastructure response.

Scenario 2 — BEC with fraudulent wire transfer attempted. Finance team receives a credible-looking email from “the CEO” requesting an urgent vendor payment. Tests verification protocols, financial-control bypass detection, and banking-partner coordination.

Scenario 3 — Cloud key compromise via leaked GitHub commit. AWS access keys committed to a public repository are detected by an external researcher. Tests credential-rotation speed, access-revocation completeness, and exfiltration assessment.

Scenario 4 — Insider threat with data-exfiltration objective. Departing employee with access to customer database is detected accessing data outside their normal pattern. Tests detection capability, HR-coordinated investigation, and evidence-preservation discipline.

Scenario 5 — Supply-chain compromise via npm dependency. Production build picks up a malicious package version. Tests software-bill-of-materials process, build-artefact verification, and customer-impact assessment.

Each tabletop runs 2–3 hours, produces a written after-action report, and feeds findings back into the runbook. Quarterly cadence is the operational floor; monthly cadence is appropriate for organisations with high-impact incident exposure.

Practical next steps

If you do not have an incident-response playbook, use the step-by-step workflow above as a starting point. If you need a retainer that includes CERT-In reporting support, see our Incident Response service page. If you need to verify your auditor’s empanelment, see the CERT-In Empanelled Auditor List 2026.

For organisations that want a thirty-minute scoping conversation with a partner, the contact form in the site footer books the call directly. We commit to written scope, fixed price in INR, and 24×7 retainer response with sub-15-minute MTTR.

CERT-In reporting FAQ

Does the six-hour clock start at incident occurrence or detection? Detection. The Direction specifies “from the time of noticing such incidents,” which is the detection moment for the organisation, not the actual incident occurrence (which may be earlier).

What if I detect on a Sunday at 2 AM? The clock runs continuously. CERT-In accepts reports 24×7 via the online portal and email. Most organisations meeting the six-hour window have an incident-response retainer that operates around the clock.

Do I need to report a contained incident with no data exposure? Yes if it falls within the ten reportable categories. The Direction’s threshold is incident type, not impact magnitude.

What if the incident affects only employee data, not customer data? Still reportable. The Direction does not differentiate by data subject category.

Can I use a generic incident-report template? CERT-In accepts the standard incident-reporting form. The form is available on the CERT-In portal and is updated periodically. Generic templates that don’t follow the prescribed format may trigger requests for additional information.

What evidence does CERT-In typically request post-report? Forensic timeline, scope of compromise, indicators of compromise (IoCs), remediation evidence, and (where applicable) attribution analysis. Initial report is high-level; subsequent updates progress toward this evidence.

Does CERT-In share incident details with sectoral regulators? CERT-In coordinates with sectoral regulators (RBI, SEBI, IRDAI) on incidents affecting their regulated entities. The reporting organisation typically also reports directly to the sectoral regulator per their specific framework.

What if the incident is still in progress at the six-hour mark? Report what is known. The initial report is for notification, not root-cause analysis. Updates are expected as the incident progresses.

Can CERT-In help with incident response? CERT-In provides technical assistance for major incidents, particularly those affecting critical infrastructure. The CERT-In team may engage directly for systemically-important incidents.

Are there penalties for late reporting? Yes. Penalties under Section 70B of the Information Technology Act, 2000 can apply for failure to comply with CERT-In Directions. The penalty quantum is typically determined case-by-case.

Does the reporting requirement apply to ransomware where the attacker encrypts but doesn’t exfiltrate? Yes. Ransomware falls within the malicious-code attack category regardless of exfiltration status.

What if I’m uncertain whether an event qualifies as a reportable incident? Err on the side of reporting. CERT-In accepts reports for events that turn out to be false positives; failing to report a real incident is the more-costly mistake.

Six-hour clock — the operational reality

Beyond the runbook, the operational reality of meeting a six-hour reporting window has texture worth understanding.

Hour 0 — detection challenge

The clock starts at “noticing,” which usually means the moment your security or operations team confirms an actual incident vs a false alarm. Most Bangalore organisations have detection latency that pushes Hour 0 later than the actual incident occurrence — sometimes by hours or days. Reducing detection latency is the single highest-leverage operational improvement for meeting the six-hour window.

Hour 1 — triage challenge

Confirming the incident type and scope within an hour requires familiarity with your environment. Outsourced first-line monitoring (MSSP, SOC-as-a-service) often has Hour 1 friction because the responder doesn’t know your environment well. Strong retainer relationships with pre-onboarded incident-response firms reduce Hour 1 friction.

Hour 2 — escalation challenge

Reaching the right internal escalation contacts and the right legal counsel within an hour is harder at 2 AM Sunday than at 2 PM Tuesday. Documented escalation trees with multiple contact methods (phone, SMS, on-call rotation) per role address this.

Hour 3 — drafting challenge

Drafting a CERT-In report requires structured information. Pre-customised templates with “fill in the blanks” structure dramatically reduce drafting time. Organisations without pre-customised templates routinely lose hours to format and content questions.

Hour 4–5 — review challenge

Most organisations require legal review before regulatory submission. Coordinating legal review for an out-of-hours incident is non-trivial. Pre-authorised reporting templates with legal pre-review reduce this friction.

Hour 6 — submission

Submission via CERT-In’s portal is straightforward when the report is ready. Most failures to meet the six-hour window are detection-and-triage failures, not submission failures.

Reporting subsequent updates beyond the initial six hours

The initial report is one of several reports required for material incidents.

Hour 6 update. Initial notification.

Hour 24 update. Refined scope, additional affected systems, exfiltration confirmation, containment status.

Hour 72 update. Root-cause hypothesis, remediation plan, customer-communication status.

Day 30 final report. Full forensic timeline, validated root-cause, completed remediation evidence.

CERT-In may require additional updates depending on incident severity and ongoing investigation.

Coordination with other regulator reporting

For Bangalore organisations subject to multiple regulatory frameworks, parallel reporting obligations arise.

RBI for BFSI. RBI Cyber Security Framework requires similar incident reporting. Coordinate timing with CERT-In submission.

SEBI for capital markets. CSCRF requires incident reporting through prescribed channels. SEBI-coordinated incident reports may parallel CERT-In submission.

IRDAI for insurance. ICSG framework requires incident reporting to IRDAI. Timing coordination with CERT-In is operational.

Data Protection Board. DPDP Act breach notification applies for personal-data breaches. The Board’s notification timeline (“as soon as reasonably practicable”) may align with the CERT-In six-hour window.

Multi-regulator reporting requires coordination across legal, compliance, and security functions to avoid inconsistent statements across reports.

Building real six-hour readiness

Beyond runbook documentation, real six-hour readiness requires specific operational investments.

Detection capability. SIEM with rules for the ten reportable categories. Alert thresholds tuned to catch real incidents without false-positive flooding. 24×7 monitoring or Aggregator MSOC subscription for entities below in-house SOC capability.

Triage capability. Trained analysts who can confirm incidents quickly. Escalation criteria documented and rehearsed. Decision authority delegated for incident-classification calls.

Communication capability. Pre-customised report templates. Distribution lists for internal escalation. CERT-In submission credentials maintained currently. Sectoral-regulator submission channels documented.

Forensic capability. Tools and skills to capture forensic artefacts immediately upon incident detection. Pre-authorised access to relevant systems. Chain-of-custody discipline for legal admissibility.

Coordination capability. Relationships with external IR retainer firm, CERT-In coordinators, sectoral regulators. These relationships must exist before the incident — building them under pressure produces poor outcomes.

Practice. Quarterly tabletops with realistic scenarios. Annual full-stack exercise testing detection through reporting. Without practice, real incidents reveal gaps that documentation didn’t.

The six-hour window is achievable for organisations that have invested in these capabilities. It is unachievable for organisations that haven’t.

Six-hour reporting in different organisational contexts

Enterprise organisations with mature SOC. Six-hour window is operationally routine. Internal SOC handles initial detection, triage, and coordinated reporting. External IR retainer activates for material incidents.

Mid-size organisations with managed SOC. Aggregator-MSOC subscription handles initial detection; internal team handles triage and reporting coordination. Six-hour window achievable with discipline.

Smaller organisations without dedicated SOC. External IR retainer is the practical path to six-hour readiness. Without a retainer relationship, the six-hour window is rarely achievable for material incidents.

Government and PSU contractors. Sectoral coordinators (CSIRT-Fin for BFSI, NCIIPC for critical infrastructure) often provide additional support. Coordination layers add complexity but provide expertise.

Cross-border organisations. Multinationals operating across jurisdictions face parallel reporting obligations. Six-hour CERT-In window may apply alongside GDPR’s 72-hour window and other jurisdictional requirements.