IT Disaster Recovery Plan: [Organisation or system name]

Complete IT disaster recovery plan (DRP) for restoring information systems at an alternate site or environment after a major disruption. The structure follows the contingency planning process and plan outline described in NIST SP 800-34 Rev. 1 (public domain): plan overview, activation and notification, recovery, reconstitution and appendices. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction
2. Concept of operations
3. Business impact analysis summary
4. Recovery strategies
5. Activation and notification
6. Recovery
7. Reconstitution
8. Plan deactivation
9. Testing, training and exercises
10. Plan maintenance
11. Appendices

1. Introduction

This plan describes how [Organisation] restores the IT systems listed in 1.3 after a disruption that makes the primary environment unavailable for longer than its tolerable downtime. It is one part of the wider contingency planning programme and is invoked by the business continuity plan or by the incident commander.

1.1 Purpose

[State the objective. Example: "Restore customer-facing order processing within 4 hours and internal reporting within 72 hours of a declared disaster affecting the primary cloud region, with no more than 15 minutes of order data loss."]

1.2 Scope

1.3 Systems covered

1.4 Assumptions

• Example: Backups in the secondary region are intact and less than 24 hours old.
• Example: At least two people from each recovery team are reachable within 1 hour.
• Example: The identity provider and DNS registrar remain available.
• [Assumption that, if false, would invalidate the plan]

1.5 Applicable policies and requirements

[List the policies, contracts, regulations and SLAs that set recovery obligations. Example: "Customer SLA SLA-2026-01 commits to 99.9% monthly availability; payment card rules require restoring logging before processing resumes."]

2. Concept of operations

2.1 System overview

[Describe the production architecture, the alternate environment, and where data is replicated. Reference the architecture document rather than duplicating it. Example: "Production runs in region A across three availability zones. A warm standby runs in region B with database replicas and scaled-down compute."]

2.2 Recovery phases

Recovery proceeds through three phases in sequence. Each phase has an owner and an exit criterion recorded in the recovery log.

2.3 Roles and responsibilities

2.4 Contact tree

The contact tree shows who calls whom after activation. Each caller confirms receipt and reports unreachable people to the DR coordinator. Phone numbers live in appendix A.

2.5 Line of succession

[State who takes over if the DR coordinator or executive sponsor is unavailable, and how authority is handed over. Example: "If the DR coordinator does not acknowledge within 30 minutes, the infrastructure lead assumes the role and records the handover in the recovery log."]

3. Business impact analysis summary

The business impact analysis identified the following recovery objectives. Definitions:

• MTD (maximum tolerable downtime): the longest outage the business process can survive before unacceptable consequences.
• RTO (recovery time objective): the target time to restore the system after disruption. RTO must be shorter than MTD to leave time for verification.
• RPO (recovery point objective): the maximum acceptable age of data at the point of restoration, which sets backup and replication frequency.

3.1 Recovery objectives by system

3.2 Dependencies

3.3 Expected availability and data loss

Use these expressions to check that the recovery objectives are consistent with the availability promised to customers.

Expected annual downtime for a system with target availability $A$:

Example: $A = 0.999$ allows about 8.76 hours per year. A single disaster with RTO of 4 hours uses roughly 46% of that budget.

Worst-case data loss for a system replicated or backed up every $\Delta t$, with replication lag $\ell$:

Example: Continuous replication with $\ell = 30\,\text{s}$ meets an RPO of 15 minutes; nightly backups ($\Delta t = 24\,\text{h}$) do not.

4. Recovery strategies

4.1 Strategy by system

4.2 Alternate site or environment

[Describe the alternate environment: provider, region or facility, capacity on standby versus on activation, quotas that must be raised in advance, and how access is obtained. Example: "Region B holds pre-approved quotas for 200 vCPU; standby runs at 20% capacity."]

4.3 Backup strategy

[Summarise backup frequency, retention, encryption and offsite or cross-account copies. Reference the backup and restore procedure for detail.]

