Plan

Developing a plan is a key component of disaster recovery (DR) best practices. When creating a DR plan, make sure you use the following resources:

DR Policies and Procedures webpage to ensure compliance with university standards.
Utilize the Backup and DR Plan Job Aid when creating or reviewing backup or recovery plans.
Set prioritization by using the Criticality Matrix.
Ensure a Chain of Custody Form is completed and stored/on file in accordance with the unit’s IT procedures, for a minimum of one year unless otherwise specified by the unit’s record retention schedule. More information can be found in the university’s Information Security Control Requirements (ISCR) IT1.1.5.

Key Terms: Recovery Time Objective and Recovery Point Objective

As defined by the National Institute of Standards and Technology's (NIST) Computer Security Resource Center (CSRC), RTO is the overall length of time an information system’s components can be in the recovery phase before negatively impacting the organization’s mission or mission/business processes.

For the DR Program, the RTO is based off the system’s capability (the overall time length to restore – includes system components and data):

When determing the RTO for your systems, keep the following in mind:

Assume requirements outside of your control are available, e.g., power, network, and central authentication.
If you have a redundant site, assume everything there is operational.
- Note: Large scale scenarios such as a mass power outage, loss of multiple data centers, the loss of staff available to do the recovery or the spread of ransomware throughout the organization would extend system recovery times past documented RTOs.
Choose from the following RTO parameters:
- 1 Hour 2 Hours 4 Hours 12 Hours 24 Hours 48 Hours 72 Hours
  7 Days 14 Days 21 Days 30 Days > 30 Days No Recovery

Additional guidance when choosing RTO:

If your RTO capability does not match one of these parameters, select the next highest RTO. For example, if your RTO capability is 26 Hours, then you would choose 48 Hours because you would not be able to meet an RTO of 24 Hours.
RTO is based on system recovery. This includes the time to recover system components and data. RTO ends when the system is operational and is handed back to the business for data validation and input of data captured from paper procedures during downtime. If a system must be available regardless of data, or if there is a difference between when the system can be available and when it must be available (for example if a system needs to be available in 12 Hours, but the system is not capable of meeting that need), Business Continuity Managment and DR must work together to understand recovery objectives.

Any system thought of as “Best Effort” should be evaluated for capability and > 30 days should only be used if the RTO is truly beyond 30 days.
RTO times should be selected based off each individual system’s (application or service) ability to recover and should not account for the time required to bring dependent systems online, for example the network or central authentication.

The RPO is defined by NIST's CSRC as the point in time to which data must be recovered after an outage.

For the DR Program, the RPO is the amount of time since the data was last backed up.

Choose from the following RPO program parameters:
- 1 Hour 2 Hours 4 Hours 12 Hours 24 Hours 48 Hours 72 Hours
  7 Days 14 Days 21 Days 30 Days > 30 Days No Backups

Additional guidance when choosing RPO:

If your RPO does not match one of these parameters, select the next higher RPO. For example, if your backup is every 8 Hours then you would choose 12 Hours because 8 Hours is not a parameter.
RPO times are used to understand how much data could be lost.

1 Hour	2 Hours	4 Hours	12 Hours	24 Hours	48 Hours	72 Hours
7 Days	14 Days	21 Days	30 Days	> 30 Days	No Recovery

1 Hour	2 Hours	4 Hours	12 Hours	24 Hours	48 Hours	72 Hours
7 Days	14 Days	21 Days	30 Days	> 30 Days	No Backups