What is Contingency Planning?
Contingency Planning is the practice of preparing, testing and maintaining plans in advance that allow an organisation to keep critical systems and processes running during a disruption, or to restore them within an agreed time. It answers the question of what happens when a server, network, power supply or supplier fails: who decides, which emergency procedure applies and how quickly the system must be back. In OT environments there is an extra dimension: the physical process keeps going, so the plan must also protect Safety, production and availability when SCADA or the HMI is unavailable.
Contingency planning is a building block of broader continuity strategies such as Business Continuity and Disaster Recovery.
🧠 How does Contingency Planning work?
The best-known method is set out in NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems, May 2010). It describes a seven-step process that is widely followed outside the US government as well:
- Develop a contingency planning policy - who owns it, which systems are in scope, how often plans are tested and reviewed.
- Conduct a Business Impact Analysis - determine for each process the consequences of an outage and the tolerable downtime.
- Identify preventive controls - for example UPS, redundancy, fire protection and offline backups.
- Create contingency strategies - backup and restore, alternate sites, spare hardware, supplier contracts.
- Write the contingency plan - with concrete recovery procedures per system and scenario.
- Test, train and exercise - from tabletop exercises to a full failover.
- Maintain the plan - as a living document, tied to change management and version control.
According to NIST, the plan itself has three phases: activation and notification (confirm the incident, decide, call people in), recovery (bring systems back in a fixed order) and reconstitution (test, return to normal operations and review the plan).
A good plan describes not only what must be done, but also who, with what, and how quickly.
⏱️ Which recovery objectives shape the plan?
The Business Impact Analysis produces three numbers that drive every choice in the plan:
| Term | Meaning | OT example |
|---|---|---|
| MTD (Maximum Tolerable Downtime) | Total downtime the process can tolerate | A bakery line whose dough becomes unusable after a few hours |
| RTO (Recovery Time Objective) | Maximum recovery time of one system; must be shorter than the MTD | Time to rebuild a SCADA server |
| RPO (Recovery Point Objective) | Maximum acceptable data loss, measured back to the last backup | Loss of historian data or batch records since the last backup |
NIST SP 800-34 states that the RTO must normally be shorter than the MTD, because work often has to be reprocessed after recovery. The RPO sits outside the MTD: it is about data loss, not time. In the process industry the MTD can be very short, while the RPO for a PLC program can be generous, as long as the latest approved version is stored safely.
🔄 How does Contingency Planning relate to other plans?
NIST SP 800-34 distinguishes eight types of plans, including the business continuity plan, the crisis communications plan, the cyber incident response plan, the disaster recovery plan and the information system contingency plan (ISCP). Continuity planning concerns the business functions; contingency planning concerns recovering the systems that support them.
| Plan | Focus | Typical trigger | OT example |
|---|---|---|---|
| Business Continuity | Keeping business processes going | Prolonged disruption of any kind | Moving production to another plant |
| Contingency plan (ISCP) | Recovering one system or group of systems | Failure of that system | HMI outage → manual operation with a checklist |
| Disaster Recovery | Restoring infrastructure after a major incident | Fire, flood, ransomware | Restoring SCADA from a backup server at an alternate site |
| Incident Response Plan | Detecting, containing and investigating a cyber incident | Attack or suspicious activity | Isolating the OT network from the office network |
| Crisis Communication Plan | Communicating with staff, customers and regulators | Any incident with external impact | Notifying the CSIRT and the local community |
Contingency planning and disaster recovery overlap heavily: the DR plan is effectively the part that covers large, site-wide disruptions.
🏭 What does Contingency Planning look like in industrial networks?
OT differs from IT on one crucial point: the process often has to keep running or stop in a controlled way. Typical measures are:
- Offline backups of PLC programs, drive parameters and HMI projects, including the right software versions and licences to restore them
- Failover to redundant SCADA servers, networks and power supplies
- Manual operation during HMI or IO faults, using local control panels and paper checklists
- Local procedures when central monitoring or the Historian is unavailable, such as logging critical readings by hand
- Safe state - the plan defines when the process moves to a fail-safe state; the SIS keeps working independently of the control system
- Spare hardware for components with long lead times or that are no longer manufactured
Real incidents show why this matters. During the LockerGoga attack on Norsk Hydro in 2019, parts of production continued under manual operation. In 2021 Colonial Pipeline shut down its pipeline for six days, even though only the IT network had been hit. After NotPetya, Maersk could only recover thanks to a single domain controller in Ghana that had been offline because of a power cut.
In OT, contingency planning is about physical processes that must continue, even without IT support.
📐 Which standards and laws require contingency planning?
- NIST SP 800-53 Rev. 5 - the CP (Contingency Planning) control family includes CP-2 (contingency plan), CP-4 (testing), CP-9 (system backup), CP-10 (system recovery and reconstitution) and CP-12 (safe mode). For US federal systems this is mandatory through FISMA.
- NIST SP 800-82 Rev. 3 (September 2023) - the OT security guide that applies these controls to industrial systems.
- IEC 62443-3-3 - system requirements SR 7.3 (control system backup) and SR 7.4 (control system recovery and reconstitution).
- ISO 27001 and ISO 22301 - information security during disruption and a full management system for business continuity.
- NIS2 - Article 21(2)(c) requires business continuity, such as backup management and disaster recovery, and crisis management. In the Netherlands this is transposed in the Cyberbeveiligingswet (Cybersecurity Act), in force since 15 August 2026.
Together these frameworks support Compliance, Incident Response and Risk Management within the wider IEC 62443 approach.
🧭 How do you test a contingency plan in an OT environment?
NIST SP 800-34 links the intensity of exercising to the impact level of the system:
| Impact level | Recommended exercise | Minimum content |
|---|---|---|
| Low | Tabletop exercise | Discuss a scenario with all points of contact in the plan |
| Moderate | Functional exercise | Perform roles in a simulated environment, including recovery from backup media |
| High | Full-scale functional exercise | Failover to the alternate site, full recovery and reconstitution to a known state |
In OT a full test during production is rarely possible. NIST therefore points to planned maintenance or a shutdown as a natural moment for a functional exercise. Practical tips:
- Test the restore, not just the backup - load a PLC program onto spare hardware and compare it with the latest approved version.
- Use a test environment or digital twin for scenarios you cannot replay in the plant.
- Practise manual operation with operators, including the moment of switching back to automatic.
- Keep immutable backups and maintain a jump server or other management route that does not depend on the affected domain.
- Review and update - record lessons learned and feed them into the plan, at least annually and after every major change.
🔐 What does contingency planning deliver for security?
- Reduces the impact of cyber incidents, power outages and sabotage
- Clarifies roles and decision rights in advance, so nobody has to improvise during a crisis
- Prevents recovery from causing reinfection, because clean backups and a fixed recovery order are agreed beforehand
- Gives management a sound basis for investment decisions on redundancy and alternate sites, as part of overall security
Without contingency planning, a relatively small incident can lead to prolonged downtime or hazardous situations.
❓ Frequently asked questions
What is the difference between contingency planning and business continuity?
Business continuity is about keeping business functions running as a whole, including people, sites and suppliers. Contingency planning focuses on absorbing failures of, and recovering, the systems that support those functions. A contingency plan is therefore a building block of the wider business continuity plan.
Which standard describes contingency planning?
The best-known guide to contingency planning is NIST SP 800-34 Rev. 1 from 2010, with a seven-step process and templates per impact level. The related controls are in the CP family of NIST SP 800-53. For OT, NIST SP 800-82 and IEC 62443-3-3 complement it.
Is contingency planning mandatory under NIS2?
NIS2 does not use the term contingency planning, but Article 21 does require business continuity, backup management, disaster recovery and crisis management. Organisations under the Dutch Cyberbeveiligingswet must therefore be able to demonstrate emergency plans. A tested contingency plan is the most direct way to show this.
How often should a contingency plan be tested?
NIST leaves the frequency to the organisation, but the sample policy in SP 800-34 assumes an annual review and an annual test. After major changes to installations, the network or the organisation, the contingency plan should also be reviewed straight away. In OT, tests are often linked to planned maintenance shutdowns.
What should an OT contingency plan contain at a minimum?
An OT contingency plan contains at least the critical systems with their RTO and RPO, contact details and decision rights, procedures for manual operation and safe shutdown, the location of offline backups and the recovery order. Supplier agreements and spare parts belong in it too. Without these elements the plan cannot be executed in a crisis.
What is a tabletop exercise in contingency planning?
A tabletop exercise is a discussion-based exercise in which participants walk through a scenario and agree who does what, without actually switching systems off. For contingency planning it is an inexpensive first test that exposes gaps in roles, communication and procedures. Functional exercises with real restores follow later.
📌 In summary
Contingency Planning ensures that industrial processes keep running in a controlled way or stop safely during outages or attacks, and recover within an agreed time. With a Business Impact Analysis, clear RTOs and RPOs, offline backups, manual operation procedures and regular exercises, a paper plan becomes a working safety net that also aligns with NIS2 and IEC 62443.