RTO and RPO are usually set by asking the business what it wants, which reliably returns 'zero'. This worksheet sets them the other way round: measure what you can currently deliver, price the gap, and let the business choose knowingly.
Measure actual capability first. Fill the 'measured actual' column from real restore tests before you fill the target column. Negotiating targets without knowing current capability produces numbers nobody can hold.
Price the downtime. An hour of outage on this system costs roughly what? Lost revenue, idle staff, SLA credits, regulatory exposure. A system costing £200/hour and one costing £40,000/hour should not share an RTO.
Map dependencies before committing. An application with a one-hour RTO that depends on an identity provider with a four-hour RTO has a four-hour RTO. Chains are the most common reason stated objectives are quietly fictional.
Present the gap as a priced choice. Where target and capability diverge, state what closing it costs. That converts 'IT cannot meet the RTO' into 'the four-hour RTO costs this much; the one-hour RTO costs that much', a decision the business can actually make.
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Fill measured actuals from restore tests. If a cell is empty, the objective beside it is aspirational.
| System | Business process supported | Cost of downtime / hour | Target RTO | Measured RTO | Target RPO | Measured RPO | Depends on | Gap |
|---|---|---|---|---|---|---|---|---|
| Payment processing | Customer checkout | £38,000 | 1h | 2h 40m | 5 min | 1h | Identity provider, payment gateway | Yes (RTO and RPO) |
| Finance ERP | Invoicing, month-end close | £4,500 | 4h | 2h 41m | 1h | 1h | Identity provider, file share | No |
More free templates IT teams use alongside this one.
A BIA exists to decide the order you recover things in when you cannot recover everything at once. That makes the useful output a ranked list, not a document, and ranking requires scoring impact at several time horizons, because impact is rarely linear.
Most DR plans are written to satisfy an auditor and are unusable in an actual disaster: too long, structured by system rather than by sequence, and assuming the authors are available. This one is ordered the way the event unfolds.
A backup job reporting success proves a file was written. It does not prove the file can be read, is uncorrupted, or contains what you think. This log records the only thing that answers that question: an actual restore, timed and verified.
RTO is how long recovery may take, the outage duration you can tolerate. RPO is how much data you can afford to lose, measured backwards from the incident. RPO is driven by backup frequency; RTO is driven by restore speed and the recovery architecture.
Measure current capability from actual restore tests first, estimate the hourly cost of downtime for each system, then present the gap as a priced choice. Targets set without measured capability are aspirations that get discovered as fictional during the incident.
Because recovery is sequential. An application cannot be usable before the identity provider, network, and DNS it relies on are recovered. The effective RTO of any system is the sum of its dependency chain, which is usually longer than its stated individual target.
