The Evidence-Based Path From Restore to Resumption

This chapter turns Minimum Viable Factory Recovery from a decision idea into a lifecycle for moving from disruption to monitored production. The focus is how each transition changes what the team must know: first the production impact, then the dependency set, then the clean state, then the mission scope, and finally the evidence and gates for resumption. Readers should be able to use the lifecycle to organize recovery reasoning without mistaking it for a universal procedure or a replacement for incident response and safety engineering.

A lifecycle is useful because recovery conditions change. A preplanned mission can become impossible when a backup is found to be contaminated, an identity path is shown to be compromised, a supplier becomes unavailable, or a safety assumption cannot be validated. The reverse can also happen: a narrower mission may become feasible before full enterprise restoration. The lifecycle keeps the decision tied to current evidence rather than to the first recovery plan written before the incident.

From impact to a candidate mission

The first stage is mission impact assessment. Instead of beginning with a list of encrypted or unavailable systems, responders identify which production missions are disrupted. That includes product lines, batches, order types, quality processes, supplier flows, logistics steps, and customer commitments. The goal is not to ignore the infrastructure outage. It is to translate the outage into consequences that can guide recovery priorities.

This distinction changes what “critical” means. A server may be technically important but irrelevant to a selected short-term mission. A less prominent service may be essential because it supplies the identity, recipe, quality, or supplier information that the mission needs. Impact assessment gives the team a reason to choose one production objective over another and prevents the recovery effort from optimizing for the most visible asset.

The second stage is dependency modelling. For each candidate mission, the team builds the graph described earlier: IT systems, OT assets, identities, data, people, manual procedures, materials, suppliers, and logistics. The graph should include hidden relationships such as service accounts, time synchronization, engineering workstations, certificate services, remote vendor access, historian feeds, and quality-release data when they are relevant to the mission.

The point of the stage is not to produce a diagram that looks complete. It is to identify the conditions that must be satisfied together and the state of each relationship. A dependency can be available, untrusted, evidenced, approved, or absent. It may have an approved substitute, or it may be a hard blocker. The graph is valuable when it changes the next decision: which copy to select, which identity to rebuild, which path to test, or which mission to narrow.

The third stage is clean-state selection. Responders compare possible restore sources and configurations using evidence rather than recency alone. They consider the suspected compromise window, malware persistence, credential exposure, data consistency, dependency compatibility, backup age, and operational suitability. The choice should be documented because later validation and production resumption depend on what the team decided to trust.

This stage is where storage recovery and mission recovery meet. A copy that is technically restorable may be rejected because its baseline is not independent, its associated identity state is compromised, or its data cannot support the selected product. An older copy may be considered if it has stronger evidence and the mission can tolerate the data gap. The lifecycle does not declare one option universally correct. It makes the reason for the selection visible and testable.

The fourth stage is MVF planning.