Business Impact Analysis

The Business Impact Analysis (BIA) is developed as part of the Business Continuity Plan process and is a point-in-time analysis of system components that determines the criticality and potential impact to Bramble’s mission-critical processes and data as well as impact to Bramble should the system component become unavailable. This quantitative analysis allows Bramble to establish priority levels for sequencing recovery activities and resources.

Purpose

The purpose of the BIA is to identify and prioritize system components by correlating them to mission critical processes that support the functioning of Bramble. Using this information to characterize what would be the impact to Bramble, if any of these systems were to be unavailable.

Scope

The scope of the BIA is the entirety of systems utilized across Bramble. Team members refer to the inventory of systems as the tech stack. Note that due to the nature of the information that is maintained in the tech stack, it is not available as a publicly facing document.

Roles and Responsibilities

Role Responsibility
Security Risk Team Executes an annual BIA. For new systems that have not previously undergone a BIA, a holistic one will be performed. All other systems that have gone through an initial BIA will undergo a targeted BIA process to validate and obtain the most up-to-date data related about it’s use at Bramble.
IT Compliance Utilizes the data obtained from the BIA to drive Business Continuity Planning activities.

BIA Procedure

  1. A formal BIA questionnaire is distributed to the technical system owners for each system, as listed in the tech stack. If there are multiple individuals listed, one team member will be selected.
  1. Once all responses have been received, the data will be sanitized and aggregated. Follow-ups with technical owners will be completed as required to ensure the data used is accurate, complete, and objective.

  2. Mission critical systems are identified and next steps are taken to ensure that a system recovery/business continuity plan is documented accordingly.

  3. On a periodic basis, the BIA is reviewed and will be reperformed. While we do not anticipate significant changes year over year, as part of our due diligence and compliance needs, Bramble is required to make sure that system recovery/business continuity plans are up-to-date so that team members are always prepared to respond to system disruptions or outages.

BIA Ouputs:

  1. Determining data classification and approved operating System usage: Bramble data and system resources can more clearly be linked to mission critical business processes by way of classifying them based on sensitivity. These priority levels can be established for sequencing recovery activities and resources. Additionally, the existence of an approved set of operating systems platforms will facilitate ease of management and quick turnaround and repair when they are non-functional.

  2. Determining mission critical business processes and recovery criticality: In this step, Bramble’s mission critical business processes / systems are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime reflects the maximum, that an organization can tolerate while still maintaining the mission.

  3. Identifying resource requirements: Realistic recovery efforts require a thorough evaluation of the resources required to resume business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include software, data files, system components, and vital records.

  4. Determining alternate storage and strategies: Identify any alternate strategies in place to meet expected RTOs. This includes backup or spare equipment and vendor support contracts.Bramble alternate storage process, serves to securely store data in an alternate location from source data

  5. Identifying recovery priorities for system resources based on standards: Adherence to Bramble’s agreed upon RTO/ RPO: Apart from determining the RTO and RPO, BIA also defines Maximum Tolerable Downtime (MTD)

    • The Maximum Tolerable Downtime (MTD) - represents the total amount of time senior management are willing to accept for a mission/business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave continuity planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content.
  6. Delegating and defining the process: Designate each incident as critical or non-critical based on the business priority. Compile a list of personnel who must be in place to perform these functions. In times of an occurrence of an incident, a detailed step-by-step approach about how to communicate it to the group, how it is performed, who performs it, and the operational mode of action taken.

The following links show the process carried out at Bramble to cater to this requirement:

Reporting

The most important part of the Business Impact Analysis is to weigh the exactness of all findings. Communicate the findings to the respective department managers or key personnel to ensure that the assumptions made are in fact accurate and realistic. Once the accuracy of the documented findings has been established and agreed to by all parties, these BIA findings are submitted to Bramble’s leadership for approval.

Plan update and protect from disclosure

The BIA report will be updated based on changes to the organization, information system, or environment of operation and problems encountered during the implementation, execution, or testing. This plan will be protected from unauthorized disclosure and modification. Finally, all the Business Impact Analysis data will be stored in a safe place for future reference in the event of a disaster.

Exceptions

There are no systems that are exempt from the BIA procedures. Note that Bramble may procure new systems throughout an annual period. While the Security Risk Team will work towards performing a BIA for new systems in a timely manner, systems may periodically not have a BIA performed until the next annual BIA.

References