Part 4 of 6
System Resilience & Technology Evaluation
For anyone choosing a platform, or wondering what happens to theirs when the power goes: how to plan for the system being part of the disaster, and the five sets of questions to put to a vendor before the ones about price.
Emergency management technology is bought on the assumption that it will be available. Ask the question the other way round.
What if your system is part of the disaster?
Emergency management technology is bought on the assumption that it will be available. Ask the question the other way round.
- The EOC is inaccessible — where do you coordinate from, and does anyone know?
- Your network is down — what still works?
- CAD is unavailable — how do you keep an incident record?
- Cellular networks fail — how do you reach your own people?
- Commercial power is gone — for how long can you run, and on what?
- Your cloud vendor is fine but your jurisdiction has no internet — which is the more likely failure
- Half your trained staff cannot report — who is second, and third?
- A critical vendor is unavailable — what is the manual process, and has anyone done it?
- Alternate facilities are identified, reachable and equipped
- Essential functions are written down and prioritized
- Orders of succession and delegations of authority exist in writing
- Critical documents exist on paper, current, somewhere reachable
- Data is backed up somewhere the same disaster cannot take
Worth being blunt about
If your emergency management system only works under normal conditions, it is not an emergency management system.
What technology needs to solve
These are the operational problems departments and emergency managers actually describe. Each opens onto the approaches that address it, and the products listed here that claim to.
We are running an emergency operations center on phone calls, whiteboards and spreadsheets
The picture in the EOC, the picture in the field and the picture at the partner agency drift apart within hours, and reconciling them consumes the staff who should be making decisions.
We cannot track resource requests and mutual aid at scale
Requests are made by phone and remembered by the person who made them, so nobody can say what was ordered, what arrived, what it is doing now, or what it has cost.
We cannot reach the public with something they will act on
A warning that reaches the wrong area, arrives in one language, or reads as routine gets ignored, and the next real one is ignored with it.
Damage assessment and reimbursement records get assembled after the fact
Recovery money turns on documentation nobody was collecting while it mattered, and the department carries costs it could have recovered.
Our plans exist, but nobody can find the right one during an incident
The emergency operations plan, the annexes, the mutual aid agreements and the contact lists are written, approved and filed somewhere nobody can reach at two in the morning. The people who wrote them are not the people who need them.
We cannot say which community lifelines are unstable
The reporting describes which agencies are busy rather than what the community has lost. Leadership is told about activity when the decision in front of them turns on whether people have power, water, a road out and somewhere to go.
We cannot run the emergency operations center if the building is unavailable
The plan assumes a room. When that room is flooded, without power, inside the evacuation zone or simply unreachable, the coordination that room was doing stops, and it stops at the moment it is most needed.
We run exercises, but the corrective actions disappear into a report
The same finding appears in three consecutive after-action reports because nobody owned it, nobody was given a date, and nothing verified that it had been done. The exercise proved the plan rather than testing it.
Worth being clear about
Technology should reduce coordination friction. It should not simply digitize existing confusion.
A jurisdiction that cannot say who decides what, or where its resources are, will have those problems faster and in a nicer interface. Doctrine, process and people first; the product supports them.
Evaluating a platform: interoperability
The questions that decide whether a system helps you work with other agencies or quietly requires them to become your customers.
- Can outside agencies contribute without buying the same software?
- Can information be exported, in a format something else can read?
- Does it support an API, and is it documented?
- Can it ingest the data formats you already have?
- Does it integrate with your GIS?
- Can somebody view information without becoming a full administrator?
Evaluating a platform: operations
- Can it track a resource request from request to demobilization?
- Can it support multiple operational periods?
- Can it maintain an event log that survives an audit?
- Can it track unresolved issues, rather than only completed ones?
- Can it support community lifelines — all eight?
- Can it run more than one incident at a time?
- Can it support EOC status boards the way your EOC actually works?
- Can plans and attachments be reached quickly, under pressure?
Evaluating a platform: resilience
- What happens when internet service is lost?
- Can it be run from an alternate location?
- Does it work on a phone, in the field, on a bad connection?
- What is the vendor's own continuity architecture?
- Can information be exported or printed before you need it?
- Can operations degrade to paper without losing the incident record?
Evaluating a platform: security
- How do people authenticate, and is multi-factor available?
- Are permissions role-based, and fine enough for partner agencies?
- What is logged, and for how long?
- How are backups taken, and have they been restored?
- Is data encrypted in transit and at rest?
- What is the data retention policy, and who owns the data?
- Who at the vendor can see your data, and under what circumstances?
- What is the vendor's own incident response process?
- What availability is committed to, and what happens when it is missed?
Evaluating a platform: public information and recovery
- Can public information workflows reach several channels at once?
- Can warnings be geographically targeted where that is appropriate?
- Can accessible and multilingual content be produced and sent?
- Can expenses be documented as they are incurred?
- Can damage assessments be attached to a location?
- Can photographs and supporting documents be kept with the record?
- Can records be exported for reimbursement and audit?
The question that decides it
Can a city employee who works in the EOC twice a year actually use it?
Every other question on this page matters less than this one. A system that only the two people who configured it can operate has not increased your capability; it has concentrated it.
What to do next
Buying it is not the end. The next part is how a jurisdiction finds out whether any of this works before an incident tells it.
Read: Learning, Exercises & Documentation