INSTA-LEADS: Our Full-Service B2B Marketing Program Delivers Sales-Ready Leads Click to Learn More!
Welcome Guest | Sign In

Don't Panic: Accounting for Human Nature in IT Disaster Response

Don't Panic: Accounting for Human Nature in IT Disaster Response

IT managers often account for possible panic among personnel when they plan out disaster preparedness scenarios. However, the opposite of panic can be just as bad. In order to act fast when fast action is necessary, an IT staff should be given instructions on how to verify that the alarm bells really do mean business.

By Ed Moyle TechNewsWorld ECT News Network
04/18/08 8:30 AM PT

Ever heard that story about the mother who lifted the car off of her son? I thought it was an urban legend until I looked it up. But apparently it's true: In 1982, Angela Cavallo saw her son being crushed by a 1964 Impala. Seeing that happen brought Angela to a state of panic so severe that she (temporarily) gained superhuman strength -- enough strength necessary to lift the car off her son.

It's called "hysterical strength" -- tremendous strength brought about by severe stress. While hysterical strength is still not fully understood by the medical community, is thought to be an extension of the "fight or flight" reflex we all feel as a result of emergency situations.

In other words, it's panic -- and it's good.

In fact, panic is critical to our survival as a species. Panic comes about as a response to emergency situations. For example, imagine a gazelle seeing a lion on the horizon. For the gazelle, a heightened level of readiness to flee is an absolute must. The panic brings about an immediate adrenaline response -- a higher level of blood oxygenation, heightened awareness, accelerated heart rate and numerous other changes to get it ready for action. In the case of the gazelle, the changes facilitate evasion from the lion with (sometimes) lifesaving consequences. In humans, it can give us the strength to pick up a car.

One Side of the Coin

I'm bringing this up because it is imperative that we, as IT managers, account for the impact of panic as we lay out our plans for disaster preparedness and incident response. Specifically, IT managers tasked with putting together responses to natural disasters like earthquakes, fire, flood and plague and for putting together response to security incidents like hackers and industrial espionage need to realize that panic can be -- and oftentimes is -- a factor.

To minimize the impact of panic, it is important to keep emergency-related plans (usually incident response and disaster preparedness plans) as simple as possible. It's also important to thoroughly document the plans, test them and keep employees well-trained in their execution. The more familiar that employees are with the plan, the less likely they are to deviate from it in the heat of the moment. In addition, the simpler a plan is, the easier it is for personnel to take appropriate action without wasting time. After all, we want our employees thinking with a clear head when a disaster or security incident occurs, and rational thinking in an emergency situation can make the difference between keeping our business afloat and having our business go under.

Preparing for panicked employees in an emergency situation is by no means novel, and you may have heard some of this before. You may have already gone through numerous planning situations where we attempt to ensure that employees keep a level head when the time comes. Maybe you've conducted exercises to see what impact panic might have on your employees and then taken steps to mitigate that impact. For those that have already taken steps to mitigate panic, that's a useful first step -- but we need to carry it one step further. Because, while panic is a natural response to emergency situations, not every emergency situation immediately evokes panic.

There's Another Side

There's another variable in the equation. It's one that's equally damaging to the proper execution of well thought-out plans, and it's seldom, if ever, accounted for in incident response and disaster preparedness plans. Specifically, it's the need for individuals to verify the event before they take action.

Experts who study the behavior of individuals during emergency situations tell us quite a different story about how people act in certain types of emergency situations. They tell us that there are certain situations in which individuals don't panic. In fact, quite the opposite -- they might not take any action at all. For example, think about the last time you were in a public place when there was a fire alarm. How did people react? How many people immediately moved to the exit? How many people stayed where they were and didn't take any action? How many people milled around looking for further guidance about how to proceed next?

When presented with a situation like a fire alarm, most individuals will undertake an internal "risk analysis" to determine how (or whether) to act. Compare a person caught in a smoke-filled room (who has concrete evidence that there is a serious fire) with a person on the floor below -- who can't see the smoke but hears the fire alarm. The person who sees the smoke and hears the fire alarm is presented with unequivocal evidence of the fire -- they might make an immediate attempt to flee to safety. The person who hears the alarm might decide that a fire is unlikely and decide to stay put.

As with panic, the evaluation of risk based on available information is a perfectly normal and reasonable response. People know that it's more likely a drill or a false alarm than a life-threatening fire. In the absence of corroboration, individuals may make decisions based on their own understanding of the risks involved rather than the decisions that we might want them to make based on the actual circumstances. On the other hand, if an individual can hear the fire alarm and a neighbor gives them corroboration -- for example, they knock on the door and yell "Hey, get out -- it's a fire," the corroboration of the emergency is more likely to encourage the individual to take appropriate action.

So How Do You Account for That?

Understanding that personnel may make internal risk management decisions based on the available evidence before they respond in an emergency, it is particularly important that our preparedness activities contain a built-in method for providing external validation. Specifically, we want to clearly validate when a situation becomes an emergency. We want to minimize the risk analysis decisions that employees make for themselves and use formal risk management channels instead. In other words, we don't want someone to wait to act because they think the risk isn't sufficient for them to act. We want everyone on the same page.

Since individuals will often wait to gain validation before they take action, our planning should account for this and incorporate that behavior into the structure of the plan. For example, a process that provides external validation of an emergency situation (analogous to a verbal corroboration in the fire example) through notification to employees -- for example in an e-mail or call chain -- is much more likely to elicit the appropriate response on the part of employees. We should think through how we can encourage employees to defer to (and look to) the formal defined channels for risk-analysis rather than relying on their own internal compass in telling them how they should act.

As we define response strategies, it is important that we account for panic to make sure that our employees respond with level-headed rationality. But it's also important that we look to new and emerging information about how individuals react to emergency situations -- in ways other than panic -- in order to make sure that our employees follow the plan.


Ed Moyle is currently a manager with CTG's information security solutions practice, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner of Security Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development.


Facebook Twitter LinkedIn Google+ RSS