Disaster Recovery Plan: Tiers, Roles and Proof
A disaster recovery plan is only worth the last rehearsal behind it, so tier the services, name the dependencies and file a measured recovery time.
A disaster recovery plan is the written answer to "what do we do when a whole thing is gone", agreed while everyone is calm. It names the systems, ranks them, says who acts, and states how long each one may stay down. The document is easy. Keeping it true is the hard part.
What counts as a disaster here
Not every outage qualifies. NIST's glossary defines the plan as a written procedure for recovering information systems at an alternate facility after a major failure or the destruction of a site.
That word "alternate" is the dividing line. If the fix is a restart, it is an incident. If the fix is running somewhere else, from a copy, with data that may be stale, it belongs in this document.
What goes in a disaster recovery plan
Ready.gov's guidance starts with an inventory of hardware, software and data, and that ordering is right. You cannot rank what you have not listed.
- Scope and trigger. What situations invoke the plan, and who is allowed to declare one.
- Service inventory with tiers. Every system, with an owner and a recovery target.
- Dependency map. Including the third parties you do not control, such as a payment provider, a mail relay or a registrar.
- Recovery procedures per tier. Written as steps someone unfamiliar can follow at 3am.
- Roles and a contact tree. With a path that works when your own chat tool is part of the outage.
- Communications. Who tells customers, through which channel, and how often.
- Backup and restore verification. The date of the last successful restore, not the last successful backup.
- Test calendar and results log. Dated entries, with the measured numbers.
Sections one to seven are what most templates give you. Section eight is what separates a plan from a wish.
Tier your services instead of setting one target
A single company-wide recovery target is always wrong. It is either too expensive for your internal dashboards or too slow for checkout, and usually both at once.
| Tier | Example service | Recovery target | Data loss budget | What it costs |
|---|---|---|---|---|
| 1 | Checkout, auth | 15 minutes | 1 minute | Warm standby, replication, rehearsed cutover |
| 2 | Public site, docs | 4 hours | 1 hour | Redeploy from an image, hourly snapshots |
| 3 | Reporting, exports | 24 hours | 24 hours | Nightly backup, restore when convenient |
| 4 | Internal dashboards | Best effort | 7 days | Rebuild from source when someone asks |
Those two middle columns are the recovery time objective and the recovery point objective, and mixing them up is the most common error in the whole exercise. RTO vs RPO unpicks the difference properly, including why the clock starts earlier than teams assume.
We prefer four tiers over three. Three pushes everything ambiguous into the middle band, and the middle band is where budgets go to die.
Map the dependencies you do not own
Your plan can be perfect and still fail on something you have no control over. A registrar with an expired card. A certificate authority you cannot reach. A managed database in the same region as everything else you are failing away from.
Write each external dependency down with three facts: what breaks without it, what the fallback is, and how you would find out. That third column is usually empty, and an empty third column means the first sign of trouble is a customer.
Announced work belongs in the same document too, because a drill that looks like an outage burns exactly the trust the plan exists to protect. Put the rules in your maintenance window policy and reference them here.
How do you test a disaster recovery plan?
You rehearse it, and you measure the rehearsal from outside the system you broke. Internal orchestration logs report when the standby became ready, which is not the same moment your customers could use the service again.
We tested a documented four-hour target on a stack whose standby came up in under a minute. Measured from the public hostname, recovery took a little over nine minutes, because resolvers were still handing out the old address. The plan was not wrong about the standby. It was wrong about what the customer experienced.
Run the drill, record the first failed check, the first recovered check and the gap. Failover testing covers the mechanics of the drill itself, including the fail-back that most teams never rehearse.
Filing the evidence
Each test should leave an artifact that someone can read a year later without you in the room. A timeline works best. Probe detects failure at 14:02:30, standby promoted at 14:03:10, first successful external check at 14:11:45. That is a measured recovery of nine minutes fifteen seconds against a four-hour target.
Measuring that from one location is not enough, because a regional failure takes your only observer with it. Six probe regions are available as of September 2026, and their egress addresses are on the probe IPs page if your drill runs behind a tight firewall.
Keep the history alongside the plan. A free account holds a month of check history as of September 2026, while Individual stretches that to a year and Enterprise to two. An annual drill is worth very little when the evidence expires before the following one.
Common mistakes
Writing targets nobody costed. A fifteen-minute target with nightly backups and no standby is a sentence, not a capability. Either buy the standby or raise the number in the document.
Backing up without restoring. A backup you have never restored is an untested assumption with a storage bill. Restore one on a schedule and write the date in the plan.
One contact tree, inside the tools that just died. Keep an offline copy, and confirm at least one channel that does not depend on your own infrastructure.
Reviewing the disaster recovery plan annually. Infrastructure drifts in weeks. Pin the review to deploys of tier one services rather than to a date in the calendar.
A disaster recovery plan earns its keep when the tiers are costed and the dependencies are named. The last drill should have a measured number next to it rather than a tick. Start with the inventory, tier it honestly, then prove one recovery this quarter and file the timeline. You can measure that first rehearsal on the free plan, which includes 10 monitors as of September 2026, so open an account before you schedule the drill.
FAQ
A written procedure for getting information systems running again after a major failure, usually at an alternate site and from a copy of the data. NIST frames it around that alternate facility, which is the useful dividing line. If a restart fixes it, you have an incident; if you have to run somewhere else from a copy, the recovery plan applies.
Scope and trigger conditions, a service inventory with recovery tiers, a dependency map that includes third parties, step by step recovery procedures, roles and a contact tree that works when your chat tool is down, a communications plan, evidence that backups restore, and a test calendar with dated results.
More often than annually, because infrastructure drifts in weeks rather than months. A small quarterly drill on one tier one service beats a large yearly exercise that nobody schedules. Tie the review to significant deploys rather than to a calendar date, and keep the measured recovery time from every rehearsal.
Business continuity covers how the organisation keeps operating, including people, premises and processes. Disaster recovery is the technical subset: which systems come back, in what order, at what site and with how much data loss. The recovery plan feeds the continuity plan with realistic timings rather than aspirational ones.
Related reading
- RTO vs RPO: Two Clocks, and How to Set Both - RTO vs RPO compares two clocks from one failure: time offline and work lost. Set them per workload, and buy down the detection term first.
- Failover Testing: Prove the Standby Actually Works - Failover testing proves your standby takes over before a real outage runs the experiment for you. Here is how to run the drill and measure it.