Conducting an effective business impact analysis

Learn how to conduct a business impact analysis as part of a disaster-recovery plan.

Security managers are increasingly being required to ensure that their organization's information systems and data can survive a disaster. In order to accomplish this, security managers are conducting disaster-recovery projects which identify critical information systems, tasks and processes, and define in what order and how quickly they must be recovered after a disaster.

A key requirement for a successful disaster-recovery project is conducting an effective business impact analysis (BIA). This article presents an overview of the BIA process and how to conduct an effective one.

A BIA is a systematic process by which an organization gathers and analyzes information about its essential functions and processes (applications, data, networks, information systems, facilities, etc.). This information is then used to determine how the organization would be impacted if these functions and processes were interrupted by a disaster.

A BIA can provide a security manager with reliable data concerning the potential impacts and costs of disasters, as well as establish the basis for setting recovery priorities and selecting appropriate recovery strategies. More specifically, it can help a security manager answer a number of significant questions:

  • Which information systems and processes are essential to the survival of the organization?
  • How quickly must critical information systems and processes be resumed before significant or unacceptable losses occur?
  • What are the interdependencies among different information systems and processes?
  • In what order and how fast do specific information systems and processes need to be recovered after a disaster?

BIA process

Typically, a BIA is composed of five phases: project initiation, information acquisition, information analysis, findings documentation and report presentation to senior management.

Project initiation

The initial step in a BIA is for the security manager to obtain senior management sponsorship. Project goals, objectives and scope are presented to the management. Once these items are agreed upon, a project team is formed. Be sure and do this step first. Based on personal experience, not having senior management support for a disaster-recovery project will likely lead to the project not succeeding.

The project team should be composed of employees with appropriate skills and knowledge, third-party staff or a combination of both. Next, a detailed project schedule is developed and approved. Finally, the project is announced to all likely participants. The announcement should include a memo from senior management stressing both the importance of the project and the need for full participation and cooperation.

Information acquisition

A BIA should collect a wide variety of information, including:

  • Detailed descriptions of an organization's information systems and processes.
  • Identification of the users of information systems and processes.
  • Definitions of interdependencies among information systems and processes.
  • Expected qualitative and quantitative costs if particular information systems and processes are not available for specific periods of time.

Information should be obtained from various organizational units (e.g., Finance, Legal, Human Resources and Administration), as well as from relevant business partners. Be sure to carefully identify all the information you will need to gather; many persons will only respond to one request for information.

Information systems can be complex, with a wide range of components, interfaces, and processes; the person(s) conducting the BIA should seek to identify all interdependencies among these items.

Information analysis

The information obtained during information acquisition needs to be carefully examined and analyzed to identify critical information systems and processes, as well as potential disaster impacts.

BIA data can be analyzed by a variety of manual and computerized methods, the discussion of which is beyond the scope of this article. The analysis method to be used should be pre-defined. It is often useful to create a diagram of an organization's information systems and processes in order to illustrate interdependencies.

It is critical that security managers validate the information obtained in the information acquisition phase with participants for accuracy and relevance; a BIA based on inaccurate or incomplete information can cause significant problems during later stages of a disaster recovery project.

A useful method for validating BIA findings is to:

  1. Prepare a draft BIA report containing initial findings and issues.
  2. Issue the draft report to participants and request feedback.
  3. Review feedback and revise findings accordingly.

Document findings

The BIA findings are documented in a formal report; a typical BIA report includes:

  • Executive summary
  • Objectives
  • Scope
  • Data gathering and analysis methodology
  • Summary of findings
  • Detailed findings (by department or functional area)
  • Charts and graphs to illustrate potential losses (e.g., financial information, lost customers)
  • Recommendations

Report presentation to senior management

The formal BIA report should be presented to senior management. The security manager should be prepared not only to provide detailed explanations for any of the BIA findings, but also to advocate for their recommendations. This presentation is a great opportunity for a security manager to show senior management why disaster recovery is important and why it should be supported.

A well written and presented BIA report can significantly increase senior management's interest in and awareness about, disaster recovery; this, in turn, increases the likelihood that management will approve the next stage of the project.

About the author

Steven Weil CISSP, CISA is senior security consultant with Seitel Leeds & Associates, a full service consulting firm based in Seattle, Washington. He can be reached at [email protected]

This was last published in February 2003

Dig Deeper on Risk assessments, metrics and frameworks