Conduct a Business Impact Analysis.

UCF ID: 01147

Control Type: Process or Activity

Status: Live

Supporting and supported controls

This control directly supports:

Correlate the risk assessment to the business impact of the evaluated risks. [UCF Control ID 00686]

This control has the following supporting controls:

Review past audit reports and Business Impact Analyses for outstanding issues. [UCF Control ID 01148]

Review the risk to the audit function of losing audit personnel. [UCF Control ID 01153]

Review the risk to the audit function due to changes in service providers and vendors. [UCF Control ID 01154]

Ensure the Business Impact Analysis identifies tolerance to downtime. [UCF Control ID 01172]

Review the current published guidance, training, and awareness programs. [UCF Control ID 01245]

Authority documents complied with:

FFIEC IT Examination Handbook – Business Continuity Planning, March 2008, Pg 8 thru Pg 10, Pg D-2, Pg D-5, Pg D-6, Pg F-1, Exam Tier I Obj 2.1, Exam Tier I Obj 2.5, Exam Tier I Obj 8.4; FFIEC IT Examination Handbook – E-Banking, August 2003, Pg 36; CMS Core Security Requirements (CSR), Draft, § 5.2.7; Health Insurance Portability and Accountability Act of 1996 (HIPAA), § 164.308(a)(7)(i), § 164.310(a)(2)(i), § 164.312(a)(2)(ii); Business Continuity Institute (BCI) Good Practice Guidelines, 2005, Stage 1.2 Process, Stage 1.1 Process; The Standard of Good Practice for Information Security, CI2.3.5; OGC ITIL: Security Management, § 2.2.4; Australia Better Practice Guide - Business Continuity Management, January 2000, Pg 13 ¶ 4 thru Pg 13 ¶ 6, Pg 36; BS 25999-1, Business continuity management. Code of practice, 2006, § 6.2.1, § 6.2.3; BS 25999-2, Business continuity management. Specification, 2007, § 4.1.1; Contingency Planning Guide for Information Technology Systems, NIST SP 800-34, Rev. 1 (Draft), § 3.2, § 5.1.1, App B; ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000, ¶ 10.1.1, ¶ 10.1.2, ¶ 10.1.3, ¶ 10.1.4, ¶ 10.1.5, ¶ 10.1.6

Banking and Finance Guidance

The organization should conduct a Business Impact Analysis (BIA) as part of the continuity planning process. The BIA should assess and prioritize all functions and processes that must be recovered; identify the impact of nonspecific events on the functions and processes; assess the impact of regulatory and legal requirements; estimate the maximum allowable downtime; consider the impact of a pandemic; and be evaluated during the risk assessment; be tested and incorporated into the continuity plan; and be reviewed and updated regularly. A copy of the BIA should be maintained offsite. [Pg 8 thru Pg 10, Pg D-2, Pg D-5, Pg D-6, Pg F-1, Exam Tier I Obj 2.1, Exam Tier I Obj 2.5, Exam Tier I Obj 8.4, FFIEC IT Examination Handbook – Business Continuity Planning, March 2008]

A business impact analysis should be conducted on the e-banking services to determine the minimum level of required service and recovery-time objectives. [Pg 36, FFIEC IT Examination Handbook – E-Banking, August 2003]

Healthcare and Life Science Guidance

[§ 5.2.7, CMS Core Security Requirements (CSR), Draft]

[§ 164.308(a)(7)(i), § 164.310(a)(2)(i), § 164.312(a)(2)(ii), Health Insurance Portability and Accountability Act of 1996 (HIPAA)]

NIST Guidance

