An incident is the worst possible time to determine who is in charge, whom to notify and whether to isolate the plant from the corporate network. Those decisions are difficult enough with time to consider them. Under pressure, outside working hours and with production at stake, they are considerably harder. An incident response plan allows them to be made in advance.
Assume an incident will occur
No combination of controls prevents every attack. Phishing succeeds, suppliers are compromised and vulnerabilities are exploited before patches are available. Organisations that recover well are not those that were never breached. They are those that detected the intrusion early, contained it decisively and restored operations from backups they had already tested.
The incident response lifecycle
Recognised frameworks such as NIST SP 800-61 describe incident response as a continuous lifecycle:
- Preparation. Define roles, contacts, decision authority and the tools responders require. Ensure logging and backups are in place before they are needed.
- Detection and analysis. Define what constitutes an incident, how alerts are triaged and how severity is classified.
- Containment, eradication and recovery. Isolate affected systems, remove the attacker’s access and restore services in a controlled sequence.
- Post-incident activity. Review every significant incident and feed lessons learned into the risk register and the plan.
What the plan must define
- Who leads the response, and who is authorised to take drastic action such as isolating a network or shutting down a process?
- Who must be notified, and within what timeframe: executive leadership, legal counsel, regulators, insurers, customers and employees?
- Which systems are critical, in what order they are restored, and where the backups are held?
- How the team will communicate if email or the corporate network is unavailable?
- Which external specialists can be engaged, and whether a retainer is already in place?
Industrial environments require dedicated playbooks
In OT, the safety of people and equipment takes precedence over evidence preservation. Isolating a control network may be the correct action, or it may initiate a hazardous trip. Those decisions belong to operations and engineering, with security in an advisory role. Playbooks should be developed jointly, should specify when the process can safely run in manual or isolated mode, and should document how controller logic and configurations are restored from known-good copies.
Exercise the plan
A plan that has never been rehearsed is a document rather than a capability. Tabletop exercises, in which the team works through a realistic scenario, are inexpensive and expose gaps quickly: an outdated contact list, unclear decision authority, a backup no one knows how to restore. Conduct at least one exercise a year, and after any significant organisational or system change.
Maintain an incident record
Log every incident, including minor ones, with the date, affected assets, severity, related risk and actions taken. Over time, the log reveals patterns that no single incident shows, and it is precisely the evidence regulators and insurers request.
The best time to write an incident response plan was before the last incident. The next best time is now.