Part 1 of 6
Foundations of Emergency Management
For anyone who has to explain why emergency management is more than the day of the incident: the six phases the work actually runs on, the five federal mission areas they map to, and why the first question is never which software to buy.
Response is the part that is visible. It is one sixth of the work, and the shortest.
Emergency management is more than response
Response is the part that is visible. It is one sixth of the work, and the shortest.
- Risk
Find out what can actually happen here, who it would harm and how badly. Everything downstream is built on this, and it is local.
- Prepare
Build the capability the risk demands — plans, people, agreements, equipment, training — before anybody needs it.
- Mitigate
Change the conditions so the next event does less harm. The cheapest work in emergency management, and the least visible.
- Respond
Coordinate, prioritize, resource and inform, for as long as it takes. Hours for a fire; months for a disaster.
- Recover
Get the community back, and prove what happened well enough to pay for it.
- Learn
Find out what did not work and change something. Without this step the loop is a circle rather than a spiral.
It is continuous. A jurisdiction that only does emergency management when the EOC is open is doing response with extra paperwork.
The five mission areas
FEMA's National Preparedness Goal organizes capability into five mission areas. Preparedness is not a sixth box beside them — it is the work of building capability across all five.
Avoiding, stopping or interrupting a threatened or actual act, most often used of terrorism.
Securing against the threats that cannot be prevented — people, infrastructure, systems.
Reducing the loss of life and property by lessening the impact of what does happen.
Saving lives, protecting property and the environment, and meeting basic human needs once an incident occurs.
Restoring, and where possible improving on, what the incident took.
The core capabilities beneath these are the vocabulary a risk assessment is written in. It is worth knowing them before writing a capability gap into a grant application.
Start with risk, not software
The first question is not "what EOC software should we buy?". It is a set of much harder ones: what can happen here, what would the consequences be, what capability would we need, what capability do we have, and where is the gap?
The formal versions of those questions are the Threat and Hazard Identification and Risk Assessment, or THIRA, and the Stakeholder Preparedness Review, the SPR. The THIRA identifies the threats and hazards a community faces, describes the impacts in concrete terms, and sets capability targets from them. The SPR is the honest half: what can we actually do today, and what would we need to close the difference.
Neither is a piece of software. Both are documents a jurisdiction writes about itself, and both are the argument a purchase later has to fit inside.
The logic underneath it
Eight steps, in this order. Skipping any of them shows up later as a system nobody can justify.
- Identify hazards
What can credibly happen here, drawn from your own record and your own geography.
- Describe impacts
Not "a flood" but how many people, which buildings, which roads, for how long.
- Determine capability requirements
What you would need to be able to do, stated as a target.
- Assess current capability
What you can do today. Honestly, including the parts that depend on one person.
- Identify gaps
The difference between the last two. This is the whole output.
- Build capability
Plans, people, agreements, equipment, training — and sometimes technology.
- Exercise
Find out whether the capability is real.
- Improve
Change something, then go round again.
Risk is local. A neighboring county's assessment is not yours, and neither is a national average.
What to do next
The framework tells you what the work is. The next part is how it is actually run on the day, and where most jurisdictions find their coordination breaks.
Read: Incident Command & EOC Operations