<Project Name>

Disaster Recovery Plan

Disaster Recovery Plan Template Instructions

(Please remove this section before completion of template)

The Disaster Recovery Plan objective is to provide key Disaster Recovery personnel with all pertinent information in order to have the project added to the University Disaster Recovery plan. This plan will outline the functionality of the system, hardware, software, and provide an overview of the business need to allow the Disaster Recovery personnel to make an informed decision on how to implement the best recovery model in the event of a disaster.

Be sure to maintain version control as the analysis is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant. See below for requirements for a project and deliverable approvals.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Project Deliverable	Requirements by Project Size
Planning/Development Phase	Large	Medium	Small	Requirements	Approvals
Disaster Recovery Plan (SDLC)	O	O	O	This deliverable is optional for all project sizes, unless requested by the Sponsor, Steering Committee or IT management.	The Disaster Recovery Plan should be approved by the Sponsor, the Steering Committee, Implementation Team, at a minimum. And, the IT Infrastructure Department for sign-off on requirements, design and costs.

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

1.3.	Business Continuity	2

1.3.1	Critical Business Functions	2

1.3.2	Recovery Point Objective	2

1.3.3	Recovery Time Objective	3

2.	Version Control	5

3.	Overview	6

3.1 Application Overview	6

3.2 Hardware Overview	7

4.	Architecture	8

4.1 Software:	8

4.2 Hardware	8

5.	Communications	9

5.1 Communication Plan	9

5.2 Contact Profile	9

6.	Recovery Procedures	11

7.	Testing	12

8.	Approval	13

Dictionary of Terms	14

Introduction

Purpose

The objective of this document is to provide key Disaster Recovery personnel with all pertinent information in order to have the <Insert System Name>added to the University Disaster Recovery plan. This plan will outline the functionality of the system, hardware, software, and provide an overview of the business need to allow the Disaster Recovery personnel to make an informed decision on how to implement the best recovery model in the event of a disaster affecting the hardware, software, connectivity, or other unforeseen event that will prevent access, operation, or use of said system.

Assumptions

The disaster recovery of this System and/or application relies on the following critical assumptions. If any of these assumptions are not true at the time of the disaster, then the user facility must remain in downtime procedure mode until all such assumptions are true.

<Insert assumption>

<Insert assumption>

<Insert assumption>

Business Continuity

Critical Business Functions

Identify the suspected organizational functions and/or activities that will be dependent on the application and/or system being implemented. Analyze the identified functions, and then determine only critical functions.

Please use the table below

Recovery Point Objective

Once the critical functions of the application and/or system have been identified, each one must have a Recovery Point Objective documented. This describes the acceptable amount of data loss measured in time. Generally, this is the definition of what an organization determines is an "acceptable loss" in a disaster situation.

Example: If there is a complete replication at 10:00am and the system dies at 11:59am without a new replication, the data written between 10:00am and 11:59am will not be recovered from the replica. This amount of lost time data has been deemed acceptable because of the 2 hour RPO. This is the case even if it takes an additional 3 hours to get the site back into production. The production will continue from the point in time of 10:00am. All data in between will have to be manually recovered through other means.

Please use the table below

Recovery Time Objective

Document the Recovery Time Objective which will determine the duration of time for and a service level that a critical business process must be restored to after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.

Please use the table below

This document provides an outline listed in the order of importance of the suspected “Critical Business Functions” that are reliant on the <Insert System Name>, Recovery Point Objective, and the Recovery Time Objective will be considered in the development of the Business Continuity plan of the afore mentioned system. Since the system is not fully implemented the anticipated Critical Functions, Recovery Point and Recovery Time Objective’s must be re-evaluated prior to the finalization of the Business Continuity plan.

Business Continuity
Overview
Critical Business Function
Recovery Point Objective
Recovery Time Objective
Critical Business Function
Recovery Point Objective
Recovery Time Objective
Critical Business Function
Recovery Point Objective
Recovery Time Objective

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

Overview

3.1 Application Overview

