The latest business continuity news from around the world

Portal Publishing Ltd, PO Box 1393, Huddersfield, HD1 9TN, England

A methodological approach for developing a business impact analysis

Published: Friday, 15 September 2017 09:30

While business impact analysis (BIA) is seen by many as the backbone of any business continuity management system (BCMS) it is lacking a formal methodology. Here, Alberto G. Alexander, Ph.D, MBCI, details nine methodological steps for developing a BIA and discusses information gathering methods and BIA project management aspects.

Introduction

When developing and managing an effective BCMS, the backbone of its correct implementation is the business impact analysis (BIA) stage.

In this phase of a BCMS, according to ISO 22301:2012, an organization is required to determine the critical activities, the maximum tolerable period of disruption (MTPD), its recovery time objectives (RTO), and the minimum level at which each activity needs to be performed upon resumption. It’s a good practice at this stage to also determine the recovery point objective (RPO).

One of the main constraints that organizations encounter is how to develop a methodology to establish and document the prerequisites of a BIA in conformance with a specific standard or guideline. This article seeks to address this issue.

Methodological steps for developing a business impact analysis

The BIA “analyses the financial and operational impact of disruptive events on the business areas and processes of an organization” (Alexander, 2009). It is very important to be conceptually clear about this statement. The financial impact refers to monetary losses such as lost sales, lost funding and lost revenue. The operational impact represents non-monetary losses related to business operations and usually includes loss of competitiveness, poor customer service and damage to business reputation.

It is also crucial to understand that the findings of the BIA “enable an organization to determine the extent of the overall effort to recover from potential business disruption, and details the roadmap for developing the business continuity strategy and the incident management plan (IMP)” (Alexander, 2009). The BIA allows the organization to identify the critical processes of business and its continuity requirements, which become the main issues for the development of an IMP. “One of the fundamental aspects when developing a BIA is that it can help to determine whether or not the existing business continuity strategy addresses the recovery requirements” (Priti, 2017)

Figure one, below illustrates the methodological steps for developing a BIA.

Figure one: Methodological steps for developing a business impact analysis

A brief description of the steps follows:

1) Define the boundaries of the BIA: the starting point prior to the development of the BIA is the identification of the scope of the BCMS within the organization. Strategically, top management should have identified the scope, considering the products and services of the organization. Several key criteria could be considered to decide the products and services of the organization that need to be protected to assure continuity; including: a) market pressure, b) specific company sites, c) products and services profitability. Once the scope has been established, it is strategically recommended that its boundaries are outlined and precisely defined in terms of with what activity they initiate and with which one they terminate.

2) Identify activities that support the scope: an activity is considered a process or set of processes undertaken by an organization (or on its behalf) that produces or supports one or more products or services. When the scope of the BCMS is delimited, the organization should identify all the activities involved in the scope that directly contribute to the generation of its products and services. A good tool that helps in this step is a flowchart.

3) Assess Financial and operational impacts: the third step is to assess the financial and operational impacts that would affect the organization in the event of a disruption of the activities identified in the preceding step. The financial impact assessment is performed before carrying out the operational impact assessment.

(3a) The financial impact assessment: this measures the extent and severity of the organization’s financial losses. A financial impact assessment is carried out for each activity. The question to be asked is “What would the magnitude and severity of financial loss be if the activities were interrupted following a disruption?” The losses are estimated on a daily basis. Figure two offers an example of financial losses for a specific scope.

ACTIVITIES / MAGNITUDE FINANCIAL LOSS (US$) / SEVERITY LEVEL
¾ Help desk / 2,000.00 / 1
¾ Equipment maintenance / 2,000.00 / 1
¾ Software support / 2,000.00 / 1
¾ Applications development / 0 / 0
¾ Data base administration / 2,000.00 / 1
¾ Business client´s support / 2,000.00 / 1
¾ Training / 0 / 0
¾ Server administration / 9,000.00 / 2
¾ Management network equipment / 25,000.00 / 3
¾ Call logging administration / 17,000.00 / 3