The organization must conduct a business impact analysis (BIA). The purpose of the BIA is to correlate systems with critical business services and processes and then characterize the consequences of a disruption. The Information System Contingency Plan Coordinator uses the BIA results to determine the contingency requirements and priorities, and the BIA results should be incorporated into the Continuity of Operations, Business Continuity Plan and DRP. The BIA is accomplished during the Initiation phase of the SDLC and may need to be accomplished during the Acquisition/Development phase as systems evolve and change. The BIA consists of three steps: (1) Business processes and recovery criticality should be determined; (2) Resource requirements should be identified; and (3) Recovery priorities for system resources should be identified. The BIA results can help the organization determine what type of backup should be performed and how often, if redundancy or mirroring of data is needed, and what type of alternate site is needed to meet system recovery objectives. Appendix B contains a sample template to assist users in performing a BIA on an information system. [§ 3.2, § 5.1.1, App B, Contingency Planning Guide for Information Technology Systems, NIST SP 800-34, Rev. 1 (Draft)]

ISO Guidance

¶ 10.1.1 Loss of confidentiality. . An organization should consider what damage could arise from the loss of confidentiality of the asset(s) reviewed (intentional or unintentional). For example, loss of confidentiality might lead to
• loss of public confidence, or deterioration of public image,
• legal liabilities, including those that might arise from breach of data protection legislation,
• adverse effects on organizational policy,
• endangerment of personal safety, and
• financial loss.
According to the answers to the questions above, it should be decided whether the overall damage that could result from a loss of confidentiality would be serious, minor or none. This decision should be documented.
¶ 10.1.2 Loss of integrity. . An organization should consider what damage could arise from the loss of integrity of the asset(s) reviewed (intentional or unintentional). For example, loss of integrity might lead to
• incorrect decisions being made,
• fraud,
• disruption of business functions,
• loss of public confidence, or deterioration of public image,
• financial loss, and
• legal liabilities, including those that might arise from breach of data protection legislation.
According to the answers to the questions above, it should be decided whether the overall damage that could result from a loss of integrity would be serious, minor or none. This decision should be documented.
¶ 10.1.3 Loss of availability. . An organization should consider what damage could arise from other than short-term loss of availability of applications or information, i.e. which business functions, if interrupted, would result in response or completion times not being met. The extreme form of loss of availability, permanent loss of data and/or physical destruction of hardware or software, should also be considered. For example, the loss of availability of critical applications or information might lead to
• incorrect decisions being made,
• inability to perform critical tasks,
• loss of public confidence, or deterioration of public image,
• financial loss,
• legal liabilities, including those that might arise from breach of data protection legislation and from not meeting contracted deadlines, and
• significant recovery costs.
It should be noted that the damage resulting from loss of availability could vary considerably for different time periods of such loss. Where this is the case it will be advisable to consider all damages that might occur in such different time periods, and assess the damage for each time period as serious, minor or none (this information should be used in the safeguard selection).
According to the answers to the questions above, it should be decided whether the overall damage that could result from a loss of availability would be serious, minor or none. This decision should be documented.
¶ 10.1.4 Loss of accountability. . An organization should consider what damage could arise from the loss of accountability of users of systems or subjects (e.g. software) acting on the behalf of the user. This consideration should also include automatically generated messages that can cause an action to occur. For example, loss of accountability might lead to:
• system manipulation by users,
• fraud,
• industrial espionage,
• untraceable actions,
• false accusations, and
• legal liabilities, including those that might arise from breach of data protection legislation.
According to the answers to the questions above, it should be decided whether the overall damage that could result from a loss of accountability would be serious, minor or none. This decision should be documented.
¶ 10.1.5 Loss of authenticity. . An organization should consider what damage could arise from the loss of authenticity of data and messages, regardless whether they are used by people or systems. This is particularly important in distributed systems where decisions made are distributed to a wide community or where reference information is used. For example, loss of authenticity might lead to:
• fraud,
• a valid process being used with invalid data leading to a misleading result,
• manipulation of the organization by outsiders,
• industrial espionage,
• false accusations, and
• legal liabilities, including those that might arise from breach of data protection legislation.
According to the answers to the questions above, it should be decided whether the overall damage that could result from a loss of authenticity would be serious, minor or none. This decision should be documented.
¶ 10.1.6 Loss of reliability. . An organization should consider what damage could arise from the loss of reliability of systems. This is also important to address functionality which is a sub-characteristic of reliability (see ISO 9126). For example, loss of reliability might lead to:
• fraud,
• lost market share,
• demotivated staff,
• unreliable suppliers,
• loss of customer confidence, and
• legal liabilities, including those that might arise from breach of data protection legislation.
According to the answers to the questions above, it should be decided whether the overall damage that could result from a loss of reliability would be serious, minor or none. This decision should be documented. [¶ 10.1.1, ¶ 10.1.2, ¶ 10.1.3, ¶ 10.1.4, ¶ 10.1.5, ¶ 10.1.6, ISO/IEC 13335-4 Information technology — Guidelines for the management of IT Security — Part 4: Selection of safeguards, 2000]

