Disaster Recovery Plan Template: RTO and RPO per System

9 min read ยท 2026-11-15

A disaster recovery plan template for IT works best when you build it one system at a time. For a company of about 200 people, one entry looks like this: "Order database: business owner head of operations, Tier 1, RTO 4 hours, RPO 15 minutes, continuous replication." You write an entry like that for every application, database and service, then you test each one.

Each record holds five things: the system's owner, its tier, how fast it must be back (RTO), how much data you can lose (RPO) and the method that restores it. Once every system has a tested record, you can present the plan and defend it.

This guide gives you the template with every field explained. It also includes a full example for that fictional 200-person company, the phases to complete the plan with owners and milestones, and how to present the result to leadership or an auditor.

The roadmap at a glance

Goal: Produce an approved IT disaster recovery plan with a complete record for every system, each with a tested RTO and RPO. Duration: 8 to 10 weeks for the first approved version, then a review every quarter

  1. Inventory every system (Weeks 1 to 2)

    Build the list that the rest of the plan depends on.

    • Name an executive sponsor and a plan owner, usually the IT manager or head of infrastructure.
    • List every application, database, server, cloud service and network link.
    • Give each one a business owner and a technical owner.
    • Map its dependencies: identity, DNS, network, databases, third-party APIs.

    Milestone: A complete inventory, each system with two named owners.

  2. Rank systems and set RTO and RPO (Weeks 2 to 4)

    Turn business impact into numbers each owner signs.

    • Ask each business owner what stops after one hour, one day and one week of downtime.
    • Sort systems into Tier 1 critical, Tier 2 important and Tier 3 can wait.
    • Set an RTO and an RPO for each system, not for each tier, so every target can be checked on its own.
    • Get written confirmation from each business owner.

    Milestone: A signed list of systems with tier, RTO and RPO.

  3. Check targets against reality (Weeks 4 to 6)

    Make sure each target can be met with what you have today.

    • Compare each RPO with the real backup or replication schedule of that system.
    • Compare each RTO with the last measured restore time, or estimate it with the engineer who owns the system.
    • Choose a recovery method for each system: hot standby, warm standby, restore from backup, or vendor recovery.
    • Log every mismatch on a gap list with a cost, an owner and a deadline.

    Milestone: A recovery method for each system and a gap list approved by the sponsor.

  4. Write runbooks and the call tree (Weeks 6 to 8)

    Give each critical system a procedure that someone other than its author can follow.

    • Write one runbook per Tier 1 system: start conditions, ordered steps, expected result after each step.
    • Add recovery checks: logins work, data is current, integrations respond.
    • Write a fail back procedure to return to the primary environment.
    • Build a call tree with phone numbers that still work if email and chat are down.

    Milestone: Runbooks for every Tier 1 system, reviewed by a second engineer.

  5. Test, measure and sign off (Weeks 8 to 10)

    Replace estimated recovery times with measured ones.

    • Run a tabletop exercise on a realistic scenario with the full recovery team.
    • Restore at least one Tier 1 system in an isolated environment and time it.
    • Record the actual recovery time next to its RTO in the system record.
    • Fix the gaps, update the plan and present it for sign-off.

    Milestone: A test report and a signed version 1.0.

  6. Maintain (Every quarter)

    Keep each system record accurate as things change.

    • Review owners, targets and the call tree every quarter.
    • Update the affected records after every incident, test or major change.
    • Keep a dated change log.

    Milestone: A change log and a test calendar for the next twelve months.

The system record: fields of the template

The system record is the core of this disaster recovery plan template. Fill in one for each system, using the fields below.

Build the full plan around these records: purpose and scope, risk assessment and business impact analysis, roles and call tree, backup and recovery strategy, communication plan, testing and maintenance calendar, and appendices such as vendor support lines and network diagrams. Keep the main document short enough to read under stress. The detail belongs in the records and runbooks.

  • System name and description: what it does, in one line a non-technical reader understands.
  • Business owner: the person who decides what downtime is acceptable.
  • Technical owner and backup: who restores it, and who does it if that person is unavailable.
  • Tier: 1, 2 or 3, with the reason in one sentence.
  • RTO: the maximum acceptable downtime.
  • RPO: the maximum acceptable data loss, measured in time.
  • Current backup or replication: method and frequency as they run today.
  • Recovery method: standby, restore, rebuild or vendor.
  • Dependencies: what must be restored first.
  • Last test: date, type of test and measured recovery time.
  • Open gaps: what prevents meeting the target, with an owner.
  • Runbook location: where the procedure is stored, including an offline copy.

IT disaster recovery plan example, filled in

Here is the full example for the fictional 200-person company. It runs an online store, an ERP and office tools in the cloud. The targets are only illustrations. Yours must come from your own impact analysis.

