Business Impact Analysis: The Foundation of a Disaster Recovery Plan

Consider the following statistics taken from the Disaster Recovery Journal (Winter 2011):

• A single incident of data loss can cost a company an average of $10,000.00
• 93 percent of companies that lost their data for 10 days or more, filed for bankruptcy within a year.
• 40 percent of businesses that suffer a loss of data, fail within 5 years.

And while most companies and organizations have taken Disaster Recovery seriously, they often fail to take a proper BIA or Business Impact Analysis and properly test their plan for appropriateness; often resulting in losses. A BIA or a Business Impact Analysis is exactly what it sounds like; proper research to determine what the business impact would be if an application, website, database, HR document, etc… were not available for given sets of time.  Perhaps if a database were not available for an hour there would be little impact, but if it were down for a day, it would be critical.  It is important to do an accurate study to determine where those pain points are for all aspects of your organization and review them regularly for changes in criticality.  While this sounds like the absolute foundation for all DR plans (and it is) I have regularly encountered both government and private industry that fail to do this most basic step.  They either consider everything to be critical (it isn’t) or they only backup a few servers that they think contain their most important documents/data.  Neither of these plans accomplishes suitable DR. Everything is not critical. From IT’s secret iTunes library to 20 years worth of employee newsletters, there are many things in your data center that don’t deserve a chunk of your DR budget.  Take control of your data center by utilizing quotas, scanning storage or servers for inappropriate material, and taking an active approach to knowing what is in your data center.  Conduct interviews with people at various levels in each department to understand dependencies and prioritize applications.  Determine criteria of what constitutes critical-data and what is considered not-critical-data and get executive buy-in for that criterion. Know what is where. The Accounting Share should contain accounting data.  If one database feeds several front ends, that should be documented.  This is simple stuff that is often just not done.  Volumes, shares, and folders should be utilized to best categorize data.  It is understandable that you may not want to name the web server “WebServer1”, but perhaps you utilize another method to allow IT personnel to easily understand what types of servers or data stores they support.  The names of flowers could represent your SQL servers, while movie names might represent ESX.  Come up with a plan, get buy-in, be consistent, and enforce, enforce, enforce. Test regularly. Suppose you have done your due diligence and you know what should be backed up and replicated to your DR site and you know where all of that data is; will your DR plan work? Years ago, I worked as a contractor to a large government agency that was performing its first large scale DR exercise.  This particular exercise had high visibility within the government and the success of this exercise was critical.  Tapes were loaded on secure planes and escorted under armed guard to the DR site.  Engineers were there in spades to boot systems and monitor failovers.  SLAs were documented and all were ready to pat each other on the back for the months of hard work preparing for this one moment when so many eyes would be on them and they would shine.  The index tape was loaded into the tape library, which the library decided to thoroughly shred and in a matter of moments the DR exercise was a total failure.  A total loss of the index tape had not been considered in the planning of the exercise, SLA’s could not be met, and we all went home rather humbled.  Test your plan regularly and incorporate all lessons learned. Just Do It. I have worked on countless DR exercises where everything was well planned, documented, BIA’s were performed, and thousands spent on DR software and warm/hot sites, but they had never actually performed a true failover.  The exercises were completed up to the point where actual failover would occur and the business would be running on the DR site, but they were afraid to “push the button” so to speak.  Is that a true exercise?  Do you know your investment is worthwhile if it isn’t thoroughly tested?  I would have to so say a resounding NO.  I am not suggesting you failover your entire organization, but perhaps the accounting software/databases are failed-over during the weekend and after much warning to the accounting department of course.  Perhaps next quarter it is the home directories.  Exercises of various levels and degrees of difficulty should be tested during the year, and much documentation should be recorded, lessons learned cited, issues resolved, and successes celebrated. In summary, perform a thorough BIA, account for as many obstacles as possible, and thoroughly test your DR plan.  The planning and testing you do now could mean all the difference in the future.