Frequently Asked Questions

The strategic and tactical capability of the university to plan for and respond to disruptions and to continue operations at an acceptable predefined level.

The reliance or interaction, directly or indirectly, to an application or system to support a critical business function or process required during a disruption.

BCM is a holistic management process that identifies potential threats to the university and the impacts on operations of those threats, if realized, might cause. It provides a framework for building organizational resilience with the capability of an effective response that safeguards functions and processes critical to the university's mission.

The Business Owner of an IT Application, in consultation with the Information Technology team (typically during the Systems Development Lifecycle), establishes an acceptable RTO/RPO for Business Application(s) prior to production release. Application data, over time, integrate into business operations forming new, and sometimes complex, dependency relationships. BCM tracks this expansion/contraction of use and assesses gaps (Business “need” vs IT recovery “capability”) that may require further business risk mitigation/continuity planning effort.

Yes.  The University BCM Policy became effective on July 1, 2020.

The Business Continuity Management Office will annually provide the gap report of operational need versus systems and applications (dependencies) recovery capability.  NOTE:  This data is not to be used to set RTO’s and RPO’s.

College/Unit leaders (e.g., dean, senior vice president, president, provost) are accountable for BCM for their areas. The Business Continuity Representative (BCR) is accountable for ensuring BCM activities are completed. 

Appointed by the college/unit leader, the individual identified leads and is accountable for ensuring unit BCM activities are completed.

The Business Continuity Management Office will publish a performance scorecard and distribute it to the BCRs, unit leaders, Risk Management Committee and The Office of Business and Finance. An annual update of the BCM program will be provided to the President’s Cabinet and the Board of Trustees, as appropriate.

The process of analyzing activities and the effect that an operational disruption might have upon them. The BIA lists critical functions and gives guidelines on tolerable downtime.

The process of identifying and minimizing the exposures to certain threats that an organization may experience.

A Business Continuity Plan (BCP) documents procedures that guide the university to recover, resume, and restore to a pre-defined level of operation following an unplanned disruption. This type of plan addresses disruption of critical business operations and supports achieving objectives based on BIA, RA, and Senior Leadership approved resumption objections.

A Disaster Recovery Plan (DRP) documents procedures that guide the university to recover, resume, and restore Information Technology to a pre-defined level of operation, at an alternate location, following a data center disaster. This type of plan addresses loss of the Data Center and supports achieving objectives outlined in an IT Disaster Declaration Agreement.

An Information Technology Contingency Plan (ITCP) documents procedures that guide the university to recover, resume, and restore Information Technology to a pre-defined level following disruption of technology service(s). This type of plan assumes the data center is available and supports achieving IT Service Level Agreements.

A Building Emergency Action Plan (BEAP) documents Building life safety procedures and objectives.

An event that interrupts normal business functions and operations, whether anticipated (e.g., flood, tornado) or unanticipated (e.g., blackout, technology failure).

Process or function that cannot be interrupted or unavailable for more than a mandated or predetermined timeframe without significantly jeopardizing the university mission.

The Recovery Time Objective (RTO) is the period of time following an incident or disruption within which a critical function and/or process and application and/or system must be resumed, recovered or restored to avoid unacceptable risks or consequences.

The business function RTO is initially set during the BIA process. The IT system application and system RTO is initially set during the Systems Development Lifecycle prior to production release.

The RPO indicates how much data the business can lose before it is unacceptable. (For example, the business has a manual process that will allow two days [48 hours] of work to get re-entered into the system resulting in an RPO of 48 hours. Anything beyond 48 hours of lost data would be unacceptable to business operations.)

The RPO is also how much data is expected to be lost by IT systems and applications during an IT disruption or due to an Information Technology Disaster. (For example, application data is backed up nightly resulting in an RPO of 24 hours, so the business can expect to lose up to 24 hours of data when the system is restored to operations). 

The Business sets the RPO during the BIA process.

The IT Application Owner initially sets the RPO during the Systems Development Lifecycle prior to production release.  It is reviewed and updated, as needed, during the System Development Lifecycle.

During the BIA process application dependencies and “needs” are identified from all business areas that consider any application critical to their operation. The “need” is then compared to the existing IT Disaster Recovery “capability” to determine gaps.