A business impact analysis (BIA) is research to collect and identify processes within an organization to determine the criticality of each process and the impact in the event of a potential failure.
During a business impact analysis, companies examine what the impact will be if certain business processes fail due to incidents such as fires, severe weather or malware. Its goal is to provide the company's management with recommendations for creating a business continuity plan or a disaster recovery plan.
In most cases, the emergency coordinator and his or her team conduct the business impact analysis. They do this in several steps. First, they conduct a research, which usually consists of a series of interviews and workshops with the company's employees to identify business processes, quantify potential damage from their failure and identify dependencies. A planning and analysis part follows this research, where the emergency team prioritizes and determines for how long the failure of a particular process can be tolerated by the company.
Finally, the emergency team prepares a business impact report to present to the management. This document outlines the impact of business processes, defines maximum tolerable downtimes, and prioritizes business functions. It also provides concrete recommendations for measures to limit the impact of failures and to create a disaster recovery plan or emergency manual.
What is the difference between a business impact analysis and a risk assessment?
Both business impact analysis and risk assessment are important steps in creating a disaster recovery or business continuity plan. However, the business impact analysis focuses solely on the consequences that the interruption of certain business processes may have, and does not address the reasons and probability for their failure.
Risk assessment, on the other hand, identifies potential hazards such as severe weather, earthquakes, IT incidents or supplier failures. It plays out these scenarios and estimates how likely they are to occur and how great the impact would be for the company, ultimately providing recommendations for measures to prevent and limit the potential damage.
The business impact analysis and the risk assessment complement each other. However, emergency teams perform the business impact analysis usually before the risk assessment, since it is easier for them to understand the effects of an incident if they know all dependencies.
Example of a questionnaire of a business impact analysis
A structured questionnaire for preparing the interviews saves the emergency team time and provides precise, comparable data. The German Federal Office for Information Security (BSI) provides a sample questionnaire on its website that is suitable for most SMEs. This covers the following points:
What impact (1 – low, 2 – medium, 3 – high, 4 – very high) does it have on the company if the core process fails?
What impact (1 – low, 2 – medium, 3 – high, 4 – very high) does a data loss have on the company?
Which IT systems are absolutely necessary for emergency operation of the process?
Which of the IT systems contain data that cannot be recovered in the event of a loss?
Are there alternatives or alternative workflows to these IT systems?
Which of the IT service providers are mandatory for an emergency operation of the process?
Are there alternatives or alternative workflows to these IT service providers?
BSI provides the questionnaire in German language as a Word template for download. It also offers an example of an already completed questionnaire for the business areas of financial accounting, sales and production as a PDF.
Carrying out a business impact analysis
A business impact analysis is a multistep process that includes the following phases:
Gathering of information.
Evaluation and analysis of the information.
Elaboration of recommendations.
Presentation of the report to the management.
Various standards for business continuity management provide guidance on how the emergency team should proceed when conducting a BIA. For example, the documentation of the ISO guidelines ISO 22301 is a good starting point. The German Federal Office for Information Security (BSI) presents a methodology for establishing emergency management in its BSI 100-4 standard, which details the steps for a business impact analysis. With the Implementation Framework for Standard 100-4, or UMRA for short, the BSI also provides not only individual templates, but a complete toolbox free of charge. Here is a summary of the BSI's recommendations for the procedure for a BIA:
1. Identifying business processes
The first step in a business impact analysis is always to create a comprehensive overview of all business processes. However, there is no exact definition of what exactly is meant by a process. But it has proven useful to see a process as the entire path of a product from the manufacturer to the consumer. Each process receives a certain input – this can be a raw material, components, preliminary products, but also data or services – and creates an output. Inputs and outputs provide the links between multiple processes. For each business process, the emergency response team should record the following:
A clear designation of the process.
A short description.
The required input.
The output.
Subprocesses of the process
Links to other processes such as predecessors and successors.
The degree of dependencies to other processes.
The contact person for the process.
2. Select relevant units and business processes
To reduce the effort and cost of business impact analysis, the contingency team can cut out departments and business processes where end-to-end operations are obviously not critical – for example, marketing.
3. Evaluate possible damage
The next step is to go through the business processes one by one and to determine in interviews with those responsible how great the damage would be in the event of a failure. Losses can be financial, in the form of lost sales or penalties, or intangible, in the form of damage to the company's image or loss of market share.
Where possible, emergency teams should assess damages during interviews both quantitatively, in terms of monetary amounts, and qualitatively by categorizing them as "low", "normal", "high" and "very high". Typically, emergency teams establish three to five such categories.
For such qualitative categorization, it is crucial to define the ratings unmistakably defined. After all, employees in different areas of the company may interpret these categories differently. For the IT manager, the failure of a server may fall into the "very high" category because he thinks of how much work it will take to restore the system for his team. At the same time, the CEO is more likely to rate the financial impact for the company as "low". Here's an example:
Damage category
Impact
low
Loss less than 5% of sales, no violations of laws and no negative external or internal impact.
normal
Tolerable losses of 5-20% of sales. Customers notice the disruptions only in isolated cases.
high
Considerable financial losses of 20-30% of sales, but not threatening the existence of the company. Violations of laws and regulations with tolerable consequences. Individual customers and business partners draw consequences.
very high
Financial damages threaten the existence of the company. Violations of laws with consequences for business operations and employees. A significant proportion of customers and business partners draw consequences.
Contingency teams must also take into account that damage at different times has varying degrees of impact. An online retailer, for example, is hit disproportionately harder by an outage during the run-up to Christmas than during the summer. During payroll, a failure of the accounting system has a greater impact than usual.
4. Determine restart parameters
When emergency teams know the damage level of each process, they can determine how long the procedure may be down before the consequences are no longer tolerable for the company. This time period is called the maximum tolerable downtime (MTA). The goal must be to have processes up and running again before the end of the MTA. This time target is called the Recovery Time Objective (RTO). The RTO consists of the time until the incident is discovered, the response time and the time required for the actual restart, i.e., the start of emergency operations. Among the parameters that the emergency response team must establish for each process is the recovery level. It determines which functions of the operation must be available before normal operation can be restored.
5. Taking dependencies into account
Dependencies between processes might make it necessary to adjust restart times of individual operations. If one process requires the output or service of another, both must be restored. Therefore, they also have the same RTO. This makes it necessary to determine dependencies of each process and inherit availability requirements to preceding operations as needed. Such inheritances of the RTO can also be made granularly. Three to six dependency levels, such as 1="very high" or 6="low" are recommended. Here, "very high" expresses a 1-to-1 passing on of the restart time, while low means that no inheritance is necessary.
6. Prioritization of business processes according to criticality
The RTO also shows the prioritization of individual processes. Since it is determined according to the damage level, a shorter recovery time automatically means a higher criticality of the process. However, it simplifies communication to categorize the processes into classes such as "highly critical", "critical" to "non-critical". This allows emergency management to focus on the processes identified as being most important.
7. Identifying Single Points of Failure
Once the emergency team has finally identified the most critical business processes, it must now determine which resources are necessary for their operation, both during normal operations and emergencies. Resources may include power supply, access to a database or SAP, an Internet connection, or a specific employee who has specialized expertise. Here is a list of possible resources:
Personal
Information
IT Technology
Special equipment
Services
Infrastructure
Resources
For each resource, the emergency team should determine how heavily the process depends on it and categorize this from 1=very high, i.e. indispensable for the process, to 4=low. In this way, it can identify the single points of failure, i.e., very critical resources whose loss would trigger a complete breakdown of the process. It must document these and initiate measures to safeguard them as quickly as possible.
In addition to the resources for normal operation, the emergency team must also document the resources required for emergency operation. This can consist of the company switching to an alternative process or running the operation with reduced capacities.
8. Writing a BIA report
The Business Impact Analysis report should contain all important information collected during the BIA. This includes, for example, methods used and an overview showing processes and dependencies. For each process, there should be an individual assessment with damage analysis and prioritization for recovery, as well as an overview of the resources required for the critical procedure and its single points of failure.
Findung gaps in your emergency management? Here's what you can do:
If you identify technical gaps in your emergency management during a business impact analysis, a cloud solution can be an easy option to implement. In a comparative test by the trade journal the cloud report, the Open Telekom Cloud took first place in the backup category. The editors pointed out that the Open Telekom Cloud had the “widest range of functions at moderate costs” of all the cloud providers tested.
Some of our services run in a high availability cluster by default, which protects against catastrophic events. For example, Open Telekom Cloud's Object Storage Service (OBS) provides identical and constantly updated copies of data in two German data centres within three availability zones. We can also create such high-availability clusters on request for virtual machines from the Elastic Cloud Server offering and block storage from the Elastic Volume Service (EVS). For this purpose, we offer the Storage Disaster Recovery Service (SDRS) as an option.
To protect against minor incidents such as ransomware attacks, accidental deletion or deliberate manipulation by hackers, Open Telekom offers cloud backup solutions such as Cloud Backup Recovery (CBR) Service or Cloud Server Backup Service (CSBS). It can be used to automatically back up entire system landscapes.
If you need additional geographic redundancy with longer distances between the data centres, you can also use our second region in Amsterdam to run a solution for backups or disaster recovery on virtual machines. The locations as well as the distance between our German and Dutch data centres meet the BSI recommendations for georedundancy.
