Select a page

Business Impact Analysis 101

Business Impact Analysis 101

Business Impact Analysis 101 Get The Facts

The Business Impact Analysis (BIA) is the foundation and building block of your business continuity program. Done correctly, your planning phase and strategy selection should go smoothly and your plan will be sound. Unfortunately, many plans are ineffective and this can often be traced back to issues with the BIA.

I’ve witnessed many mistakes when it comes to conducting a solid Business Impact Analysis. Simply put, the BIA is just a method of collecting information (data) about critical business processes, Key employee information, IT and other assets, and more. This can and often includes other information that may be important and/or come in handy for planning or risk assessment purposes. For example – here at Continuity Co., LLC we often collect additional pertinent data to perform calculations on downtime and other items. Our Business Impact Analysis is very comprehensive and allows for additional more holistic planning.

One of the more recent and most common examples I have seen is the issue of Quantitative vs qualitative BIA’s. This usually, but not always around which method is better, and often involves whether or not you are involving IT.

You’re Business Impact Analysis should be exhaustive and even the most basic should address both qualitative and quantitative type questions. It is also important, and I can’t stress this enough, to involve IT in the process as early as possible. How we implement the BIA process is to work with our clients to select business units and break them into groups. We then hold a kick off meeting to ensure everyone is on the same page, and as each business unit completes their BIA, we loop in IT to perform their section of that business units BIA. Using this method we keep things moving forward, and we hold a group meeting to discuss and share issues and findings.

Recently we met with a potential client that was three years into their BIA process, which they have not yet completed, and they were just looking at beginning to involve IT. Though, they were still unsure if they wanted to wait until the BIA process was complete for all business units. There are several problems with this.

The first issue is that waiting so long to bring IT into the BIA process the original findings are likely outdated, and obsolete. The second, is that it is an industry (business continuity profession) best practice to complete a BIA every two years. This is done so that your information is not out of date.

While I can’t get into every nuanced question we ask in our proprietary BIA’s. I can tell you we drill down into each business units processes’ and what are the interdependencies, Recovery Time Objective’s (RTO’s), Recovery Point Objective’s (RPO’s), manual workarounds, controls, applications, etc.

Then when IT gets involved we look at Work Recovery Time (WRT), Maximum Allowable Downtime (MAD), Server location, backup frequency, backup media, cost-benefit-analysis, etc.

Bottom line, a BIA, is a BIA, is a BIA. While you do not want overkill, you want to gather all the information you need to complete the necessary planning.

0 Comments

Leave a reply

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

*

UA-22415034-1