For anyone who has performed a BIA, you know that there are many choices to make in how it is structured. This article will give you some insight into decisions that are critical and may impact the results of your BIA. Every company will have to determine for itself what will work best for your own situation. It is also important to consider all the new technologies that are impacting your organization, like virtualization and cloud computing, and how the BIA can provide value in capturing information about these technologies and how they can best be utilized within your company in the future. This is addressed later in this paper.
Determine a BIA Methodology
One of the first decisions you will be faced with is determining the methodology to use during your BIA. Will you hire consultants, use BIA software, use questionnaires, interviews, or both? The answers to all of these questions depend on what you want to get out of the project.
The goals of the project will guide you to the correct answers on the questions above. Do you want to perform a high-level BIA, or get as much detail as possible? Do you want to cross-reference every single application to the business units that use it, or just the critical applications?
The size of the company will also impact your goals and methodology. The larger the company is, the more difficult it will be to drill down to the finest detail. You will want to take no more than four months to complete your BIA. A BIA is a snapshot of your corporation at one point in time. The longer the project goes on the more likely that the data will be out of date as soon as it is published.
Identify early what the reports will contain
Once the overall goals have been determined, you should define the reports that you will want to use in the final report. This may seem like an odd time to worry about this, but it will save you several very big headaches later on. After you’ve gathered your data, and you are getting ready to prepare your reports, you will invariably realize that you want to report on some additional information that you don’t have, or that you don’t have enough detail on. This will force you to backtrack to gather more data or abandon that portion of your report. Therefore, it is critical to decide what information is going to go into the report at the earliest stage of the BIA, so you can be sure to ask the right questions during the information gathering process.
How will it be resourced?
Is this project one which your company is going to tackle itself, or do you want to contract it out? If you hire an outsider to do it, make sure that you stay involved in every phase of the operation. If you do, you will learn a tremendous amount about your organization.
For one BIA I participated in before I became a consultant, our company hired a consultant to help us with a large BIA project, but we made it very clear that he would lead it and we wanted to be assigned to tasks just as if we were employed by the consultant. This worked very well throughout the project. We all participated equally in the kickoff meetings. The consultant performed one-third of the interviews, and my staff and I performed two-thirds (after several training sessions). We prepared the detail spreadsheets while the consultant wrote the final report, which we then edited before submitting it to management. It was a true partnership, and we learned some invaluable insights into our company that we would have missed had we farmed out the entire project. As a side benefit, we also saved our company about half the cost consultants normally charge for a BIA.
Should you use a Database or MS Office Templates
Whether to use database software is another issue. There are a lot of disagreements by experts on whether databases are too complicated, or whether the extra setup time is worthwhile. Databases offer a lot that MS Word and Excel templates cannot.
If you are capturing the BIA information and also want that information to become part of your BC or DR plan, then you should consider databases. The right database product will take the BIA information and import it into a BC/DR Planning tool, and you’ve just saved yourself a lot of work. Many people are in favor of using a simple template in Excel or Word for the BC/DR plan itself, but again, the more you want to port that information into your plans, the decision to use a database becomes easier.
Questionnaire, Personal Interviews, or Both
The software issue leads into another quandary, whether to rely solely on a questionnaire, perform personal interviews, or use a combination of both. This will be determined in part by the amount of resources available to collect your data.
Questionnaires definitely have their place in data collection, but they should be used, in my opinion, in conjunction with the interview, and not, for example, as the sole means to have a manager rate the criticality of their business functions. Managers often overestimate the value of their business unit to the overall success of a company, as they generally lack the global view. The interview process is where you review and modify, if necessary, the information contained in the questionnaire. If resources are extremely limited, this may not be possible, but I would try to use a combination of the two techniques, if possible.
A good use of questionnaires is to gather data that involve lists of items (such as software applications, vendors, vital documents, or interdependencies among business units). Another purpose of the questionnaire is for items that may require research or some thought before answering. How many employees are required for a particular business function? How many during peak periods? How much revenue would be lost if the business function couldn’t be performed?
If information did not fall into these two categories, then we did not put it into the questionnaire. We saved everything else for the interview. During the interview itself, having the questionnaire answers in advance allowed us to focus in on the key areas that needed to be addressed. It streamlined the interview, saving time during each of the 100 plus interviews that were held. Combining methods in this fashion gave us more information than either a questionnaire or interview by itself ever could have.
If you would like several types of questionnaires, feel free to e-mail me at email@example.com, and I would be happy to send them to you. Every company should judge the effectiveness of these forms for your organization.
Define Appropriate RTOs/RPOs
One main objective of the BIA is to capture the number of employees utilized under normal and peak operating periods, and then determine how many employees (or desks, in a multiple shift environment) are needed within the recovery time objectives (RTO) outlined by your company.
If you aren’t familiar with the term, RTO means the timelines within which you need to recover your business functions. There are several ways to define the criticality of business units. There are usually three to five levels, broken into mission critical, near mission critical (sometimes called “necessary” or “essential”) and non-essential. To make it simple, you can even number them Tier 1, 2 and 3 or A, B, and C. These labels will mean different things to every organization. Mission critical could mean minutes for some organizations or it could mean a day for other organizations, depending on your company’s tolerance for downtime.
It is also important to gather information on your company’s tolerance for data loss. While RTO measures your tolerance for downtime following a disaster, recovery point objective (RPO) measures how much data can be lost prior to the disaster.
A simple example should illustrate this point. If you backup your data nightly during the week, and you have a disaster event at 4 p.m. on Monday, you have lost one full days worth of data plus any processing since Friday night’s backup. Add to those two days that it would take you to recover at your hot site, and you’ve potentially lost a total of five days. If your critical business units feel they can only be down for two days, then losing five days of productivity might be unacceptable to them. You can use the BIA process to make them understand that the true length of an outage due to a disaster is the amount of data lost (the RPO) plus the time it takes to bring your systems back to life following a disaster (RTO).
Define Two Separate RTOs/RPOs - Expected and Achievable
There is often a dichotomy between what the business unit wants in terms of expected RTOs (in blue below) and what can actually be provided by the company and by the IT department (achievable, below in red). It is very important to note these differences during the BIA process so that when the final report comes out, these differences can be discussed, gaps identified, and a resolution achieved. Either expectations need to be managed or the achievable RTO/RPO needs to be improved. This is a management decision, but can only be addressed once it’s been brought to light.
One company had told customers that a system could be up and running within a week after a total loss of the facility, which sounded reasonable. However, in talking with technicians, it became clear that network communications would take much longer to recover, maybe even months. This situation couldn’t be addressed until it was identified. They no longer talk with customers about recovery in one week until a plan is in place to make it happen. Fortunately, this is not a mission critical system, so they have deferred the risk until they can fix it.
Following the BIA your business units will now have a more realistic expectation of how they will be affected during a disaster. The importance of this cannot be stressed enough. A good partnership with the business units is essential to a successful BIA, and to the health of the DR program altogether. The definitions for RTO and RPO should not be driven by the IT organization, but by the business units themselves. They are in the best position to gauge the tolerance in your industry for an outage. Generally, the only time this is discussed in any formal way is the BIA process. Otherwise, it is usually dictated by IT, who are making some very large assumptions that they know what the business units want, or there may not be a concrete policy on the subject. Either way, don’t let it happen to YOUR organization. Keep your business units involved!
Determine How System/Applications Support Your Business and its Customers
One of your objectives during a BIA should be to understand how every piece of software relates to every business unit. If you have a large organization with hundreds of software programs, you may decide this is too tasking. If so, make sure you get at least the top five programs that impact each business unit. Applications should have a criticality rating separate from the business unit’s rating, because you should not assume that every business unit needs every application it uses within the same timeframe.
A business unit that has a recovery window of 24 hours may only need its two main programs up and running within that time frame. It may not need three other programs until the end of the first week, which might give you time to procure equipment and build it yourself, rather than including it in a hot site agreement. However, be careful to identify all interdependencies, or you may find out too late that one of your mission critical systems relies upon another system that is not recoverable within the needed time frame. If that happens, your whole plan might be in jeopardy of failing.
Vendors, vital records and other equipment should be treated the same way. They all need to be rated based upon how quickly the information or relationship needs to be reestablished.
Once all of these lists are created for each business unit, it will become self-evident which applications, vendors, etc. are most critical. Your plans can virtually write themselves. Well, its not really that easy, but the plan writing stage does become much easier when the BIA is performed in such detail, and if all the business units have participated and taken it seriously.
One of the most important purpose of a BIA is to make sure you understand as many of the risks associated with operating your business as possible. There will certainly be monetary concerns of how each business unit affects the bottom line of your company, but you should also consider each business unit on other levels, including customer service, regulatory, legal and whether other departments are dependent on this unit, such as a printing department.
This can be broken down into financial, operational and intangible (reputation, good will, etc.) risks. You need to have a way to catalogue these risks, and rate them in terms of impact/severity to the organization and likelihood of its occurrence. Once you’ve rated these risks, starting with the most serious risks, start developing a strategy for how your company will deal with them.
There are four courses of action:
- Accept the risk (by management) and do nothing.
- Resolve the risk so that it will no longer impact the organization.
- Mitigate the risk, or develop a workaround.
- Defer the risk until another time (the next budget cycle) when it will be addressed.
Determining How to Use the Cloud to Enhance your Business Model
There is a lot of talk about how cloud computing is going to revolutionize your data center and your business model. While there is a lot of truth to that statement, you don’t want to increase your risk by moving your mission critical applications out to the cloud if you don’t know anything about where the “cloud” is.
Of course, that is the idea, right? Get rid of your hardware and maintenance costs and you reduce some risks…..but you don’t want to substitute one risk for another risk that you know very little about. Where is this cloud environment? What are the business continuity plans? Would you stake your company’s future on it? Well, you are even if you don’t think you are!
Cloud computing is a positive movement, and can be a great benefit to controlling costs and increasing uptime and productivity. However, make sure you perform due diligence to understand the risk profile of the partner you’ve chosen to host your cloud environment. Once your systems are in the cloud, you assume the risks of the cloud provider.
The impact this has on the BIA can be subtle, but significant. A thorough BIA performed today should include some analysis of the cloud-worthiness of your applications. You would not generally want to put your most mission critical applications in a public cloud, but you can evaluate which systems might be appropriate for a private cloud (some mission critical systems), which systems might do well in a public cloud (your less critical systems), and which systems are not ready for the cloud environment (some mission critical applications or apps that don’t react well to virtualization). Defining the differences between public and private cloud is beyond the scope of this paper, but the BIA is a perfect time to be addressing these considerations. Every BIA should undertake, in part, whether your applications would be good candidates to reside in either a public or private cloud, where they can be accessible by people with just an internet connection and a password.
Understanding New Technologies
This should be a critical component of any BIA today – making sure you understand what new technologies are planned within various business units within your company, especially in a decentralized organization, and asking the right questions to help determine the direction that IT should go. This will provide a value beyond the traditional BIA and give your management team a reason to keep the BIA current year after year. You can call it a technology profile, or a technology impact assessment, or another name. Its primary purpose is to help lead the discussion of where your technology is and, more importantly, where it is going to be in the next six to 12 months, and where it should be.
For example, part of the analysis could be an assessment of your virtualization capabilities. Which systems are virtualized? What opportunities are there for more virtualization? This saves the company money and can pay for the BIA, which again, provides great value. This approach may also identify areas where a manual system might be replaced by a computerized system, and the BIA might be used to help justify the initial expense. Admittedly, these are not subjects that have traditionally been within scope of a BIA, but if you think outside the box a little, and insert those objectives into your goal or mission statement for the BIA, and management understands the value proposition of tackling these challenges, then it is a win/win for the company and for you.
If you haven’t tried a BIA in your organization for some time (or ever), this should point you in the direction you want to go. There will be other issues and decisions to make, to be sure, but you should be able to develop your own technique, incorporating some ideas from this article, and your own experience on what will be successful within your company.
About the Author:
Harlan Dolgin, JD, CBCP, is director of continuity services with Bick Group. He has been involved in BC/DR since 1997 with companies like Thomson Reuters, WellPoint and US Bank. He is also an adjunct assistant professor at St. Louis University, teaching a course on business continuity management and pandemic planning.