Figure two: illustration of financial impacts

The second part of the financial impact assessment ranks each impact in a severity level based on its monetary loss value. The following scale is recommended:

·  Severity level 0: No impact

·  Severity level 1: Minor impact

·  Severity Level 2: Intermediate level

·  Severity level 3: Major impact

(3b) Operational impact assessment: the operational impact assessment measures the negative impact of a disruptive event on various aspects of business operations related to issues such as: customer satisfaction, cash flow, profitability and image. According to the industrial sector it belongs to and to the nature of its activities, each organization will identify the adequate operational impact criteria. Figure three shows some criteria that focus on five different operational aspects: cash flow, profitability, portfolio, image and customer satisfaction to illustrate operational impact ranking activities. The ranking values of each activity represent the level of negative impact in the event it is disrupted. The operational impacts can be measured using a quantitative ranking such as: none, low, medium, high, and highest.

ACTIVITIES / OPERATIONAL IMPACT RANKING
CASH FLOW / PROFITABILITY / PORTFOLIO / IMAGE / CUSTOMER SATISFACTION
¾ Help desk / None / None / None / None / None
¾ Equipment maintenance / None / None / None / None / None
¾ Software support / None / None / None / None / None
¾ Applications development / None / None / None / None / None
¾ Data base administration / None / None / Low / Medium / None
¾ Business client´s support / None / None / Low / Low / Low
¾ Training / None / None / None / None / None
¾ Server administration / High / High / Highest / High / High
¾ Management network equipment / High / High / High / High / High
¾ Call logging administration / Medium / Medium / High / Low / Low

Figure three: illustration of operational impacts

4) Identify critical activities: this step identifies the activities that have to be performed in order to deliver the key products and services, which enable an organization to meet its most important and time sensitive objectives. The financial and operational impact rankings assigned in step three provide a basis for identifying critical activities. An activity is considered critical if any of the following is true:

·  A severity level of 2 or 3 is assigned to its financial impact;

·  A ranking of high is assigned to at least three of its operational impacts;

·  A ranking of high is assigned to at least two of its operational impacts and a ranking of highest is assigned to at least one;

·  A ranking of highest is assigned to at least two of its operational impacts.

The critical activities listed in Figure four (below) were obtained by applying the above selection criteria to the impact rankings of business activities presented in figures two and three.

BUSINESS ACTIVITIES / CRITICAL ACTIVITIES
¾ Help desk
¾ Equipment maintenance
¾ Software support
¾ Applications development
¾ Data base administration / ¾ Data base administration
¾ Business client´s support
¾ Training
¾ Server administration / ¾ Server administration
¾ Management network equipment / ¾ Management network equipment
¾ Call logging administration / ¾ Call logging administration

Figure four: critical activities

5) Assess MTPDs and prioritize critical activities: “The maximum tolerable period of disruption (MTPD) is the duration after which the viability of the organization will be irrevocably threatened if product and service delivery cannot be resumed” (Alexander, 2009). The estimates of MTPD can be based on either financial or operational impacts. The personnel responsible for assessing the financial and operational impacts are asked the following question: “What is the maximum period of time that can be tolerated for this process based on the financial and operational impact levels?” Let’s imagine that the financial loss of US $25,000 per day becomes unacceptable when it exceeds US $50,000. Therefore, the MTPD is two days, since then the financial losses will exceed US $50,000, if the disruption continues for a longer period of time. This example assumes that the operational impacts are insignificant relative to the financial losses.

Usually the analysis requires revising the financial and operational impacts of the disruption to estimate the MTPD. Once the MTPDs are calculated, a priority for their recovery should be established. A critical activity that has a shorter MTPD compared with another critical activity is assigned a higher recovery priority. Considering today’s connectivity and the dependency on information technology, the trend of MTPDs is to shrink in terms of duration and probably they will be close to zero in the near future. Figure five presents the MTPDs and recovery priorities for the critical activities presented in Figure four.