ITIL Guidance

[§ 2.2.4, OGC ITIL: Security Management]

General Guidance

1.2 Process BIA talks about conducting a business impact analysis. The following steps are required:
Identify discrete business processes across the organization and management owners of these processes
Identify suitable staff from whom information can be sought about the business processes - subject matter experts
Identify the impacts which may result in damage to the organization’s reputation, assets or financial position
Quantify the time scale within which the interruption of each business function becomes unacceptable to the organization.
1.1 Process talks about conducting a business impact analysis to identify how a variety of threats may affect the organization. Threats include:
Loss of staff
Loss of location (single and/or multiple)
Telecommunications failure
Computer system failure (component and/or total)
Equipment failure (e.g. depending on industry: building management systems, manufacturing capacity)
Supplier failure [Stage 1.2 Process, Stage 1.1 Process, Business Continuity Institute (BCI) Good Practice Guidelines, 2005]

Software vulnerabilities should be identified and evaluated to determine applicability and business impact to the organization. [CI2.3.5, The Standard of Good Practice for Information Security]

UK and Canadian Guidance

The organization should conduct a business impact analysis to determine and document what impact a disruption would have on activities that support key services and products. The organization should consider impacts relating to the business objectives, aims, and stockholders and may include: the impact on public and staff wellbeing; the impact on the loss of or damage to technology, information, or facilities; the impact of requirement breaches; damage to financial viability or reputation; product deterioration or service quality; and environmental damage. [§ 6.2.1, § 6.2.3, BS 25999-1, Business continuity management. Code of practice, 2006]

The organization must have a defined, documented, and appropriate method to determine the impact of any disruption to activity that supports its key services and products. To accomplish this, the organization must identify all activities that support the key services and products; identify the impacts from disruption and how they vary over time; establish the maximum tolerable period of disruption by identifying the maximum amount of time by which each activity must resume, the minimum performance level each activity must be performed at after resumption, and the length of time that can pass before normal operating levels need to be resumed; categorize activities by their recovery priority and identify critical activities; identify all dependencies pertaining to the critical activities; determine which business continuity management arrangements are in place for products and services provided by suppliers and outsourced partners; set recovery time objectives for resuming critical activities; and estimate the required resources for each critical activity to resume. [§ 4.1.1, BS 25999-2, Business continuity management. Specification, 2007]

Asia and Pacific Rim Guidance

Pg 13 ¶ 4 thru 6 says that when analyzing the impact of an outage focus should be placed on consequences. Ideally, use bottom-up and top down approaches to business continuity management. Bottom-up approaches begin with the idea ‘what happens if controls fail?’ and then works from there towards controls. Top down management begins with consideration of likelihood and cause of an outage.
Pg 36 talks about conducting a business impact analysis. For this process, all key business processes should be documented, activities and resources critical to key business processes should be identified along with interdependencies between resources. All business processes and activities should be ranked. Operational and financial impacts of an outage should be considered, and each potential risk should be considered based on its likelihood of occurrence. [Pg 13 ¶ 4 thru Pg 13 ¶ 6, Pg 36, Australia Better Practice Guide - Business Continuity Management, January 2000]