Resilience begins where the emergency plan ends
DEMO ANALYSIS — An illustrative look at how public institutions can prepare for several pressures arriving at once.
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.