Anyone who has spent time in emergency management understands that the public’s attention to risk is often either non-existent or fleeting. It takes disaster on a large scale to gain attention and that attention is usually accompanied by demands for swift corrective action in the immediate aftermath which is in turn followed by apathy as the disaster fades into history. This is particularly true of disasters that have a low frequency of occurrence but a high potential impact.
Consider, for example, the Y2K crisis of distance memory. Also referred to as the millennium bug, the problem was caused by computer coding that failed to account for changing the first two digits in a date from 19 to 20 at the turn of the century. The problem was known well in advance and there were numerous missed opportunities to correct it. However, it wasn’t until a year or so before the event that the problem became a widespread crisis, with predictions of catastrophic failures of computer systems leading to the apocalypse. A lot of effort went into last minute planning by emergency managers to help allay public concern. However, within a matter of months all the lessons learned about system interdependencies, critical points of failure, and the need for parallel systems were forgotten.
This tendency of the public to create what is sometimes called the disaster “flavor of the month” poses considerable problems for emergency managers. On the one hand, the nature of the disaster is usually real, albeit often exaggerated to epic proportions and there is a responsibility to respond to a concerned public. On the other hand, with limited resources and competing priorities, emergency managers cannot afford to focus all their resources on a single threat. But how then do you balance these two challenges?
To answer that question, consider the latest flavor of the month, the recent CrowdStrike debacle. The cybersecurity upgrade that created what is most likely the biggest IT failure in history has raised the issue of cybersecurity with the public to extremely high levels and it’s likely that we will see a demand for action on the part of emergency planners. The question is, “How much of this problem do emergency managers own?”
To begin, we need to consider that various issues raised by the crisis, much of which are still being learned. There is the immediate response which is requiring a significant effort on the part of IT departments to manually remove a corrupted file from thousands of individual computers. This clearly in the purview of the IT department. But many organizations also responded by switching to manual systems. Others had never invested in the training and materials needed to do so. One can argue that identifying the need for such systems and encouraging their development is clearly something with which emergency managers could assist, even if the actual development and testing of such systems are the responsibility of the affected organization.
This is the first lesson in “planning for everything”: Recognize who owns the problem. Emergency managers don’t have to do it all but can provide guidance and resources. We can point out problems and suggest solutions. We can assist in the formation of workgroups or taskforces. We can also hold people accountable through workplans and operating agreements.
The CrowdStrike failure highlighted the interdependence of critical infrastructure. This is exacerbated by the fact that something like 85% of the critical infrastructure in the United States is privately owned, making the transfer of information difficult. This means we may not always recognize this interdependence until a crisis occurs. This points to another lesson for planning: think strategically. It is easy to view threats from a purely local level but recognizing interdependencies can allow you to prepare for crisis and provide early warning before a problem arises. Remember that disasters have ripple effects and that events in occurring in locations far removed from your organization can have profound impacts. Consider, for example, the far reaching effects on local economies caused by the terrorist attacks on September 11th.
More importantly, however, is the recognition that emergency managers do not deal in specific hazards but rather in the consequences of those hazards in relation to an organization's vulnerabilities. For example, had the CrowdStrike failure affected a municipal water supply’s SCADA system, the result would clearly be an emergency management issue. But a cybersecurity attack, a terrorist attack, or an earthquake could produce the same issue. We plan for consequences, not hazards. This is your third lesson in planning for everything: focus on consequences. This is emergency management 101: all hazard planning means planning for response generated needs that remain relatively constant in all disasters. In other words, plan for consequences. Planning for agent generated needs that vary with the specific disaster is more strategic in nature and more like contingency planning.
We really can’t plan for everything, but we can plan for the things that are common to all disasters. To do that, we need to share the load by making use of the broader planning community and recognizing that emergency management is not a discrete process but a distributed one that should involve all members of an organization.
Comments