patpitchaya - Fotolia
When crafting a disaster recovery plan, it's critical to identify and avoid potential threats and prepare for the worst. A business impact analysis provides the information needed to address possible disruptions, provided that you do your homework. Following a thorough business impact analysis checklist will strengthen your disaster recovery strategy.
A business impact analysis is central to the development of business continuity and disaster recovery (BC/DR) plans. A BIA is a statement of requirements for recoverability; a hierarchy of priorities; and the value proposition to support senior management's investments in data backups, alternate facilities, duplicate equipment and other resources. It demonstrates an organization's vulnerabilities and what needs to be done before a disaster to meet the needs of the business and what can be deferred until a disaster occurs.
A BIA is a complex process, so there is plenty of room for error. Luckily there are some key ways to ensure that you don't miss a step when conducting your analysis. Using a BIA template can help, along with the steps we lay out below. Planning will differ by organization and industry, so when going through the business impact analysis checklist, make a note of which steps, business processes and applications you'll want to underscore in planning.
10 ways to improve your business impact analysis
- Consider an interruption of business functions in addition to applications. The driver of a business impact analysis is the business. The first question that needs to be addressed is what the effect would be on the entire organization if a business function could not be performed. The second question is which applications that function relies on. Some planners may be inclined to prioritize applications. While these are critical, maintaining business continuity and getting systems up and running as soon as possible is critical in this age when any downtime is considered unacceptable.
- Account for your whole IT environment. While business users may know which applications they rely on, they do not often know which other applications or infrastructure those applications rely on. When determining the relative importance of applications, the analyst needs to understand the totality of the IT environment: servers, storage, network, infrastructure and the portfolio of applications as a whole.
- Consider profit and loss for multiple circumstances. You shouldn't ask yourself, "If application X couldn't run, how much money would be lost?" It raises too many other questions such as: Could losses be made up when the system is recovered? Would an outage lose customers as well as sales? How much loss is attributable to a specific application? When performing a BIA, financial information is often collected and then isn't used when determining recovery requirements because it's too complicated. You should consider the profit and loss impact of an extended outage, as well as the capital and operating costs of reconstruction.
- Recognize nonfinancial losses, like loss of a good reputation. While financial loss is a critical threat to any organization, it is not the only concern for senior management. The effect on reputation and customer retention may weigh more heavily on their minds. Business managers may not fully understand how their function fits into their company's business model, so they could attribute the totality of financial risk to their own applications rather than considering the entire business. Ensure that everyone is mindful of the organization's reputation when planning for potential disruptions and downtime.
- Include considerations for enterprise and single-use applications. Some applications are more important than others because they serve the enterprise as a whole. Therefore, there is no one business manager who can state the overall importance of those applications. However, an application that serves a single business function, or that serves many functions in different ways, may not be as readily noticed. Take stock of the applications your organization uses most and relies on, and be sure to pay attention to them in your analysis.
- Consider data center applications. Some applications -- such as the operating systems, database management systems and data center tools that enable business applications -- do not have business users. It is easy to say that the infrastructure must be recovered before all applications, but that doesn't mean that the operating system on an obscure server that performs analysis should be recovered before the credit, trading or inventory systems.
- Differentiate between a BIA and a risk assessment. A risk assessment determines what could cause an outage; a business impact analysis shows the effects if one did occur. A risk assessment is beneficial because it helps an organization identify critical threats and prepare for them, which can help allocate and prioritize DR resources and planning. A risk assessment performs an entirely different business function from a BIA, so be sure you are not using one as a replacement or shortcut for the other. The issue for a business impact analysis lies in the resulting consequences of interruptions of varying durations, regardless of the causation.
- Understand that risk acceptance doesn't mean cutting corners. Going through an entire business impact analysis checklist is a lengthy process, so some managers may not want to spend time on determining the impact of an event if they're willing to accept the downtime for a particular application. However, acceptable downtime for one department may be unacceptable for the organization as a whole, so even a manageable impact should still be considered.
- Complete the entire BIA process. Sometimes the result of an analysis seems obvious to business managers, so they might automatically assume the answer without going through the whole BIA process. Assumptions may yield correct results 80% of the time, but that means they're incorrect 20% of the time, and that is plenty of opportunity for error with the number of business functions and applications in any given organization. This leaves room for applications to be inaccurately analyzed, and you won't know it until a disaster strikes.
- Don't understate BIA results. Disaster recovery is expensive, but that's no reason to mince words when it comes to the results of a business impact analysis. A business manager may choose to understate the financial, operational or reputational impacts of his or her applications being unavailable because of the perceived cost of recoverability. Of all the potential mistakes that could be made during a business impact analysis, this is the most insidious, because it intentionally undermines the overall statement of recovery needs that a BIA is intended to produce. It is understandable that managers may be more concerned about budget today than an incident that may not even occur in the future, but they are placing a potentially intolerable burden of risk on the enterprise.
Getting your business impact analysis right
Overall, you should perform BIAs with an open mind and follow the facts, wherever they may lead. Existing preconceptions may be shattered, but if preconceptions were reliable, there would be no need for a business impact analysis checklist at all. In far too many organizations, the so-called business impact analysis for information systems is performed in a quick meeting between a few IT managers.
An IT disaster recovery plan is a subset of a business continuity plan and the criticality of an application is dependent on the criticality of the business functions that rely on it. The business functions of any organization are complex and interdependent. In large companies, they may be so interwoven that understanding the relative impact of one versus another is a herculean labor. But it is a worthwhile effort, not only so that senior management can invest in recoverability, but also for the insights it gives into the complexities of the companies.
Conducting a BIA from start to finish