By now, we’ve all heard how the citizens of Hawaii were awoken on Saturday, January 13^th with a (thankfully erroneous) alert telling residents to take shelter because of an incoming ballistic missile.

While the investigations and government hearings will continue, now that we’re a couple of weeks removed from the event, it’s important to take a step back and use this opportunity to crystallize several mass notification best practices.

If you’re in charge of administering an emergency management system in the days following Hawaii you no doubt were asking yourself (or were asked by your superiors) about whether a false alarm could happen in your community, and if you’ve taken the proper precautions.

While Hawaii specifically seems to be a combination of system design and human errors, there are actions we can all take to mitigate the risk of user error and make it easier to quickly send out corrections:

Know Your System Design and Procedures

The design of your emergency management system matters. The best system is one that is easy to use but not easy to err.

The system needs to be intuitive to use. People need to be able to understand how to operate it and quickly gets messages out under pressure. The discussion around Hawaii has been about getting the right message out but this does not negate the need for speed. Many situations, such as tornadoes, provide little time to notify people before the onset of the event. Pre-defined notification templates can enable standard processes to be quickly followed.

With some reports indicating that delays in obtaining proper authorizations extended the time it took for Hawaii to correct the alert, it’s easy to see why your process needs to be clear and concise. Pre-determine who can authorize a correction and what the chain-of-command is. Use scheduling information and escalation procedures built into the notification system to rapidly contact the responsible people. Incorporate false messages and corrections into your testing schedule so that if there is an instance of a false alarm there is no time wasted figuring out how to retract the message.

Build in Safeguards

You can employ safeguards to lower the risk that a wrong message would be accidentally sent broadly over Wireless Emergency Alert (WEA) or Emergency Alert System (EAS) networks. These include:

1. Separate Live and Test Modes – Have distinct Test and Live modes, where both the controls and the look and feel are different. This will help operators quickly recognize that they are in one mode versus the other. Have the Test mode be the default and require an active switch to Live mode to send a real message widely.
2. Build In Access Controls – Set the system up so the administrator controls exactly who has permission to utilize WEA and EAS and to send out a live message.
   1. Require Credentials – Don’t allow operators to store logins or IPAWS credentials. To send out a live message over IPAWS channels, including WEA and EAS, require the operator to enter in IPAWS credentials each time. This, along with system log-in credentials, provides a two-factor authentication requirement which lowers the risk of an unauthorized person accessing the system. Requiring the entry of IPAWS credentials also adds another process step before sending a live message: one problem encountered in the Hawaii incident was that it apparently was too easy and rote in the system that was used to just confirm that the erroneous message should be sent.

Test and Test Again

Organizations should not take the wrong message from Hawaii: they need to continue to conduct drills. It’s what the folks in Hawaii were trying to do – to test the system and make sure they knew what to do in an actual emergency. In fact, the takeaway should be to increase the amount of testing. Training, preparation and repetition is the best way to ensure things go smoothly when there’s a critical event taking place. Additional testing may have helped Hawaii to execute a plan for how to cancel an error message or send an immediate follow up in case of an error, which would have reduced the 38 minutes lag time.

The best ways to avoid potentially disastrous errors is to be prepared: know your system, adjust it to limit human error, train your people and ensure that you’ve not only planned for every eventuality, but also then followed through with testing for each. It’s a delicate balance – instilling safeguards, but also ensuring the system can be used quickly and easily during a critical event – but one that must be achieved by every community to ensure public safety.