Technical Disaster Recovery Plan

System / platform: [Name] Owner: [Team or person] Date: [Date] Last tested: [Date] Next review: [Date]

---

1. Scope and critical systems

[State what this plan covers and what it explicitly does not. List the systems in scope and rate how critical each is, so recovery effort is prioritised correctly.]

System	Function	Criticality	Depends on
[System 1]	[What it does]	[Critical / High / Medium]	[Dependency]
[System 2]	[What it does]	[Critical / High / Medium]	[Dependency]
[System 3]	[What it does]	[Critical / High / Medium]	[Dependency]

2. Recovery targets (RTO / RPO)

[Set the maximum tolerable downtime and data loss for each critical system. These numbers drive every other decision in this plan.]

System	RTO (max downtime)	RPO (max data loss)
[System 1]	[e.g., 30 minutes]	[e.g., 5 minutes]
[System 2]	[e.g., 4 hours]	[e.g., 1 hour]
[System 3]	[e.g., 24 hours]	[e.g., 24 hours]

3. Backup strategy

[Describe what is backed up, how often, where it is stored, retention, and how restores are verified.]

• What: [Databases, object storage, configuration, secrets]
• Frequency: [e.g., continuous replication + hourly snapshots + daily off-site copy]
• Location: [Primary region, plus an isolated off-site / cross-region / cross-account copy]
• Retention: [e.g., 7 daily, 4 weekly, 12 monthly]
• Restore verification: [How and how often you prove a backup actually restores]

4. Failover and recovery procedures

[For each failure scenario, give ordered, concrete steps, who triggers them, and how success is confirmed.]

Scenario A — [e.g., primary database failure]

1. [Detect and confirm the failure — alert, dashboard, health check]
2. [Declare the incident and notify the on-call lead]
3. [Promote the standby replica / restore from the latest snapshot]
4. [Repoint the application at the new primary]
5. [Verify reads and writes succeed; confirm RPO actually met]
6. [Communicate status; close the incident]

Scenario B — [e.g., full region outage]

1. [Trigger condition and who decides]
2. [Fail over to the secondary region]
3. [Update DNS / traffic routing]
4. [Validate critical user journeys]
5. [Communicate; monitor for stability]

5. Roles and contacts

Role	Responsibility	Name	Contact (incl. out-of-hours)
Incident commander	Declares the disaster, owns decisions	[Name]	[Phone / channel]
Recovery lead	Executes the technical steps	[Name]	[Phone / channel]
Communications	Updates customers and stakeholders	[Name]	[Phone / channel]
Escalation	Final authority / vendor contact	[Name]	[Phone / channel]

6. Test schedule

Test type	What it proves	Frequency	Last run
Tabletop exercise	Roles, comms, decision flow	[e.g., Quarterly]	[Date]
Restore drill	Backups are restorable + complete	[e.g., Monthly]	[Date]
Failover drill	Real RTO is met	[e.g., Twice a year]	[Date]

7. Recovery checklist

[A condensed, in-the-moment checklist for the person doing the recovery.]

• Incident declared and commander assigned
• Scope of impact confirmed (which systems, how many users)
• Latest good backup / replica identified and its age checked against RPO
• Recovery procedure for the scenario started
• Service restored and critical journeys verified
• Data integrity confirmed
• Customers and stakeholders informed
• Incident closed; recovery time and data loss recorded
• Post-incident review scheduled; plan updated