# 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*.

<!--
Guidance: How to use this template
- Complete the business impact analysis summary (section 3) first. RTO,
  RPO and MTD drive every strategy and procedure that follows.
- Write procedures so that a competent engineer who has never seen the
  system can follow them at 3 a.m. with this document alone.
- Keep contact data in appendix A and reference it; contact details go
  stale faster than procedures.
- A plan that has never been exercised is an assumption. Section 9 is
  not optional.
- Store a copy outside the systems it recovers (printed, offline, or in
  a separate tenant).
-->

## Document control

<!-- Guidance: Identify the plan so every copy can be traced to one approved version. Classification matters: the plan contains infrastructure and contact details. -->

| Field | Value |
|---|---|
| Document ID | [DRP-ORG-001] |
| Systems covered | [System names or "see 1.3"] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Plan owner (DR coordinator) | [@name] |
| Classification | [Confidential] |
| Last exercised | YYYY-MM-DD |
| Next review due | YYYY-MM-DD |
| Related documents | [Business continuity plan], [Incident response plan], [Backup and restore procedure], [BIA report] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Head of IT / CTO | [@name] | [Decision] | YYYY-MM-DD |
| Information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Business continuity manager | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to systems, strategies, contacts and test outcomes. Auditors check that the plan changed after each exercise. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft from BIA results |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added payments database failover after tabletop exercise TT-03 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by executive sponsor |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Introduction](#1-introduction)
2. [Concept of operations](#2-concept-of-operations)
3. [Business impact analysis summary](#3-business-impact-analysis-summary)
4. [Recovery strategies](#4-recovery-strategies)
5. [Activation and notification](#5-activation-and-notification)
6. [Recovery](#6-recovery)
7. [Reconstitution](#7-reconstitution)
8. [Plan deactivation](#8-plan-deactivation)
9. [Testing, training and exercises](#9-testing-training-and-exercises)
10. [Plan maintenance](#10-plan-maintenance)
11. [Appendices](#11-appendices)

## 1. Introduction

<!-- Guidance: Explain why the plan exists, what it covers and what it deliberately does not cover. Readers in a crisis need to know in one minute whether this is the right document. -->

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

| In scope | Out of scope |
|---|---|
| *Example:* Production workloads in [cloud region / data centre] | Desktop and laptop recovery (see end-user IT procedure) |
| *Example:* Databases, object storage, message queues, DNS | Business process workarounds (see business continuity plan) |
| *Example:* Identity provider integration and secrets | Security incident investigation (see incident response plan) |
| [Item] | [Item] |

### 1.3 Systems covered

| System ID | System | Description | Owner | Criticality tier |
|---|---|---|---|---|
| SYS-01 | *Example:* Order API | Customer order intake and payment capture | [@name] | Tier 1 |
| SYS-02 | *Example:* Orders database (PostgreSQL) | System of record for orders | [@name] | Tier 1 |
| SYS-03 | *Example:* Reporting warehouse | Daily finance and sales reports | [@name] | Tier 3 |
| [SYS-nn] | [System] | [Description] | [@name] | [Tier] |

### 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

<!-- Guidance: Describe how recovery works as a whole before the detail: phases, who is in charge, and how teams fit together. -->

### 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.

| Phase | Starts when | Ends when | Owner |
|---|---|---|---|
| Activation and notification | Disruption detected and assessed | Plan activated and teams mobilised | DR coordinator |
| Recovery | Teams mobilised | Systems operating at the alternate environment | Recovery team leads |
| Reconstitution | Recovery complete and primary available | Operations back on primary, plan deactivated | DR coordinator |

### 2.3 Roles and responsibilities

| Role | Responsibilities | Primary | Alternate |
|---|---|---|---|
| Executive sponsor | Declares a disaster, approves spend, external decisions | [@name] | [@name] |
| DR coordinator | Activates plan, leads recovery, keeps the recovery log | [@name] | [@name] |
| Infrastructure team lead | Network, compute, DNS, alternate environment | [@name] | [@name] |
| Database team lead | Database restore, replication, data validation | [@name] | [@name] |
| Application team lead | Application deploy, configuration, functional checks | [@name] | [@name] |
| Security lead | Access control, secrets, evidence preservation | [@name] | [@name] |
| Communications lead | Staff, customer and regulator communications | [@name] | [@name] |
| [Role] | [Responsibilities] | [@name] | [@name] |

### 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.

```mermaid
flowchart TD
  ES["Executive sponsor"] --> DRC["DR coordinator"]
  DRC --> INF["Infrastructure lead"]
  DRC --> DB["Database lead"]
  DRC --> APP["Application lead"]
  DRC --> SEC["Security lead"]
  DRC --> COM["Communications lead"]
  INF --> INFT["Infrastructure team"]
  DB --> DBT["DBA team"]
  APP --> APPT["Application teams"]
  COM --> EXT["Customers, vendors, regulators"]
```

### 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

<!-- Guidance: Summarise the BIA, do not repeat it. Every number here must come from an approved BIA. If RTO is longer than MTD the plan is broken. -->

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

| System ID | System | Business process supported | MTD | RTO | RPO | Recovery priority |
|---|---|---|---|---|---|---|
| SYS-01 | *Example:* Order API | Taking orders | 8 h | 4 h | n/a (stateless) | 2 |
| SYS-02 | *Example:* Orders database | Taking orders, fulfilment | 8 h | 4 h | 15 min | 1 |
| SYS-03 | *Example:* Reporting warehouse | Finance reporting | 5 days | 72 h | 24 h | 5 |
| [SYS-nn] | [System] | [Process] | [MTD] | [RTO] | [RPO] | [n] |

### 3.2 Dependencies

| System ID | Depends on | Type | Must be recovered first |
|---|---|---|---|
| SYS-01 | SYS-02, identity provider, secrets store | Hard | Yes |
| SYS-03 | SYS-02 replica | Soft | No |
| [SYS-nn] | [Dependency] | [Hard / Soft] | [Yes / No] |

### 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$:

$$
\text{Downtime}_{\text{year}} = (1 - A) \times 8760 \ \text{h}
$$

*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$:

$$
\text{Data loss}_{\max} \approx \Delta t + \ell \le \text{RPO}
$$

*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

<!-- Guidance: For each system say how it will be recovered and why that option meets RTO and RPO at acceptable cost. Name the rejected options. -->

### 4.1 Strategy by system

| System ID | Strategy | Alternate location | Data protection | Meets RTO / RPO | Estimated cost per year |
|---|---|---|---|---|---|
| SYS-01 | *Example:* Warm standby, scale out on activation | Region B | Stateless; images in registry replicated | Yes, 1 h measured | [Amount] |
| SYS-02 | *Example:* Cross-region streaming replica, promote on activation | Region B | Continuous replication plus daily snapshot | Yes, RPO 1 min measured | [Amount] |
| SYS-03 | *Example:* Rebuild from infrastructure code and restore backup | Region B | Daily snapshot copied cross-region | Yes, 30 h measured | [Amount] |
| [SYS-nn] | [Backup and restore / Pilot light / Warm standby / Active-active] | [Location] | [Method] | [Yes / No] | [Amount] |

### 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

| Item | Arrangement | Vendor | Contract reference | Activation lead time |
|---|---|---|---|---|
| *Example:* Database licences in alternate region | Licence portability clause | [Vendor] | [Ref] | Immediate |
| *Example:* Emergency support | 24x7 priority support plan | [Vendor] | [Ref] | 1 h response |
| [Item] | [Arrangement] | [Vendor] | [Ref] | [Time] |

### 4.5 Strategies considered and rejected

| Option | Reason rejected |
|---|---|
| *Example:* Active-active across regions for SYS-02 | Write conflict handling not justified for an 8 h MTD |
| [Option] | [Reason] |

## 5. Activation and notification

<!-- Guidance: Make the decision to activate explicit and fast. Ambiguous criteria cause hours of debate while the RTO clock runs. -->

### 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:

| ID | Criterion | Example evidence |
|---|---|---|
| AC-01 | Primary environment unavailable and expected to remain so beyond 50% of the shortest RTO of an affected Tier 1 system | Provider status page, failed health checks across all zones |
| AC-02 | Data corruption or destruction that cannot be repaired in place within RTO | Ransomware indicators, failed integrity checks |
| AC-03 | Physical loss or denial of access to the facility | Fire, flood, power loss beyond generator capacity |
| [AC-nn] | [Criterion] | [Evidence] |

### 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.

```mermaid
flowchart TD
  D["Disruption detected"] --> A["Incident commander assesses impact"]
  A --> Q{"Meets an activation criterion?"}
  Q -- "No" --> IR["Continue incident response, reassess every 30 min"]
  IR --> A
  Q -- "Yes" --> DEC["Executive sponsor declares disaster"]
  DEC --> ACT["DR coordinator activates plan"]
  ACT --> CT["Contact tree started"]
  CT --> TM["Recovery teams assemble in bridge"]
  ACT --> COMMS["Communications lead notifies stakeholders"]
  TM --> REC["Recovery phase begins"]
```

### 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.]

| Question | Answer | Recorded by |
|---|---|---|
| What is the cause and is it contained? | [Answer] | [@name] |
| Which systems and data are affected? | [Answer] | [@name] |
| Is the primary environment usable within RTO? | [Yes / No] | [@name] |
| Is there evidence of compromise? | [Yes / No] | [@name] |

## 6. Recovery

<!-- Guidance: Give step-by-step procedures in recovery priority order. Each step names the performer, the command or action, and how to verify it worked. -->

### 6.1 Recovery sequence

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

```mermaid
flowchart LR
  P1["1. Network, DNS, identity, secrets"] --> P2["2. SYS-02 Orders database"]
  P2 --> P3["3. SYS-01 Order API"]
  P3 --> P4["4. Tier 2 systems"]
  P4 --> P5["5. SYS-03 Reporting"]
```

### 6.2 Procedure: SYS-02 Orders database

| Step | Action | Performer | Verification | Done at |
|---|---|---|---|---|
| 1 | *Example:* Confirm replication lag on the region B replica from the last available metric | DBA | Lag value recorded in the log | [hh:mm] |
| 2 | *Example:* Fence the primary to prevent split brain (revoke network access) | Infrastructure | Primary unreachable from region B | [hh:mm] |
| 3 | *Example:* Promote replica: `[promote command]` | DBA | Replica reports read-write mode | [hh:mm] |
| 4 | *Example:* Run integrity checks: row counts and latest order timestamp | DBA | Latest order within RPO of the outage start | [hh:mm] |
| 5 | *Example:* Update connection secret to the new endpoint | Security | Secret version incremented | [hh:mm] |
| [n] | [Action] | [Role] | [Check] | [hh:mm] |

### 6.3 Procedure: SYS-01 Order API

| Step | Action | Performer | Verification | Done at |
|---|---|---|---|---|
| 1 | *Example:* Scale the region B deployment from 2 to 20 instances | Application | All instances healthy | [hh:mm] |
| 2 | *Example:* Switch DNS weighted record to region B, TTL 60 s | Infrastructure | External probe resolves to region B | [hh:mm] |
| 3 | *Example:* Place a test order with the internal test account | Application | Order visible in SYS-02 | [hh:mm] |
| [n] | [Action] | [Role] | [Check] | [hh:mm] |

### 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.]

| Step | Action | Performer | Verification | Done at |
|---|---|---|---|---|
| 1 | [Action] | [Role] | [Check] | [hh:mm] |

### 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

<!-- Guidance: Reconstitution is often the riskiest part: moving back to the primary without losing data written during recovery. Plan it as carefully as failover. -->

### 7.1 Validation of recovered systems

Before declaring recovery complete, verify each system:

| Check | Method | Pass criterion | Result |
|---|---|---|---|
| Functional test | *Example:* Scripted smoke test suite | 100% pass | [Pass / Fail] |
| Data validation | *Example:* Reconcile order counts with payment provider | Difference explained | [Result] |
| Security controls | Logging, monitoring, access control active | All alerts flowing | [Result] |
| Performance | Load at normal peak | p95 latency within SLO | [Result] |

### 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

<!-- Guidance: Close the event formally so that costs stop, temporary access is removed and lessons are captured. -->

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

<!-- Guidance: Each Tier 1 system needs a functional test at least yearly. Record evidence: what was tested, measured RTO and RPO, and issues found. -->

### 9.1 Exercise schedule

| ID | Type | Scope | Frequency | Next date | Owner |
|---|---|---|---|---|---|
| EX-01 | Tabletop exercise | Activation, notification, decision making | Twice a year | YYYY-MM-DD | [@name] |
| EX-02 | Functional test | SYS-02 replica promotion in isolated environment | Quarterly | YYYY-MM-DD | [@name] |
| EX-03 | Full failover | All Tier 1 systems to region B | Yearly | YYYY-MM-DD | [@name] |
| EX-04 | Restore test | Random backup restored and verified | Monthly | YYYY-MM-DD | [@name] |
| [EX-nn] | [Type] | [Scope] | [Frequency] | YYYY-MM-DD | [@name] |

### 9.2 Exercise results

| Exercise | Date | Target RTO | Measured RTO | Target RPO | Measured RPO | Issues raised |
|---|---|---|---|---|---|---|
| *Example:* EX-02 | YYYY-MM-DD | 4 h | 52 min | 15 min | 40 s | DR-ISS-07: promotion script lacked timeout |
| [EX-nn] | YYYY-MM-DD | [RTO] | [Measured] | [RPO] | [Measured] | [Issue IDs] |

### 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

<!-- Guidance: Plans decay when systems change. Tie plan updates to change management and to exercise outcomes. -->

### 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

| ID | Source | Action | Owner | Due | Status |
|---|---|---|---|---|---|
| DR-ISS-07 | *Example:* EX-02 | Add timeout and retry to promotion script | [@name] | YYYY-MM-DD | [Open / Done] |
| [DR-ISS-nn] | [Source] | [Action] | [@name] | YYYY-MM-DD | [Status] |

### 10.3 Distribution

| Copy | Holder | Format | Location |
|---|---|---|---|
| 1 | DR coordinator | Printed and offline PDF | [Location] |
| 2 | Executive sponsor | Offline PDF | [Location] |
| 3 | Shared | Read-only, separate tenant | [Location] |

## 11. Appendices

<!-- Guidance: Keep fast-changing reference data here so the procedures stay stable. -->

### Appendix A. Personnel and vendor contacts

| Name / company | Role | Phone | Email | Alternate contact |
|---|---|---|---|---|
| [@name] | DR coordinator | [+00 000 000 000] | [email] | [@name] |
| *Example:* [Cloud provider] | Enterprise support | [Number] | [Portal URL] | [Account manager] |
| *Example:* [Database vendor] | Priority support | [Number] | [email] | [Contract ID] |
| [Name] | [Role] | [Phone] | [Email] | [Alternate] |

### Appendix B. System inventory

| System ID | Component | Version | Location | Configuration source | Backup location |
|---|---|---|---|---|---|
| SYS-02 | *Example:* PostgreSQL cluster | 16.x | Region A, 3 nodes | [Infrastructure code repository and path] | [Backup bucket in region B] |
| [SYS-nn] | [Component] | [Version] | [Location] | [Source] | [Location] |

### 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

| Time (UTC) | Event or decision | By | Notes |
|---|---|---|---|
| [hh:mm] | Plan activated under criterion [AC-nn] | [@name] | [Notes] |

### Appendix F. Glossary

| Term | Meaning |
|---|---|
| BIA | Business impact analysis |
| DRP | Disaster recovery plan |
| MTD | Maximum tolerable downtime |
| RPO | Recovery point objective |
| RTO | Recovery time objective |
| Warm standby | Alternate environment running at reduced capacity, ready to scale |

## 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.