Perception versus Reality — The Myths of Business Resilience

on March 9, 2015 Resilience - Growth & Strength and Tags: , , , with 0 comments
Perception vs. Reality

I recently came across a report from Quorum on disaster recovery solutions that I found to be quite interesting. Many of the statistics in the report show a disconnect between perception and reality in terms of business resilience risks and solutions. In this blog post, I’ll examine a few of those misperceptions:

The majority of respondents (33%) think natural disasters are the biggest causes of downtime.

However, the statistics show that only 5% of IT failures are caused by natural disasters while 55% are caused by hardware failure and 22% are caused by human error.

It is hard to say with certainty why the disconnect between perception and reality is so large. However, we might speculate that the media coverage of events like natural disasters far surpasses the coverage for events like human error, so people’s perception is skewed. Whatever the reason, it seems many companies do not have an accurate picture of the situation when they are addressing business risk.

In order to ensure their business is covered regardless of the circumstance, companies should conduct a risk assessment to determine all known risks that could impact them. After all the risks are listed, they can then conduct a business impact analysis that helps determine what risks need to be addressed. Once the potential impact of each risk is understood, it is much easier to prioritize the actions that need to be taken to ensure full and prompt recovery is successful.

45% of companies think an hour of downtime would cost $1,000-5,000.

However a 2013 Aberdeen report for that the average cost of downtime for small and medium sized businesses is $112,110/hour.

For most companies today, information technology and data are critical to all aspects of business—operations, finance, HR, etc. Without access to technology and data, many companies are at a complete standstill. However, it seems there is a misconception about how much not having technology/data access would cost.

While it is nearly impossible to prevent all instances of downtime, there are steps businesses can take to ensure they can survive data or technology disruptions. The best way to do this is with a proactive approach—rather than waiting for a disruption to happen, implement data protection solutions to ensure that when the unwanted does occur, losses are kept to the bare minimum.

The first step in protecting your business from downtime is limiting the number of interruptions or disruptions that can jeopardize the company. This can be done by implementing technology recovery services like virtualization, hybrid cloud solutions, virtual machine migration and instant failover.

69% feel confident enough in their backup/recovery solution to erase all of their data, knowing they could recover it.

However, 21.4% never test their solution’s capabilities and functionality.

While it is great that so many companies have confidence in their backup/recovery solutions, it seems a bit strange that some of these companies have no clue whether or not their solution works in practice. Especially as businesses change—software gets updated, new employees come in, etc.—testing is the only to truly ensure your business can survive any crisis.

Testing can be done in many ways. A company could have a bench test where a disaster is simulated, and every department reports on how they would react/respond. Surprise simulations are great tests; imagine employees coming to work only to be told that they are not allowed access to the building because a disaster has been declared… now proceed as planned. Full-blown tests can also be conducted. In these scenarios, the power might actually be shut down, and disaster protocols must actually be executed.

In a nutshell, I strongly advocate clients to Plan & Prepare, then Test & Maintain so they can Recover & Restore if/when the unthinkable occurs.

~ Bill

Share this: Facebooktwitterredditlinkedinmail

Add comment