OperationalResilience.help
The Continuity Desk - important services, kept running
Home / Line 19 - Scenario testing and exercises / Guide

Scenarios for Emerging Risks

How to build provisional scenarios for risks that are new, uncertain or only partly understood, using weak signals, plausible chains and regular revision.

Published 26 October 2026Checked against the regulation text on 26 October 2026Regime-dependent: EU under DORA, UK under FCA/PRA, labelled in the guide

The short answer

Emerging risks are risks that are new, fast changing, or only partly understood, and scenarios for them must be provisional by design. The firm cannot wait for complete understanding before rehearsing, because the risk may affect a service before understanding catches up. A provisional scenario therefore states what is known, what is assumed, and what would change the story, and it is revised as new information arrives. Its purpose is not prediction. It is to test whether the firm can recognise an unfamiliar disruption, make decisions with incomplete information, and adapt as the picture clarifies. A scenario that pretends to certainty about an emerging risk will mislead participants more than one that admits uncertainty.

What counts as a weak signal?

A weak signal is an early indication that a risk may be growing, before it has become a clear incident pattern. Signals can come from incidents at other firms, from supplier disclosures, from changes in technology use, from geopolitical or environmental developments, or from internal observations such as a new dependency that nobody fully understands. Consider a service that begins to rely on a new form of automated decision support. Early signals might include supplier changes, model behaviour that staff find hard to explain, or incidents elsewhere involving similar tools. None of those signals proves a future disruption, but together they justify a scenario that asks what the firm would do if the tool produced unreliable outputs at a critical moment.

How is a provisional scenario built?

A provisional scenario is built by tracing a plausible chain from the emerging risk to harm for one named service, even when some links in the chain are uncertain. The writer should name the service, the dependency, the mechanism of harm, and the decisions the scenario is meant to force, and should mark assumptions clearly so participants can challenge them. The scenario should include a point at which new information arrives and changes the picture, because emerging risks rarely stay static during a disruption. That twist tests adaptability, which is the skill such scenarios are meant to build. The scenario should also avoid inventing precise detail where none exists; a story that invents a cause with false confidence will be dismissed when the real risk arrives in a different form.

How are participants helped to work with uncertainty?

Participants in an emerging risk exercise need permission to say that they do not know, and a structure for deciding despite that. The facilitator can help by asking what information would change the decision, who could provide it, and what interim action is safe while waiting. The exercise should also test escalation: at what point does an unfamiliar problem become a senior leadership problem, and who makes that call? Those questions matter because emerging risks often fall between teams, with each team assuming another owns the problem. An exercise that surfaces that ownership gap has done valuable work, even if the scenario itself never occurs. Participants should leave with a clearer sense of who owns unfamiliar risks, not only with a story about one of them.

How are emerging risk scenarios updated?

Emerging risk scenarios should be updated whenever understanding changes, whether through new incidents, new supplier information, new guidance, or experience from an exercise. Updating may mean revising the mechanism of harm, adding a new dependency, changing the decisions the scenario forces, or retiring the scenario because the risk is now well understood and belongs in the main library. The update should be recorded, so that facilitators know which version they are using and why it changed. A scenario that is never updated will either become outdated or will be treated as a permanent prediction, both of which undermine its purpose. Regular revision is not a sign that the original scenario was wrong; it is a sign that the firm is learning.

What are the limits of emerging risk scenarios?

Emerging risk scenarios have limits that should be stated plainly. They cannot cover every new risk, they cannot predict timing or form, and they can create false confidence if participants treat a rehearsed story as the expected story. Their value lies in building general capabilities: recognising unfamiliar harm, deciding under uncertainty, communicating honestly, and adapting a plan. Those capabilities transfer to risks that were not rehearsed, which is the point. A firm should therefore judge its emerging risk work by whether those capabilities improved, rather than by whether a particular scenario later came true. A scenario that never occurs but leaves the firm better able to handle surprise has succeeded on the terms that matter.

Primary sources on the record

Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.

Follow the service map

Line 19 - Scenario testing and exercises Scenario Testing and Exercises How scenario testing turns a disruption story into decisions, rehearsals and changes, so an important service can be kept running or restored within its tolerance. Line 19 - Scenario testing and exercises Scenario Testing for Cyber Recovery How cyber recovery scenarios test rebuilding cleanly, verifying integrity, and returning to normal in stages, rather than simply restarting affected systems. Line 19 - Scenario testing and exercises Designing Severe but Plausible Scenarios How to design a scenario that is severe enough to breach tolerance yet plausible enough to be believed, using the service, its dependencies and its history as the test.