Declaration rule in this example: the IT director declares a disaster when a Tier 1 system is down and the expected fix will take longer than its RTO. If the director cannot be reached, the infrastructure lead makes the call. One clear sentence like this avoids the debate that often delays recovery.

  • Identity and single sign-on (Tier 1, critical): business owner IT director, technical owner infrastructure lead, RTO 1 hour, RPO 15 minutes. Every other system depends on it, so it is restored first.
  • E-commerce platform (Tier 1, critical): business owner head of digital, RTO 4 hours, RPO 15 minutes, warm standby in a second cloud region. Depends on identity and the order database.
  • Order database (Tier 1, critical): business owner head of operations, technical owner database administrator, RTO 4 hours, RPO 15 minutes, continuous replication.
  • ERP and finance (Tier 2, important): business owner finance director, RTO 24 hours, RPO 4 hours, restore from snapshots taken every four hours.
  • Customer support desk, SaaS (Tier 2, important): business owner support manager, RTO 24 hours, vendor-managed recovery, with a shared inbox as a fallback.
  • Intranet and internal wiki (Tier 3, can wait): business owner IT service desk, RTO 72 hours, RPO 24 hours, nightly backup.
  • Reporting dashboards (Tier 3, can wait): business owner data lead, RTO 72 hours, rebuilt from the restored databases.

How RTO and RPO per system expose the real gaps

RTO is how long a system can be down. RPO is how much data you can afford to lose, measured in time. An RPO of four hours means losing up to four hours of entries is acceptable.

Setting both targets for each system, rather than for each tier, shows where the plan exists only on paper. Two common cases are listed below.

Each mismatch goes on the gap list with a cost and an owner. That list is often the most useful page for leadership, because it turns risk into clear budget decisions.

  • The RPO is shorter than the backup schedule: a system backed up once a night has a real RPO of up to 24 hours, whatever the plan says. Either back it up more often or change the target with the business owner's agreement.
  • The RTO ignores dependencies: the e-commerce platform cannot meet a 4-hour RTO if identity takes 3 hours to restore and the database another 2. Add up the whole chain before you sign a target.

How to test a disaster recovery plan

Many teams test at least once a year and again after major changes. Teams with critical systems or frequent changes often test parts of the plan more often. Mix several types of exercise.

After each test, write the measured recovery time into the system record, next to its RTO. Note what failed and who will fix it by when. If a test changes nothing, that usually means nobody looked closely.

Test the call tree too. A clear call tree, saying who to call and why, cuts the hesitation in the middle of a crisis. Call every number once a quarter and fix the ones that no longer work.

  • Walkthrough: the team reads the plan together and flags outdated steps.
  • Tabletop exercise: a facilitator plays out a scenario, such as ransomware on a Friday night, and the team talks through its decisions.
  • Partial restore test: restore one system in an isolated environment and time it.
  • Full failover test: switch production to the standby environment, then fail back.

Presenting the plan to leadership or an auditor

Leadership does not want the runbooks. They want to know what is protected, how fast it comes back, what is still at risk and what it costs to close the gap. Build a one-page summary with four blocks.

Auditors for frameworks such as SOC 2 or ISO 27001 usually care more about evidence than about a long document. Have these ready: the approved plan with its version and date, the sign-off, the latest test report, and a change log that shows updates after each test. Presenting the plan as a timeline with phases, owners and milestones also answers their usual follow-up question: how do you keep it current?

  • Coverage: the number of systems in each tier, with their RTO and RPO.
  • Proof: the last test date and the measured recovery times against the targets.
  • Gaps: each open gap with its cost and owner.
  • Decisions needed: budget, risk acceptance or a change of target.

Common mistakes to avoid

  • Letting IT set every RTO alone, when business owners must confirm the downtime they can accept.
  • Setting targets for each tier only, which hides the systems that cannot meet them.
  • Writing an RPO of 15 minutes for a system that is backed up nightly.
  • Signing an RTO without adding up the restore times of its dependencies.
  • Keeping the only copy of the plan on the systems it is meant to recover.
  • Naming one person per role instead of a primary and at least one backup.
  • Leaving the "last test" field empty for months, so the targets are never measured.

Frequently asked questions

What is the difference between RTO and RPO?

RTO is the maximum time a system can stay down before the impact becomes unacceptable. RPO is the maximum amount of data, measured in time, that you can afford to lose. A finance system can have a long RTO and a short RPO: it can wait a day, but it must not lose transactions.

Should RTO and RPO be set per system or per tier?

Per system. Tiers help you rank systems and choose recovery methods, but each system has its own backup schedule and dependencies. A target set for one system can be checked and tested on its own.

How often should a disaster recovery plan be tested?

Many teams test at least once a year and after major changes, such as a cloud migration or a new core system. Review owners, targets and the call tree every quarter so the plan stays accurate between tests.

Who should declare a disaster?

One named person with authority, usually the IT director or CIO, plus at least two named backups. Write the trigger into the plan, for example a Tier 1 outage expected to last longer than its RTO.

What is the difference between a DRP and a BCP?

A disaster recovery plan restores IT systems and data. A business continuity plan keeps the whole business running during a disruption, including people, sites, suppliers and manual workarounds. The DRP is usually one part of the BCP.

Generate this roadmap with AI