This section provides orientation on the processes carried out in the system to support BIA. According to ISO 22301, business impact analysis is the process of analyzing business functions and the effects that an interruption may have on them. The underlying idea of a BIA is to analyze the organization's business components and estimate the impacts that an interruption would have on them, allowing them to be deemed critical to the organization or not and prioritized for continuity efforts.
The system offers support for managing and automating BIA processes through workflows that allow the status of each BIA to be monitored, and sends notifications to those involved in the analysis on what is expected of them at each stage.
The first step is to take an inventory of business components and the assets that support them considered relevant in terms of business continuity. During this phase, the properties of these business components and assets are provided in the Organization module, including the people responsible for them, their relevance, and their associations with other business components and assets. Business continuity-specific fields are provided in the BIA Data tab and Continuity Requirements tab that can be enabled in the Administration module for one or more types of business components. Especially important during this phase is completion of the Table of Impacts in the BIA Data tab, which scores different impacts over time. For example, the financial impact of an interruption to a certain business component is scored on a timeframe that ranges from immediate to 30 days. For details on enabling these tabs, see Chapter 17: Administration -> Customizations -> Display Options.
The next step is to begin a business impact analysis (BIA) in the Continuity module, which is a set of activities to determine the importance of each of the organization's business components according to the resulting impact if they are interrupted. During this step, business components are included in the scope of the BIA and the information registered on them is submitted for review. Those assigned as responsible for them can then confirm or update this data – including their associations with assets and the scores for the different types of impacts over time. This information must be validated and can optionally be submitted for approval. Any number of approvers can be assigned to review the information provided by the person responsible for the business component, and approvers can approve this data or request changes. Once approved, an Impact Score is calculated, which through the default formula is based on the estimated impacts over time. The Impact Score is thus the main output of a business impact analysis.
The Impact Score is used to help continuity managers determine whether or not a business component included in the scope of the BIA is critical, which can be done by simply selecting the business component and marking it as critical or not. For business components deemed critical, those responsible for them should use the BIA information provided for each in the BIA Data tab of each business component in the Organization module to then complete the fields in the Continuity Requirements tab.
Especially important properties in the Continuity Requirements tab are the RPO (Recovery Point Objective) and RTO (Recovery Time Objective). The RPO is the acceptable point or level for recovering data. It is supposed here that in many instances there will only be a partial recovery of data compared to the level available prior to the interruption. For example, if the backup routine for data related to product sales runs every 18 hours, this implies that in the worst case scenario up to 18 hours of data will be lost. The RPO then for this process is 18 hours, given that there is a tolerance for losing up to 18 hours' worth of data.
The RTO, on the other hand, is the time that the organization considers optimal for systems, applications, services, or processes to be restored after an interruption caused by an incident. For example, there may be clauses in Service Level Agreements that determine that customer support services cannot be interrupted for over 24 hours and impose fines if they are. In this case, the RTO for this process would be 24 hours. The RTO may also indicate the object time for recovering an activity or service at a pre-established level.
A third property related to the RTO is the MTPD, the maximum tolerable period of disruption for a service, application, or system. According to ISO 15999, this is the "duration after which the viability of the organization will inevitably be threatened if the delivery of products and services cannot be restored". Managers use this parameter to determine, for example, that the MTPD of a given process is 5 days, after which if the system or service is not restored, there are significant risks to the business or to the continuity of the organization itself. Note that the RTO must be less than or equal to the MTPD.
Next, the resources required by the business component to ensure its continuity should also be specified on this tab. A specific table is provided for this, where any number of assets can be associated with their respective contingency assets, and details can be provided to qualify this association. This information can be used when preparing continuity plans for the business component.
A summary of this process is provided below:
1) Continuity managers select the business components that will be included in the scope of a business impact analysis.
2) Continuity managers set revision parameters for each business component included in the scope of the BIA, including the revision frequency and the people to be assigned to approve data on them once they have been reviewed by those responsible for them. Note that approval is optional, and if no approvers are assigned the business component data will be considered valid once the person responsible confirms it.
3) A revision of business component data is initiated so that continuity managers can be sure that accurate, up-to-date data is being used. In this step, those assigned as responsible for each business component in the Organization module will review the data on each, make any necessary changes, and confirm it.
4) Once reviewed, business component data is then confirmed by any approvers assigned. Approvers have the option of rejecting this data, providing details on why it was not approved so that those responsible for the business component can then make any necessary changes.
5) Once confirmed by the final approver on the list, the Impact Score is calculated.
6) The Impact Score is used to help continuity managers determine whether or not the business component is critical and if strategies and plans should be prepared to ensure its continuity.
7) Once critical business components have been identified, continuity managers should ensure that those responsible for them provide details on the continuity requirements for each, available as a separate tab for each business component in the Organization module.