Resilience begins where the emergency plan ends

Demonstration content: the scenario in this article is illustrative, and the analysis is not reporting on a current event. It is designed to show the kind of policy work Stratium publishes.

Emergency plans often begin with a clear event: a storm, a cyber incident, a transport disruption. Real pressure rarely respects those boundaries. A power interruption can affect communications; a communications outage can complicate logistics; and a delay in logistics can turn a manageable shortage into a public confidence problem.

From hazards to dependencies

The useful question is not whether a planning team can predict the exact sequence. It is whether essential services can continue when several assumptions fail together. That changes the focus from a list of hazards to the connections between systems, decisions and people.

A practical review can start with three prompts. Which service must continue even in a degraded mode? Which outside dependency has no ready substitute? Who has authority to make a decision when normal reporting channels are unavailable? Answers should be tested with the teams who would have to act, not only recorded in a plan.

A plan is only as resilient as the handoffs it has actually tested.

Exercises should also leave room for uncertainty. A short tabletop scenario can introduce new information gradually and ask participants to explain what they know, what they do not know and what would change their decision. The aim is not to reward confident guesses. It is to make handoffs, thresholds and communication gaps visible.

Turn plans into tests

Resilience is therefore less a promise that disruption will not happen than a measurable ability to absorb it, adapt and restore critical functions. The strongest plans make that ability specific: named owners, clear fallback arrangements and a calendar for testing whether those arrangements still work.

• Name the service and its minimum operating level.
• Record the dependency, owner and credible fallback.
• Set a threshold for switching to that fallback.
• Rehearse the handoff and assign corrective actions.

That calendar matters because dependencies change. A supplier may alter its service, a team may lose a specialist, or a new digital process may become essential to a previously manual task. A plan that was credible last year can quietly become an inventory of assumptions. Owners should record when each dependency was last checked and what evidence supports the fallback.

The exercise should include the people who receive the service as well as those who operate it. A technically successful workaround may still exclude people who rely on a particular channel, language or accessibility feature. Asking who is likely to be affected, how they will be told what is happening and how feedback reaches decision-makers makes continuity more than an internal operations metric.

Make the trade-offs visible

A useful after-action review converts observations into accountable work. Each action needs an owner, a due date and a test that shows whether the gap has closed. “Improve coordination” is not a test; “the duty team can reach the named counterpart using the fallback directory within the exercise window” is. Repeating the scenario later reveals whether the organisation learned or merely documented the lesson.

For leaders, the central choice is how much redundancy to fund and where. Duplicate every capability and costs become unsustainable; assume every dependency will be available and a single failure can cascade. Mapping critical services, plausible failure paths and recovery priorities helps make that trade-off explicit. It also gives the public a clearer account of what continuity means and what it cannot guarantee.

This illustrative framework is not a prediction or an assessment of a named institution. Its purpose is to demonstrate how a reader can move from a broad promise of resilience to testable responsibilities, decision thresholds and evidence of readiness.