OT Incident Response Playbook for India: From Detection to CERT-In Reporting

When an OT security incident occurs at an Indian industrial facility, the next six hours are the most consequential - and most organisations are not prepared for them. CERT-In's mandatory six-hour incident reporting requirement means that the clock starts the moment an incident is detected. Simultaneously, the incident may be actively evolving in OT systems that control physical processes, requiring real-time decisions about response actions whose operational consequences must be evaluated before they are taken. Improvised response under these conditions consistently produces poor outcomes: slower containment, greater operational impact, delayed CERT-In reporting, and inadequate forensic preservation. A tested OT incident response playbook is not a nice-to-have; it is the operational prerequisite for meeting India's regulatory obligations while managing an active OT incident. (CERT-In, 2022)

Organisations with tested incident response plans contain OT breaches 35% faster and restore operations 40% more quickly than those relying on improvised response, according to Ponemon Institute research. (Ponemon Institute, 2024). The difference is not talent or resources - it is preparedness. Playbooks provide the structure that allows good decisions under pressure.

Key Takeaways

• CERT-In's six-hour reporting requirement demands a pre-built playbook - improvised response cannot meet this timeline reliably.
• Tested incident response plans contain OT breaches 35% faster than improvised response (Ponemon Institute, 2024).
• OT incident response must always evaluate operational safety consequences before taking containment actions.
• Playbooks must cover the full response cycle: detection, assessment, containment, reporting, recovery, and post-incident improvement.
• Tabletop exercises testing OT-specific scenarios are essential for validating playbook effectiveness at least annually.

OT security best practices for Indian enterprises

What Makes OT Incident Response Different from IT Incident Response?

IT incident response is driven by a single overriding objective: contain the threat and protect data as quickly as possible. OT incident response must balance this objective against operational safety and continuity constraints that have no IT equivalent. Before isolating a compromised SCADA server in an Indian power plant, the response team must determine whether that server is actively managing a running process, what the consequence of removing it from the network would be for that process, and whether a safe shutdown or controlled transfer of management responsibility can be achieved. Taking the wrong action in OT incident response can cause the very operational disruption that the attacker intended, or worse, create a safety incident that the security incident did not cause.

The decision-making process for OT incident response therefore requires two streams of expertise working together: cybersecurity expertise to understand the nature and extent of the compromise, and operational/process engineering expertise to understand the safety and operational consequences of response actions. Indian industrial organisations need both streams represented in their OT incident response teams, and the playbook must clearly define when each stream has decision authority. A security analyst cannot unilaterally decide to isolate a SCADA segment; a plant manager cannot unilaterally decide to delay containment indefinitely because of operational inconvenience. The playbook must define the escalation and decision authorities that balance both imperatives.

[CHART: OT incident response decision tree - security response vs operational safety considerations - Source: Opsio]

What Are the Phases of an OT Incident Response Playbook?

An OT incident response playbook for Indian enterprises should cover six phases. These phases map to the standard NIST CSF Respond and Recover functions, with OT-specific procedures added to each.

Phase 1: Detection and Initial Assessment (0-1 Hour)

Detection occurs when a monitoring tool generates an alert, an operator reports anomalous behaviour, or an external notification (from CERT-In, a vendor, or threat intelligence) indicates a potential compromise. Initial assessment determines the plausibility of the incident, the potentially affected systems, and the initial severity classification. The CERT-In six-hour clock arguably starts at detection - though the exact trigger is the determination that an incident has occurred, not the initial alert. The initial assessment should answer three questions: Is this a confirmed incident or a false positive? What OT systems may be affected? What is the immediate safety status? If answers suggest a real incident affecting OT systems, escalation to the OT incident response team should be immediate.

Phase 2: Notification and Escalation (0-2 Hours)

Simultaneous with assessment, notification must go to the defined internal stakeholders: the CISO, the plant operations manager or chief engineer, and the designated CERT-In liaison. The notification content should include what systems may be affected, the current operational status, and the initial severity assessment. Internal escalation is time-critical not just for CERT-In compliance but because operational decisions during the incident require leadership authority. For incidents that clearly meet CERT-In reporting criteria, initial reporting to CERT-In should begin at this phase even before full investigation - CERT-In expects preliminary notifications followed by updates rather than waiting for a complete investigation before reporting. (CERT-In, 2022)

NCIIPC guidelines and OT security compliance

Phase 3: Containment (1-4 Hours)

OT incident containment is where the tension between security response and operational continuity is most acute. Containment actions must be evaluated before execution: what is the consequence of isolating this network segment? Can the controlled process continue safely if this SCADA connection is severed? Is there a safe shutdown option? Can control be transferred to a backup system? The playbook must pre-approve specific containment actions for specific scenarios, with escalation paths for scenarios not covered. Pre-approved containment actions for common scenarios reduce decision latency during an active incident - the decision has been made in advance, with operational and safety review, so it can be executed rapidly when needed.

Forensic evidence preservation must occur alongside containment. OT forensics is different from IT forensics: network packet captures, historian data, SCADA event logs, and OT monitoring tool data are the primary forensic sources. Evidence must be preserved before containment actions that might overwrite it. CERT-In will request forensic evidence as part of incident investigation, and NCIIPC may require it for post-incident audit. The playbook should define evidence preservation steps that occur in parallel with containment, not after it.

Phase 4: CERT-In Reporting (Within 6 Hours of Detection)

CERT-In incident reporting must be completed within six hours of the incident being determined to have occurred. The CERT-In Incident Report should include: nature of the incident, systems and data affected, detection time, initial assessment of impact, containment actions taken, and current operational status. The report is preliminary at this stage - updates will follow as investigation proceeds. A pre-completed CERT-In report template, with the standard fields pre-populated with organisational information, reduces the time required to complete reporting under pressure. The CERT-In liaison should be responsible for submitting reports and managing the ongoing communication with CERT-In throughout the incident. (CERT-In, 2022)

Phase 5: Investigation and Recovery

Post-containment investigation determines the full scope of the incident, the attack vector, the extent of compromise, and the actions required to return to a secure operational state. OT incident investigation requires forensic analysis of industrial protocol logs, SCADA event records, and OT monitoring tool data alongside IT forensic evidence. Vendor involvement is often necessary: PLC vendors for firmware forensics, SCADA vendors for application log analysis, and OT security specialists for industrial protocol analysis. Recovery must sequence the return to service carefully: systems should only be returned to operation after their integrity is verified, and the attack path must be closed before recovery to prevent immediate re-compromise.

Phase 6: Post-Incident Review

Every OT security incident, even a contained one, should trigger a formal post-incident review. The review should answer: What detection gaps allowed the incident to reach the reported severity? What containment actions worked and what did not? Did the playbook guide good decisions or were there gaps? Were CERT-In reporting timelines met? What security improvements would prevent or limit similar incidents in future? Post-incident reviews drive the continuous improvement of both security controls and the incident response playbook itself.

[CHART: OT incident response timeline - 6-hour CERT-In window with phase milestones - Source: Opsio]