A business impact analysis (BIA) is a study used to identify the impact that can result from disruptions in the business. It focuses on the failure of one or more critical IT functions.
Another way of thinking of a BIA is that it helps you identify the systems critical to the survival of an organization. As a reminder, survivability is the ability of a company to survive loss due to a risk. Some losses are so severe that they can cause the business to fail if they aren’t managed.
And included several terms relevant to BIAs, including:
- Maximum acceptable outage (MaO)—The MAO identifi es the maximum acceptable downtime for a system. If the MAO is exceeded, the mission of the organization is affected. The MAO directly affects the recovery time.
- Critical business functions (CbFs)—Any functions considered vital to an organi-zation. If a CBF fails, the organization will lose the ability to perform essential operations, such as sell products to customers. If the organization cannot perform the function, it will lose money.
- Critical success factors (CSFs)—Any element necessary to perform the mission of an organization. An organization will have a few elements that must succeed in order for the organization to succeed. For example, a reliable network infrastructure may be considered a CSF for many companies today. If the network infrastructure fails, all other business functions may stop.
The BIA isn’t intended to include all IT functions. Instead, the BIA helps the organization identify the critical IT systems and components. You identify the critical systems and components by identifying the critical business functions. Non-critical business functions are not included.
This brings up an important question: What is a critical IT function?
Any stakeholder can determine that a business function is critical. If the stakeholder determines that the loss of the function will cause an unacceptable loss, it is a critical function. The stakeholder makes this decision based on experience and opinion. This isn’t a light decision. Once the function is desig-nated as critical, the stakeholder needs to dedicate resources to protect it. Resources can include money and personnel.
Additionally, a law could dictate that a function be considered critical. For example, consider the Health Insurance Portability and Accountability Act (HIPAA). HIPAA mandates the protection of health-related information. Access controls and other protection measures could be considered critical to ensure HIPAA compliance.
The BIA is largely a data-gathering process. You receive input from stakeholders, users, process owners, and others in the organization. You can gather the data from interviews. You can create questionnaires or surveys. You can also review available reports. You can use any method that will give you information on the target system. It’s important to realize that the BIA doesn’t provide solutions. Instead, it’s part of a larger business continuity plan (BCP). The BIA provides input into the BCP. The BCP does include solutions. For example, the BCP may provide recommendations for controls to reduce the impact of an outage.
Additionally, it’s worth comparing a BIA against a risk assessment (RA). The RA looks at threats and vulnerabilities. When a threat exploits a vulnerability, a risk occurs. The RA has a primary goal of reducing the risk. It can be reduce the risk by reducing or elimi-nating the vulnerability. It can also reduce the risk by reducing the impact of the threat.
The BIA doesn’t address the threats or vulnerabilities. Instead, it just looks at the effect if there is an outage. Although the focus of a BIA is primarily on disaster recovery, the BIA’s output can also be used in an RA. In other words, if you’re trying to determine what systems to evaluate with an RA, you can consider the output of a BIA. At the very least, the BIA identifi es and prioritizes the critical systems. Similarly, if you’ve already completed an RA, you can use that data to help with the BIA. One of the fi rst steps in an RA is to identify assets. This helps you identify the assets that are important to the organization.
Collecting Data
Because the BIA is a data-gathering process, you should consider the different methods used to gather the data. There are multiple methods available.
You can conduct interviews with key personnel. You can improve the results with a little forethought. Plan the interviews. Make sure the people you’re interviewing have the time to answer your questions. Make sure you’re ready with the right questions. Remember, your questions should focus on CBFs and the MAO of supporting resources.
Another method is to use questionnaires, forms, or surveys. Keep these limited and focused. In other words, focus on only one process at a time. If the form is too long, people may not have the time needed to answer it. If it’s shorter, you’ll get more usable information. These can be paper-based or computer-based. For example, you could use a SharePoint Web site to gather and compile the data.
You can also host meetings or conference calls. A benefit of this format is that multiple people can interact, and your results may be much richer. However, it may be quite difficult to gain consensus. This is especially true if you’re trying to identify the priority of different systems.
Varying Data Collection Methods
Nothing says that you can only use one data collection method. Feel free to vary your methods. Some people may have a lot of information and an interview may be appropriate. However, just because you interview one person does not mean you have to interview everyone.
If people are already weighed down with a large number of meetings, they may resent another meeting for a BIA. On the other hand, they may welcome the opportunity to fi ll out an online form at their leisure.
Summarized from the book Risk List and Control - Darril Gibson
Darril Gibson is the CEO of Security Consulting and Training, LLC. He regularly teaches, writes, and consults on a wide variety of security and technical topics. He’s been a Microsoft Certified Trainer for more than 10 years and holds several certifications, including MCSE, MCDBA, MCSD, MCITP, ITIL v3, Security , and CISSP. He has authored, coauthored, or contributed to 10 books including the successful Security : Get Certified, Get Ahead.
No comments:
Post a Comment