Emergency messages or notifications are common means by which organizations, states, and even countries inform their members of critical incidents that may affect their safety and security. In the best cases, these messages are prompted by credible and reliable information about a potential future attack—and therefore are left of bang. In the worst cases, these messages let people know of an attack that has already occurred but may still affect their safety. Recently, I was sent an emergency message by a campus that I’m associated with; a message that spurred my thoughts about how to effectively inform people of potential safety and security risks. I have removed location specific information. I received the following message via email in January of this year:

“Suspicious activity was recently reported to [the] [c]ampus. [Local] Police officers patrolling the [c]ampus have said this is a very low-level threat.

We are continuing to monitor the report of this suspicious activity and will update you with more at a later time. This is a good reminder to be aware and to report any suspicious activity to xxx-xxx-xxxx.”

The above message was all that was sent out by the organization’s security department. I would like to take a look at this brief message to discuss how to effectively inform people of emergency situations so that they can stay safe and make good decisions.

While it may not be clear, this is a left of bang message. Nothing had happened yet; only someone had been reported to security officials that something may happen. With that in mind, let’s take a look at the language of this message.

The first thing that should be evident is the obvious ambiguity in the message: “Suspicious activity was recently reported to the campus.” What was the suspicious activity? Who reported it? To whom was it reported? When was it reported? None of these questions can be answered by this message. The phrase “suspicious activity” is a meaningless phrase that should be erased from everyone vocabulary. The term “suspicious” may be useful in a casual conversation between two people that share the same context and are observing the same thing. For example, if two people are standing in a store and observe someone in a coat that doesn’t fit the season or current weather, and the person wearing the coat is constantly looking around while reaching into the coat, then one of the observers may say to the other, “That person looks suspicious.” This would be perfectly legitimate in this situation. Both individuals are observing the same behavior, have the same point of reference, and intuitively know what the word “suspicious” means in this context. However, in an emergency message, the term “suspicious” is absolutely uninformative.

Instead of using vague and ambiguous phrases such as “suspicious,” security personnel crafting emergency messages should be as specific as possible. For example, this message could have stated: “It was recently reported to campus officials that an 5’5” Caucasian adult male had recently walked through campus looking into the windows of residential housing.” This was not what actually occurred on the day I received the emergency message, but it does give an example of what a message could look like. People need to know what they should be looking for, and vague and general terms like “suspicious” does not increase anyone awareness one iota.

The second thing that stands out is the vagueness of when the incident occurred or was reported. The message only says “recently,” and the word “recently” refers to when the “suspicious activity” was reported, not when it occurred or will occur. But again, this type of vague language is unhelpful. Recently to you may not be recently to me. Whoever crafted this emergency message may have meant that the report was received yesterday, this morning, or even five minutes ago. But no one who received this message had any way of knowing when the report was received, let alone when the incident happened. It should be evident that any emergency message should not only specify when a report was received, but when an incident occurred, or may occur (according to the report or the security officials’ best analysis). Based on this, we could rephrase my fictitious example as such: “At 10:38am, it was reported to campus officials that an 5’5” Caucasian adult male had had been walking through campus around 10:00am looking into the windows of residential housing.” Here we’ve provided a little further information to give people better situational awareness, and to help them determine whether or not they were in the area around that time and could provide further information. In addition, people should also have enough information for them to decide if the threat or situation is still a risk.

A third thing that stands out is the phrase “low-level threat.” My immediate thought when receiving this is, what is a low-level threat? Did they mean a tripping hazard? A guy with a hockey stick threatening to slash people’s shins? Of course, I am being sarcastic, and a reasonable person may assume that by low-level threat this emergency message meant a threat that did not pose immediate or grave danger to individuals in the area. But this is only an assumption on my part. The vagueness and ambiguity in this phrase—in this message as a whole—is counterproductive. More questions are raised than are answered.

What is the nature of threats? Can a threat be “low-level”? Certainly, if “low-level” is well-defined and if everyone that receives an emergency message knows exactly what “low-level” means. However, I would argue that the phrase “low-level threat” should also be erased from our lexicons, just like the word “suspicious.” How then should threats be described?

I would categorize threats in several ways: time (chronological proximity), specificity, location, and type.

  • Time: Threats can be imminent or distant. By that I mean a threat can be an immediate risk or a future risk. If an event is occurring now, then it is “current.” If an event is likely to occur within the next hour or day, then it may be classified as “imminent.” And if an event is not assessed to occur in the immediate future (day or several days) then it is “distant.”
  • Specificity: Often security officials may not have any more information that what is reported. However, emergency notifications should be clear about whether or not the report was specific or general in the type of threat being reported. If it were reported that “two adult males in black coats were reported to be carrying assault rifles” then this would be a specific threat. Sometimes, however, only general information may be available, such as the all-too-common “suspicious package.” General information is not bad, but reports and emergency messages should provide information that is specific as possible. There is a significant difference between “individuals are threatening to shoot college professors on the main campus today” and “individuals are threatening to harm people at the school.”
  • Location: This is fairly self-explanatory; however, threats should be considered from the perspective of spatial proximity (location) in addition to chronological proximity (time). Is the threat against a specific building, neighborhood, or area?
  • Type: Of course, there are as many types of threats as there are weapons and ways to harm people. Types may include shooter, bombing, crime (burglary, rape, theft, assault), violent protest, fire, etc. When sending out an emergency notification, security officials should be as specific as possible in this category also, based on the information they possess.

Lastly, because security officials often receive tips and reports about potential threats, we should also assess and classify the nature of the report. Is the report credible or un-reliable? This may be difficult to assess, unless the person taking the report knows the person giving the report. Often, intelligence officials are able to classify information they receive because their assets have a history of reporting. Some intelligence assets are reliable, and consistently provide credible information, while others may only provide credible leads fifty-percent of the time. However, regardless of a sources history, each report should be assessed on its own. Security officials taking the report should ask: Is the source specific? Are they confident in their report? Is there conflicting or contradictory information? Numerous other questions could be asked to assess the reliability of a lead. But this could also be included in an emergency notification so that people can use their own judgment to determine how they should respond.

Returning to the emergency notification I received, there is no way for any of the recipients to know what “low-level threat” meant. Again, it was a meaningless term. A number of other issues could also be raised with this report. For example, there was no recommendation as to how people should respond. Should the recipients stay away from campus? Should they continue to work as usual? What should they do if the threat proves real, rather than “low-level”?

All this to say, any useful emergency notification should be as specific as possible. Of course, an effective emergency message should also be short and to the point. The longer a message is, the less likely that people will read it. Additionally, if emergency messages are sent via Twitter or text message, they are limited to about 140 characters. That is not a long amount of space to provide accurate information. Security officials must balance specificity with character-limits (and reader attention spans). However, the more specific the better. General, vague, and ambiguous notifications will confuse people and will not help people get and stay left of bang.

An example of an emergency message template is on the Department of Homeland Security website (http://www.dhs.gov/xlibrary/assets/ntas/ntas-sample-alert.pdf). It borders on giving too much information, but may help security officials think of the type of information that their own emergency notifications should provide.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *