# OT recovery decisions — activity sheet

Version 1.0 · October 2026 · Dan Fisher / danfisher.dev
CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/

Open /examples/recovery-explorer on the website or local preview. Older /lab/recovery-explorer bookmarks redirect here. This fictional tabletop does not connect to equipment. Times, buffer use, scenarios, and acceptance criteria are teaching assumptions, not a recovery procedure for a real facility.

## 1. An update affects visibility, not local control
Choose Update regression and the tested recovery pack. Begin incident and assess it.
Try returning to service before restoring and validating the HMI. Read the outcome.
Restore the reviewed HMI copy, reconcile configuration, review field conditions, run the functional test, optionally verify historian collection, then attempt return to service.

Discuss: Why was controller recovery unnecessary? What does the operator lose when the HMI is unavailable? Why does an older reviewed image still need reconciliation?

## 2. A power event exposes dependencies
Choose Power interruption. Try the server-only snapshot for one run and the tested pack for another.
Try restoring the network before confirming power. Then recover in an order that satisfies the dependencies.
With the server-only pack, controller recovery requires the separately recovered engineering export. Compare elapsed time and the fictional service buffer.

Discuss: Which artifacts did the server snapshot omit? What physical and human dependencies are missing from this simplified model? Does restored supply authorize equipment restart?

## 3. Recovery does not erase a cyber incident
Choose Cyber incident. Assess, preserve evidence, and establish the recovery boundary before rebuilding.
Try the recent unverified image and attempt functional acceptance. Then restore the reviewed copy, reconcile, address affected credentials, review field conditions, and test again.
In a separate run, rebuild before preserving evidence. Compare the permanent evidence-loss note in the final debrief.

Discuss: Why is newest not the same as trustworthy? Why do credentials matter after a reimage? What must incident responders and operations decide together?

## Suggested observations
- A responding server and an available controller do not establish fresh values or an authorized return to service.
- Recovering unnecessary components costs time. Missing controller/project files can make a server-only backup insufficient.
- An older reviewed configuration can be a recovery source, but field changes must be reconciled before accepting it.
- In this fictional scenario the recent copy is unverified; this is not a claim that recent backups are inherently bad or that old ones are inherently clean.
- A cyber rebuild can destroy useful evidence. Restoring software does not automatically revoke compromised access.
- The 60-minute RTO is an exercise target. Backup configuration age is not automatically the RPO or actual data loss. Missing historian samples are not recreated by restoring a project.
- The illustrative buffer can be exhausted even when software is eventually recovered. It is not a hydraulic or water-quality calculation.

## Record a debrief
Download the model's exercise review. Identify one unnecessary action, one missing prerequisite, one assumption, and one acceptance criterion you would change for a different vertical. Keep real access details and personal information out of any public worksheet.