CRITICAL ACTIVITIES / MTPDs minutes / RECOVERY PRIORITY
¾ Data base administration / 700 / 4
¾ Server administration / 240 / 1
¾ Management network equipment / 580 / 3
¾ Call logging administration / 260 / 2

Figure five: MTPDs and recovery priorities

6) Estimate the resources that each critical activity will require for resumption: in this step, the organization needs to estimate the resources required for resumption at the level of each critical activity. Previously, the firm should have identified the minimum level at which each critical activity needs to be performed upon resumption.

The sources that a business can use to determine the minimum levels of performance acceptable are the contractual agreements and service level agreements for the key products and services involved in the scope. The minimum resources needed for each activity can be classified as: (a) critical IT systems and applications, and (b) critical non IT resources. This second category can be subdivided in: ‘physical areas’, ‘human competences’, ‘equipment’ and ‘documents’. An illustration of critical activities and resources needed for resumption is shown in Figure six.

CRITICAL ACTIVITIES / CRITICAL IT SYSTEMS AND APPLICATIONS / CRITICAL NON IT RESOURCES
PHYSICAL AREAS / HUMAN COMPETENCE / EQUIPMENT / DOCUMENTS
¾ Data Base Administration / ¾ Desktop
¾ Data Base Software / 10 ft x 20 ft / Call center applications / CLS
NICE
Logger / Manual 5220
¾ Server Administration / ¾ Windows
¾ Servers / 10 ft x 20 ft / Instalment a configuration of windows servers / SQL
Server / Manual Standard Operation
¾ Management Network Equipment / ¾ LAN switches / 10 ft x 20 ft / CISCO
network
designed / CISCO
Catalyst
4948
Catalyst
3750
ASA / Manual Standard Operation
¾ Call Logging Administration / ¾ NICE / 10 ft x 20 ft / Call center applications / CC30
58720
Media
server / Manual Standard Operation

Figure six: critical activities and resources needed for resumption

7) Determine RTOs for critical activities: “The recovery time objective (RTO) is the target time set for resumption of product, service or activity delivery after an incident” (Fullick, 2013). The RTO, which is the length of time between a disruptive event and the recovery of resources, indicates the time available to recover disrupted resources. The MTPD value expresses the maximum limit for the RTO value.

The exercise of business continuity management arrangements enables the organization to validate its RTOs and, therefore, to take corrective actions to reduce them. Cross-functional teams involved with the critical activities, have the task to make the estimates of the RTOs. Figure seven offers an illustration of the RTOs for the critical activities identified in Figure four.

CRITICAL ACTIVITIES / RECOVERY TIME OBJECTIVES MINUTES / RECOVERY POINT OBJECTIVES MINUTES
¾  Data Base Administration / 500 / 150
¾  Server administration / 150 / 60
¾  Management Network / 400 / 90
¾  Call Logging Administration / 180 / 70

Figure seven: RTOs and RPOs for critical activities

8) Identify all dependencies relevant to critical activities: in this step the organization has to “consider all dependencies relevant to the critical activities, including suppliers and outsource partners” (Alexander, 2009) The critical activities that have been considered usually have some vital inputs that are provided by some other company processes or by external suppliers or outsource partners. The internal processes that supply important inputs to critical activities have also to be considered as critical activities. In the case of external suppliers and outsource partners, contractual agreements requiring them to have a BCMS set up and managed should be in place. It is important to bear in mind that every company is only as a resilient as its weakest link in the supply chain.

(9) Determine recovery point objectives for critical activities: the recovery point objective is the amount of data lost because of a business disruption. The RPO is the time that will take to investigate, repair and carry out all the arrangements to be able to activate the RTO. RPO is measured as the time between the last data backup and the disruptive event. In the BIA process, RPO is determined for each application, by asking the critical activity owners the following question: “What is the tolerance, in terms of length of time, to loss of data that may occur between any two backup periods?” The response to this question indicates the values of RPO. In Figure seven there is an example of RPOs for certain critical activities. The RPO has always to be less than the RTOs.