Outline all components and overall use of application. Please include vendor documentation as an attachment, if applicable.

Application/Software
Overview
Application Name:
Application Description:
Application Type:
Version at Install:
Current Version:
Delivery Method
Financial Impact	Y/N	If yes Explain:
Account Management of Users
Medical System Impact	Y/N	If yes Explain:
Access method:	Port:
User Location
Used By Department(s)
Install Media	Reinstall Media Location:

Application/Software Backup
Application Component	Data Size GB	Frequency	Method	Storage

3.2 Hardware Overview

Outline all components of the hardware required or used for the implementation. Please include vendor documentation as an attachment, if applicable.

Hardware/Server
Server Type
Server brand:	Server topology:
Server model #:	Server serial #:
Disk Information
Number of Disks	Size of each disk
Disk Type	Disk Interface
Raid Number	Total Available Space
Operating System
OS:	Service Pack/Version:
Physical Location
Street Address	Suite
City	State	Zip Code
Server Access Information
Server(s) name:
IP Address(s):	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx	xxx.xxx.xxx.xxx
Mac Address(s):	xx-xx-xx-xx-xx-xx	xx-xx-xx-xx-xx-xx	xx-xx-xx-xx-xx-xx	xx-xx-xx-xx-xx-xx
Active Directory OU:
Warranty Information
Length of Warranty
Warranty Start Date	Warranty End Date
Labor	Parts

System and/or Application Interface
Interface Engine:
Interfaces – Inbound:
Interfaces – Outbound:
Other Comments:

Architecture

4.1 Software:

Refer to the Software Architecture Plan document.

4.2 Hardware

Refer to the Hardware Architecture Plan document.

Communications

5.1 Communication Plan

Refer to the Communication Plan for unscheduled downtime procedures, processes and the order in which the contacts below will be notified of said downtime.

5.2 Contact Profile

Support Personnel
Hardware Administrator(s)
Contact Type	Name	E-Mail	Office	EXT.	Cell/Pager
Administrator
Secondary Admin
Back/Restore Admin
Network Administrators
Contact Type	Name	E-Mail	Office	EXT.	Cell/Pager
Administrator
Secondary Admin
Back/Restore Admin
Application Admin
Contact Type	Name	E-Mail	Office	EXT.	Cell/Pager
Administrator
Secondary Admin
Back/Restore Admin
Vendors
Contact Type	Name	E-Mail	Office	EXT	Cell/Pager
Vendor Contact
Technical Contact:
Alt Technical Contact
Vendor Support
Technical Support Links
UMDNJ Support Link(s)
Vendor Support Link(s)
Offsite Backup Storage Link(s)

Recovery Procedures

This section describes the recovery strategies identified for equipment and services.

Items that may be included:

Server Recovery Procedures: (include server restoration priorities)

Application Recovery Procedures

Application Functionality and Data Integrity Validation Procedures

Complete Restore needs

Security Procedures: (If warranted)

System Restoration Checklist

This may also just be a reference to the current Disaster Recovery Plan. Identify which schedule the system and/or application will belong to.

Testing

Identify where this system and/or application will fall into the current Disaster Recovery Plan testing phases. If it does not fall into the university current disaster recovery testing, outline the testing for this system or application.

Approval

The individuals below agree that they have reviewed and approved the requirements outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Appendix A

Dictionary of Terms

Assumptions - an assertion about some characteristic of the future that underlies the current operations or plans of an organization.

Business Continuity - an extension of disaster recovery, aimed at allowing an organization to continue functioning after (and ideally, during) a disaster, rather than simply being able to recover following a catastrophic event.

Critical Business Function - A function may be considered critical if the implication for stakeholders of damage to the organization is the halt of day to day business. A function may also be considered critical if dictated by law. Perceptions of the acceptability of disruption may be modified by the cost of establishing and maintaining appropriate business or technical recovery solutions.

Recovery Point Objective - This describes the acceptable amount of data loss measured in time. Generally this is the definition of what an organization determines is an "acceptable loss" in a disaster situation.

Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.