Scenario Testing for Cyber Outages

A cyber outage scenario rehearses what a firm does while an attack has made systems unavailable or untrustworthy, before any question of rebuilding them arises. The distinction matters. During an outage, the firm must cope: protect customers, keep essential work moving by other means where that is safe, communicate honestly about what is known and unknown, and avoid actions that could worsen the damage. Recovery, which is covered in a separate guide in this cluster, deals with rebuilding and returning to normal. An outage exercise that jumps straight to restoration skips the hardest period, when information is scarce, pressure is high, and every workaround carries a risk of its own.

A technology fault is usually understood quickly: a component failed, a fix is known, and the remaining question is how long repair takes. A cyber outage is often ambiguous at first. The firm may not know the cause, the extent, or whether systems that appear to work can be trusted. That uncertainty changes decision making. Staff may need to isolate systems, preserve evidence, and treat apparently normal data with caution, all while customers seek answers. Consider an online banking service where login and payments behave erratically after a suspected attack. The scenario should force a decision about whether to keep the channel open, restrict it, or close it, with customer harm weighed on both sides. A fault scenario rarely forces a choice of that kind.

Early decisions in a cyber outage are often about containment, authority and communication rather than technology alone. Who can decide to isolate a system or suspend a channel? Who speaks to customers, and what can be said when the cause is still unclear? How are incident records kept when normal tools are unavailable? An exercise should make those questions unavoidable by withholding information in the early injects and by introducing conflicting reports, such as a supplier saying one thing and internal monitoring suggesting another. Participants should also face the temptation to restore service quickly. A scenario that rewards speed without asking about trust in the restored system teaches the wrong lesson, because a quick return that reintroduces a weakness helps no one.

Customer communication during a cyber outage is a test of honesty under pressure. Customers need to know which services are affected, what they should do instead, and when they can expect a further update, even if the full picture is not yet known. An exercise should rehearse drafting those messages with incomplete facts, and should test who approves them and how they reach customers when a normal channel is down. Counterparts matter too. A payments firm, for example, may need to warn a settlement partner or a correspondent that volumes will change or that files may be delayed. Scenarios that only test internal coordination leave that external dimension unrehearsed, and external confusion then becomes a second incident on top of the first.

Cyber outage scenarios often reveal dependencies that a service map missed. A manual workaround may depend on a spreadsheet held on an affected system, a contact list may live in an inaccessible mailbox, or a supposedly independent channel may share the same identity service as the failed channel. Those discoveries are valuable precisely because they are embarrassing. The exercise should give participants time to try a workaround and discover that it fails, rather than assuming it works because it worked in a previous, smaller incident. Observers should note each failed assumption, because each one becomes a concrete improvement: a printed contact list, an offline procedure, or a clearer rule about when a workaround must not be used.

An outage scenario should end at a decision point, not at a tidy resolution. Useful endings include a decision to keep a channel closed overnight, a decision to invoke a supplier, or a decision to escalate to senior leadership with a recommendation and its risks stated plainly. Ending there keeps attention on judgement rather than on a fictional happy ending. The debrief should then separate three questions: what did the team decide well, what information was missing, and what will change before the next exercise. If the scenario is reused, those changes should be visible in the next version, so participants can see that rehearsal leads to action rather than repetition.