The page has been translated by Gen AI.

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.
Concept diagram
Figure. Business analysis structure diagram
  • 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 workA1A2B1B2C1C2Correlation
A1-2
A2-1
B1-0
B2-1
C1-1
C2-1
Correlation112110-

● 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

Table. Example of Work Relevance Analysis
  • 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.
CategoryImpact ItemRipple Effect
QuantitativeFinancial impact- Revenue decrease
- Cost expenditure due to compensation
- 000 won sales decrease
- 000 won cost incurred
QuantitativeWork Impact- Work processing delay (delay time due to manual work)- 00 hours or 00 days
QualitativeType- Customer, loss of sales opportunity
- Data damage, loss
- 00 customer decrease
QualitativeIntangible- Decline in reliability
- Lawsuit
- Identify possibilities
Table. Estimated Impact of Disaster
  • 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.
PriorityTask
first priorityA1
2nd priorityB1, C1
3rd rankA2, B2, C2
Table. Business recovery priority through impact analysis

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.

PriorityTaskReflect task relevance
first priorityA1A1, B1, B2
2nd priorityB1, C1C1
3rd rankA2, B2, C2A2, C2
Table. Recovery priority through impact analysis reflecting business relevance

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.

Concept diagram
Figure. Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

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.

Concept diagram
Figure. Recovery Time Objective (RTO) Determining Factors

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.

Concept diagram
Figure. Recovery point objective (RPO) determining factors

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 \ WorkA1A2B1B2C1C2System-specific RTOSystem-specific RPO
D system1 hourreal-time
E system4 hours30 minutes
F system8 hours1 hour
G system4 hours1 hour
RTO by task1 hour1 day3 days6 hours2 days1 day
Task-specific RPOReal-time1 day1 day1 hour1 day1 day
Table. Business and system recovery target time (RTO), recovery point objective (RPO)