Scenario Testing for Cyber Recovery

A cyber recovery scenario rehearses how a firm rebuilds after a cyber attack, verifies that what has been rebuilt can be trusted, and returns a service to normal in stages. Recovery is distinct from coping during an outage, which is covered in a separate guide in this cluster. During recovery, the questions change: which systems are clean, which data can be trusted, what order of restoration reduces harm, and when is it safe to invite customers back? A scenario that treats recovery as restarting systems in their previous state misses the central risk, which is restoring the very weakness that allowed the attack, or restoring data that remains corrupted. Recovery testing therefore emphasises verification and sequencing over speed alone.

Rebuilding cleanly involves creating an environment that is known to be free of the attacker's presence, rather than assuming that a cleaned version of the affected environment is safe. The scenario should force decisions about which components are rebuilt, which are restored from a known good source, and which are left out until they can be checked. Consider a customer onboarding service that was affected by malware in its document handling system. Recovery might involve rebuilding that system, restoring customer records from a source taken before the attack, and checking integrations before reconnecting to other services. Each of those steps needs an owner and a check, and the scenario should make participants explain why each step is trusted, rather than accepting a general assurance that the environment is clean.

Verification is tested by asking how the firm knows that rebuilt systems and restored data are correct. Checks might include comparing records against an independent source, testing key functions with known inputs, monitoring for signs of the attacker's return, and reviewing logs for activity that should not be there. The scenario should include a result that is ambiguous, such as a check that mostly passes but leaves a small discrepancy, so participants must decide whether to proceed, to investigate further, or to delay return. That decision is the heart of recovery testing. A team that always proceeds on a mostly clean result may be prioritising speed over safety, while a team that never proceeds may leave customers without service longer than necessary. The exercise should surface that trade off explicitly.

A staged return means bringing a service back gradually, watching for problems at each stage, rather than restoring everything at once. Stages might be defined by customer group, by function, or by volume, depending on the service. The scenario should ask who decides to move to the next stage, what evidence is required, and what happens if a problem appears after a stage has begun. For a payments service, for example, an early stage might restore internal processing while customer channels remain restricted, so that transactions can be checked before customers rely on them again. Participants should also rehearse the decision to pause or reverse a stage, since a return that cannot be paused is not controlled. Staging is slower than a single restart, but it limits the harm if recovery proves incomplete.

Customers during recovery need a different message from customers during an outage. During an outage, the message is about impact and alternatives. During recovery, the message is about what has been restored, what remains restricted, and what customers should check, such as reviewing recent transactions or re-entering information that could not be recovered. The scenario should rehearse those messages with care, because premature reassurance can cause customers to act on data that is still uncertain. Staff also need guidance for customers whose records remain affected, including how cases are tracked until resolved. Recovery communication that is honest about remaining limits will feel less satisfying than a simple announcement that service is back, but it is more trustworthy and more useful.

A recovery exercise should change the recovery plan in concrete ways. It might revise the order of restoration, clarify who can approve a return to normal, add a verification check that was missing, or improve the clean environment so that rebuilding is faster next time. Each change should be linked to a finding from the exercise, such as a check that took longer than expected or a dependency that was discovered during rebuilding. The exercise should also record what was not tested, such as a system that was assumed clean without verification, so the next exercise can cover it. Recovery capability improves through that cycle of testing, finding, changing and retesting, and a single successful recovery exercise should never be treated as proof that the next real recovery will succeed.