Business Impact Analysis and Recovery Objective Definition
Business Impact Analysis and Recovery Objective Definition
Business Impact Analysis(Business Impact Analysis)
To develop a strategy for disaster recovery, a Business Impact Analysis (BIA) must be performed. Through BIA, we assess the importance of major business processes and the potential losses that may occur upon interruption, and set the priority and scope of recovery.
- Work structuring
We group each unit task into groups, structure the overall work, and analyze it. Through analysis of the upper and lower work structure, you can understand the entire organization’s work structure as shown in the figure below.
Key task identification After structuring and analyzing the work, we select frequently used tasks among the derived business processes as targets for business impact analysis. Business impact analysis is performed considering whether the work is directly linked to core services targeting customers, and whether it is important from the organization’s strategic perspective, taking into account these two aspects.
Work relevance analysis
The importance of a task is determined not only by the significance of the task itself, but also by its relevance to other tasks. The relationship between tasks can be classified as a precedence where one task is performed before another, a subsequent order where it is performed after, or simply a reference relationship. The table below is a diagram that analyzes the relationships between tasks based on precedence and reference relationships.
| Follow-up work❷ \ Preceding work❶ | A1 | A2 | B1 | B2 | C1 | C2 | Correlation |
|---|---|---|---|---|---|---|---|
| A1 | - | ● | ● | 2 | |||
| A2 | ● | - | 1 | ||||
| B1 | - | 0 | |||||
| B2 | ● | - | 1 | ||||
| C1 | ● | - | 1 | ||||
| C2 | ● | - | 1 | ||||
| Correlation | 1 | 1 | 2 | 1 | 1 | 0 | - |
● Has relationship
❶ Preliminary work: tasks that must be processed before the line’s work is performed
❷ Follow-up work: tasks that must be processed after the row’s work is performed
- Disaster Impact Assessment
Measure the possible disaster types, losses per disaster type, and the impact duration for the implemented service. Disaster types include hardware errors, software errors, human mistakes, natural disasters, fires, network interruptions, etc. The table below shows the results of a quantitative/qualitative analysis of losses due to disasters.
| Category | Impact Item | Ripple Effect | |
|---|---|---|---|
| Quantitative | Financial impact | - Revenue decrease - Cost expenditure due to compensation - 000 won sales decrease - 000 won cost incurred | |
| Quantitative | Work Impact | - Work processing delay (delay time due to manual work) | - 00 hours or 00 days |
| Qualitative | Type | - Customer, loss of sales opportunity - Data damage, loss | - 00 customer decrease |
| Qualitative | Intangible | - Decline in reliability - Lawsuit | - Identify possibilities |
- Set business importance priority and recovery target work scope Based on the results of quantitative/qualitative analysis and work relevance analysis, we derive the priority of work importance. An example of defining work priorities is as follows.
| Priority | Task |
|---|---|
| first priority | A1 |
| 2nd priority | B1, C1 |
| 3rd rank | A2, B2, C2 |
However, even if you estimate the impact and set priorities, normal recovery does not necessarily happen according to those priorities. To achieve normal recovery, the results of the previously performed business relevance analysis must be reflected. For example, in the task relevance analysis example in the table above, to recover A1, B1, B2, and C1 must be recovered first. If this correlation is reflected in the recovery priority, the recovery order will be adjusted as shown in the table below.
| Priority | Task | Reflect task relevance |
|---|---|---|
| first priority | A1 | A1, B1, B2 |
| 2nd priority | B1, C1 | C1 |
| 3rd rank | A2, B2, C2 | A2, C2 |
Establish Recovery Objectives
After performing Business Impact Analysis (BIA), you must select the business groups subject to outage and disaster recovery and set disaster recovery objectives. For disaster recovery of the target task, two metrics are used: allowable downtime and allowable loss point.
Allowed Work Interruption Time
It is defined as Recovery Time Objective (RTO), meaning the maximum allowable time for service recovery when a disaster causes service interruption.Allowed time for business loss Recovery Point Objective (RPO) is used as an indicator, meaning the acceptable range of data loss when recovering a service interrupted by a disaster.
When setting RTO and RPO goals, the organization must review the acceptable downtime and the extent of data loss. The top-level goal of RTO is uninterrupted recovery in the event of failures or disasters, and the allowable downtime must be near zero (Near Zero). However, achieving these goals requires significant cost investment and operational burden. If information systems play a very important role within an organization, or if investment for recovery does not impose a large financial burden on the organization, a higher level of recovery objectives can be set. Also, as shown in the table below, the higher the financial burden limit that an organization can bear, the shorter the RTO can be.
The target level of RPO is set based on how far in time data loss can be tolerated. When a failure or disaster occurs, some data loss is inevitable. You can decide whether to recover data at a specific point in time based on the data copy storage frequency according to business importance and whether data replication is configured.
Information systems consist of various IT resources and interfaces, and generally perform multiple tasks simultaneously. Identify the relationship with other information systems related to this. Also, the operating organization of the information system and the organization that uses the services operated by that system are analyzed together.
The table below is an example that defines RTO and RPO through the relationship between business and information systems. For example, in the case of system F that handles task A2, the RTO is 8 hours, and task A2 is 1 day. We derive the minimum of 8 hours among these as the RTO for the relevant system and business. In the same way, we set the RPO to the minimum value of 1 hour as well.
| System \ Work | A1 | A2 | B1 | B2 | C1 | C2 | System-specific RTO | System-specific RPO |
|---|---|---|---|---|---|---|---|---|
| D system | ● | ● | 1 hour | real-time | ||||
| E system | ● | 4 hours | 30 minutes | |||||
| F system | ● | 8 hours | 1 hour | |||||
| G system | ● | ● | ● | 4 hours | 1 hour | |||
| RTO by task | 1 hour | 1 day | 3 days | 6 hours | 2 days | 1 day | ||
| Task-specific RPO | Real-time | 1 day | 1 day | 1 hour | 1 day | 1 day |