4.4 Equipment, licences and vendor agreements

4.5 Strategies considered and rejected

5. Activation and notification

5.1 Activation criteria

The plan is activated when any of the following is true and the executive sponsor or DR coordinator declares a disaster:

5.2 Activation and notification flow

The flow below shows the path from detection to mobilised recovery teams. Timestamps for each step go into the recovery log.

5.3 Notification procedure

1. DR coordinator opens the recovery bridge: [call link or phone number].
2. DR coordinator starts the recovery log at [location outside affected systems].
3. Callers follow the contact tree in 2.4 and report status within 30 minutes.
4. Communications lead sends the internal notice and, if required, the customer notice using the templates in appendix D.
5. Security lead confirms whether evidence must be preserved before systems are changed.

5.4 Damage assessment

[Describe how the team determines the cause, the systems affected, the expected duration and whether the primary site can be used. Record the outcome in the recovery log before choosing the recovery path.]

6. Recovery

6.1 Recovery sequence

Systems are recovered in the priority order from 3.1, respecting the dependencies in 3.2.

6.2 Procedure: SYS-02 Orders database

6.3 Procedure: SYS-01 Order API

6.4 Procedure: [System]

[Repeat the table for each system in 1.3. Where a system is rebuilt from infrastructure code, include the repository, tag and pipeline to run.]

6.5 Recovery escalation

[State what to do when a step fails or exceeds its time box: who to escalate to, vendor support numbers in appendix A, and the decision point for switching to the next strategy.]

7. Reconstitution

7.1 Validation of recovered systems

Before declaring recovery complete, verify each system:

7.2 Return to primary environment

1. Confirm the primary environment is repaired and the root cause is addressed.
2. Re-establish replication from the alternate environment to the primary.
3. Agree a maintenance window and notify users (appendix D).
4. Switch traffic back using the reverse of the recovery procedure, verifying each step.
5. Keep the alternate environment ready for [48 hours] in case of failure.

7.3 Concurrent processing

[State whether the primary and alternate environments run in parallel during transition, for how long, and how data consistency is checked.]

8. Plan deactivation

The DR coordinator deactivates the plan when reconstitution is complete and the executive sponsor agrees. Deactivation tasks:

• Announce deactivation to all teams and stakeholders.
• Revoke emergency access and rotate any secrets shared during recovery.
• Scale the alternate environment back to standby.
• Archive the recovery log, chat transcripts and timeline.
• Hold a post-event review within [5 working days] and record actions in 10.2.
• Refresh backups and verify replication in the steady state.

9. Testing, training and exercises

9.1 Exercise schedule

9.2 Exercise results

9.3 Training

[List training for each role: who must be trained, on what, how often, and how completion is recorded. New team members are trained within [30 days] of joining an on-call rotation.]

10. Plan maintenance

10.1 Review triggers

The plan owner reviews this plan at least [annually] and whenever:

• a system in scope is added, retired or re-architected;
• recovery objectives change in the BIA;
• an exercise or a real event reveals a gap;
• key staff, vendors or contracts change.

10.2 Improvement actions

10.3 Distribution

11. Appendices

Appendix A. Personnel and vendor contacts

Appendix B. System inventory

Appendix C. Alternate environment details

[Account or subscription IDs, network ranges, access method, quota limits and the runbook for bringing standby capacity to full size.]

Appendix D. Communication templates

Internal activation notice: "The IT disaster recovery plan was activated at [hh:mm timezone] due to [cause]. Join the recovery bridge at [link]. Next update at [hh:mm]."

Customer notice: "[Service] is unavailable due to [plain-language cause]. We are restoring service from our recovery site and expect an update by [hh:mm timezone]. Status: [status page URL]."

Appendix E. Recovery log

Appendix F. Glossary

Standard and licence note

Based on NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems (public domain, U.S. Government work), for the plan structure, the recovery phases and the BIA concepts of MTD, RTO and RPO. The wording, tables and examples are original text written for this collection. Template licence: MIT.