APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Business Impact Analysis

© November 2008 Michael Desrosiers

This month's topic is a how a Business Impact Analysis is one of the most critical pieces of an overall Disaster Recovery Plan. This e-newsletter deals with how organizations develop and implement solid procedures to document this process.

A Business Impact Analysis (BIA), is the cornerstone of any corporations Disaster Recovery Development Plan (DR). A BIA will identify what vital processes, systems and functions are needed to the survival of your business. Understanding these elements allows you to allocate resources wisely to ensure operations continue, even after unexpected events disrupt your normal business. The BIA is an analytic process that aims to reveal the business impacts that would result when a critical component exceeds its maximum allowable outage range. To start this process, you will need to understand your business operations in detail.

Here is a fairly simple and solid 10 step approach that will put you on your way to conducting a successful BIA:

  1. Get support from senior management for the exercise. You will then be able to meet with the operations management team that will know enough detail about the processes to be helpful to the program. It is hard to get people's time and even harder to get follow up for a comprehensive Business Continuity Plan (BCP) without their on-going support.

  2. Hold a kickoff meeting with the managers responsible for the core business processes and introduce the program goals, time-lines and deliverables.

  3. Collect the data. Create a BIA questionnaire which will be distributed at the meeting to all managers. Instruct each manager on how to complete the document. Make it clear that you will be following up with each manager or an individual basis to review the document. Some of the key items to consider for the questionnaire:

    a) The process name and a detailed description of it;
    b) List of all inputs and outputs from the process;
    c) What department or location "owns" the process;
    d) Define the maximum allowable outage time before impact occurs;
    e) Human and technology resources needed to support the process;
    f) Description of financial and operational impact of the outage;
    g) Legal or regulatory ramifications;
    h) Past outages and lessons learned;
    i) Description of workaround or work shifting procedures.

  4. Document the gross revenue and net profit your organization generates per year. This can be done at the appropriate business unit levels as well. The data sets the upper limit for business losses related to the business operation. Include this in your presentations to drive home the importance of the program.

  5. Meet with each manager and review the data collected. If needed, block off a few hours to help complete and refine the document with each manager.

  6. Merge all the data into a spreadsheet or database for easy data analysis and reporting capability.

  7. Schedule and conduct a review and prioritization meeting with all of the managers participating in the process. Look for gaps that are not mentioned by the departments, especially between departments. Prioritizing each process based on impact to the business, both direct and indirect as the process may be critical dependency for another process. High, medium and low ratings can be used as a scale to show their importance.

  8. During the prioritization discussion you will need to document a Recovery Time Objective (RTO). The RTO will define the unit of time that it will take to return the process back to it's normal operation, before impact results to the business and it is generally measured in hours.

  9. Create groups or bands of process RTO's. Start with the shortest possible RTO first, and then define the upper limits not to exceed a 24 hour window. These items constitute the Tier 0 RTO's. The next band are the Tier 1 RTO's which generally extends from 24 to 48 hours. Tier 2 covers a 48 to 72 hour window. The Recovery Point Objective (RPO) is the age of the files that must be recovered from backup storage for normal business operations to resume. The RPO's are different as they deal more with data recovery and are used more in a data protection strategy scenario. They are also usually measured in minutes to hours as in the case of a production type database or business critical application. It may have an RPO of 30 minutes between scheduled replications.

  10. And finally, convene a post-mortem or summary meeting to present the results of the process to senior management, managers and others core to the processes at topic. You will want to present the business processes in order of RTO and importance, along with the other process details collected during the program. Issue a final report to meeting attendees to reinforce the learning and memory of the participants. Make the report available in hard copy to use in the event of an actual outage to help prioritize actions to resume the business.

There you have it. The Business Impact analysis report ideally provides a foundation for the Business Continuity Plan that should follow this exercise. It can also provide a very important input to your overall risk management programs that may follow, now that you have insights into where business risk lives in your environment.

To view more articles:


or to inquire about an on-site presentation, please feel free to call me at 508-995-4933 or email me at mdesrosiers@m3ipinc.com.

Until next time.....


Michael Desrosiers
Founder & Principal Consultant
m3ip, Inc.
Managing Your Security and Risk Needs

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Business Impact Analysis is one of the most critical pieces of an overall Disaster Recovery Plan

Inexpensive and informative Apple related e-books:

iOS 10: A Take Control Crash Course

Take Control of iCloud, Fifth Edition

Take Control of iCloud

Take Control of Numbers

Take Control of OS X Server

More Articles by © Michael Desrosiers

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. (Edsger W. Dijkstra)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode