Incident Response and Recovery

Incident response and recovery is the practised capability to detect, contain, remediate and restore an Industrial Automation and Control System (IACS) after a cyber security event — and to learn from it. Prevention is preferred because process consequences can be severe, but prevention fails; a documented response process is also needed for regulatory duty-to-report obligations. In ISA/IEC 62443 this maps primarily to Part 2-1 SPE 7 (EVENT 1.8) and to continuity / backup expectations in SPE 8.

In this topic (flow)

Read as a sequence — plan and prevent first, then manage the incident, then learn and investigate:

Incident Response Lifecycle (planned)
Cyber Incident Response Planning (planned)
Incident Prevention (planned)
Incident Management (planned)
Post-Incident Analysis (planned)
IEC 62443-3-1 Clause 8.5 Forensics

CSIRT — Cyber Security Incident Response Team

Organise a cross-functional CSIRT before an incident. Typical roles include:

Team manager
Process / control engineer
Network and systems administrators
Plant / site manager
IT / OT security (CIO / CISO path)
Vendor support
Legal; often public relations and human resources

Not every member is needed for every event. Start with clear operating procedures, contact lists with backups, and a response checklist.

Incident response plan contents

Overview, goals and objectives — what the plan must achieve
Incident detection — how physical and digital incidents are discovered
Notification and escalation — priority rules, contacts and backups
Analysis — how to evaluate scope (systems, equipment, organisations affected)
Actions — containment, remediation and recovery steps people can follow under stress
Communications — internal/external chains, media / authority contacts, vetted statements, alternate channels if telephony or Internet fail
Forensics — evidence collection after stabilisation (see IEC 62443-3-1 Clause 8.5 Forensics)

Incident management flow

Detect — automated alerts (IDS, SIEM, AV) or human observation of abnormal behaviour
Categorise — priority and type (malware, unauthorised access, DoS, insider, etc.)
Contain — stop spread and ongoing damage without creating a worse process hazard
Remediate — remove root cause (close access paths, remove malware, apply protective measures)
Recover and restore — return to a verified pre-incident or safe operating state
Learn — post-incident analysis, forensics and programme improvements

Containment

Containment depends on incident type, system criticality and acceptable risk. Plan how to isolate affected segments without unsafe process trips. Protect adjacent units from malware and network floods (for example DoS). Pre-positioned tools (segmentation, VPN cut-over patterns, account disable procedures) must be ready before they are needed.

Remediation

Close unauthorised access paths
Remove malware and verify it does not return (worms, missed footholds)
Coordinate with asset owners, data owners and production supervision before restart

Recovery and restoration

Contingency and isolation plans for running segments independently
Backups and failover systems maintained and tested to production-comparable levels
Acceptance tests and procedures to declare the IACS fully operational again

Prevention remains primary

Strong response does not replace prevention. Keep the Maintain-phase control set healthy: asset inventory, hardening, access control, remote access, vulnerability and patch management, malware protection, backups, change management, information protection and physical security — plus clear vendor remote-access agreements and SLAs that affect the CSIRT.