Department: UW Medicine Information Technology Services
Policy Number:
Review Date: April 27th, 2007
Purpose:
The purpose of this guideline is to help System Owners be successful within the scope of performing a Business Impact Analysis on their systems..
Definitions
· See SEC-REF UW Medicine Information Security Program Glossary of Terms.
Standard
A Business Impact Analysis should correlate specific system components with the critical services that they provide, and based on that information, to characterize the consequences of a disruption to the system components It is the responsibility of the System Owner to perform appropriate business impact analysis tasks as outlined within this standard.
I. Identify Critical IT Resources
Each System Owner should evaluate his/her System to determine the critical functions performed by the system and to identify the specific system resources required to perform them. Two activities usually are needed to complete this step:
1) The System Owner should identify and coordinate with internal and external users associated with the system to characterize the ways that they depend on or support the system. When identifying contacts, it is important to include organizations that provide or receive data from the system as well as contacts supporting any interconnected systems. This coordination should enable the System Owner to characterize the full range of support provided by the system, including security, managerial, technical, and operational requirements.
2) The System Owner should evaluate the system to link these critical services to system resources. This analysis usually will identify infrastructure requirements such as electric power, telecommunications connections, and environmental controls. Specific IT equipment, such as application servers, and authentication servers, are usually considered to be critical. However, the analysis may determine that certain IT components, such as a printer or print server, are not needed to support critical services.
II. Identify Outage Impacts and Allowable Outage Times
The System Owner should analyze the critical resources identified in the previous step and determine the impact(s) on IT operations if a given resource were disrupted or damaged. The analysis should evaluate the impact of the outage in two ways.
1) The effects of the outage may be tracked over time. This will enable the System Owner to identify the maximum allowable time that a resource may be unavailable before it prevents or inhibits the performance of an essential function.
2) The effects of the outage may be tracked across related resources and dependent systems, identifying any cascading effects that may occur as a disrupted system affects other processes that rely on it.
3) The effects of the outage may be tracked using revenue streams and cost expenditures, identifying any areas of monetary need or concern that could cause a delay in the recovery effort.
The System Owner will determine the optimum point to recover the IT system by balancing the cost of system inoperability against the cost of resources required for restoring the system.
III. Develop Recovery Priorities
The System Owner should develop recovery priorities for the system resources. The System Owner should use a high-, medium-, low-scale to prioritize the resources. High priorities are based on the need to restore critical resources within their allowable outage times; medium and low priorities reflect the requirement to restore full operational capabilities over a longer recovery period.
The outage impact(s) and allowable outage times characterized in the previous step enable the System Owner to develop and prioritize recovery strategies that personnel will implement during contingency plan activation. For example, if the outage impacts step determines that the system must be recovered within 4 hours, the System Owner would need to adopt measures to meet that requirement. Similarly, if most system components could tolerate a 24-hour outage but a critical component could be unavailable for only 8 hours, the System Owner would prioritize the necessary resources for the critical component. By prioritizing these recovery strategies, the System Owner may make more informed, tailored decisions regarding contingency resource allocations and expenditures, saving time, and effort .
IV. Business Impact Analysis Documentation Requirements
System Owners are responsible for maintaining the Business Impact Analysis document(s). An annual review of the Business Impact Analysis should be performed by the System Owner to ensure accuracy and completeness.
References:
I. 45 CFR Part 164; Section 308(a)(7) (ii) (E) Applications and Data Criticality Analysis
II. ISO/IEC 17799 Section 11, Business Continuity Management
III. NIST (National Institute of Standards and Technology) Special Publication 800-34, Contingency Planning Guide for Information Technology Systems
UW Medicine IT Services: Date:
James S. Fine, M.D., CIO, ISO
Business Impact Analysis (BIA) Template
This sample template is designed to assist the system owner in performing a BIA for an IT system. The template is meant only as a basic guide and may not apply to all systems. The system owner may modify this template or the general BIA approach as required to best accommodate the specific system.
System Information
|
UW Medicine Entity: |
Date BIA Completed: |
|
|
Department: |
BIA Contact: |
|
|
System Name: |
||
|
System Owner: |
||
|
System Description: {Discussion of the system purpose and architecture, including system diagrams} |
||
|
A. Identify System Contacts |
Role |
|
|
Internal {Identify the individuals, positions, or offices within your department that depend on or support the system; also specify their relationship to the system} |
||
|
|
|
|
|
External {Identify the individuals, positions, or offices outside your department that depend on or support the system; also specify their relationship to the system} |
||
|
|
|
|
|
B. Identify System Resources {Identify the specific hardware, software, and other resources that comprise the system; include quantity and type} |
||
|
Hardware |
||
|
Software |
||
|
Environmental |
||
|
Infrastructure |
||
|
Dependent Systems |
||
|
Other resources |
||
|
C. Identify critical roles {List the roles identified in Section A that are deemed critical} |
|
|
|
D. Link critical roles to critical resources {Identify the IT resources needed to accomplish the roles listed in Section C} |
|
|
Critical Role |
Critical Resources |
|
|
|
|
|
|
|
|
|
|
E. Identify outage impacts and allowable outage times {Characterize the impact on critical roles if a critical resource is unavailable; also, identify the maximum acceptable period that the resource could be unavailable before unacceptable impacts resulted} |
||
|
Resource |
Outage Impact |
Allowable Outage Time |
|
|
|
|
|
|
|
|
|
|
|
|
|
F. Prioritize resource recovery {List the priority associated with recovering a specific resource, based on the outage impacts and allowable outage times provided in Section E. Use quantitative or qualitative scale (e.g., high/medium/low, 1-5, A/B/C)} |
|
|
Resource |
Recovery Priority |
|
|
|
|
|
|