Before Restart, Ask What You Can Actually Prove

This checkpoint connects four ideas already established about ransomware recovery in manufacturing: a copy can be available without being trustworthy, a mission depends on more than its visible applications, an identity can authenticate without being safe to reuse, and evidence must support the restart decision. The practical judgment is whether a proposed restart has crossed from “technically possible” to “defensible enough to consider,” before live production or physical-process reconnection is attempted.

The distinction matters because recovery teams often work under pressure to show progress. A recent backup, a rebuilt application, or a functioning login creates a visible sign of movement. But a sign of movement is not the same as evidence that the selected production mission can be supported. The checkpoint is therefore not another inventory. It is a way to test the combination of copy, dependencies, identities, and evidence as one recovery decision.

Five questions before a restart

Start with the candidate mission, not with the most convenient machine. A plant might want to resume one product family on one line for a limited period, while the rest of the enterprise remains under investigation. That is a narrower question than “Can the factory be restored?” It gives the team something specific to test: what output is intended, which quality conditions apply, what duration and throughput are acceptable, and which relationships must hold for the mission to be valid.

The first question is availability. Is the required component reachable and usable at all? The answer may concern a data copy, a service, an identity path, a workstation, a storage mapping, or a communication link. Availability is the most visible state, but it is only the first gate. A service that responds to a request is not necessarily a service that should be used in production.

The second question is trust. Is the component believed clean and uncompromised enough for the mission? For a restore point, that includes its compromise window, content hygiene, baseline relationships, and consistency with the other data the mission needs. For an identity, it includes the possibility that credentials, tokens, privileged accounts, or administration paths were exposed. For a network relationship, it includes whether the path is real and controlled rather than merely present on a diagram.

The third question is evidence. What supports the trust claim? The team may have logs, a forensic timeline, a test restore, configuration comparisons, scan results, credential-reset records, or a documented account of assumptions. Evidence does not turn uncertainty into certainty, but it makes the basis for the judgment inspectable. Without it, responders may rely on intuition, habit, or the reassuring fact that a system appears to work.

The fourth question is operational approval. Even a component that is available, trusted, and supported by evidence may not be approved for the proposed use. A quality stakeholder may need to confirm that the records and checks are sufficient. An operations or safety authority may need to approve the conditions under which a system can participate in the mission. The approval is not a decorative signature; it states that the component’s current state is acceptable for a defined operating purpose.

These states are related but not interchangeable. A backup can be available but untrusted. A clean restore can be trusted in isolation but unsupported by enough evidence to justify its use.