Most material on RTO and RPO stops at the definitions, and the definitions are not hard: one number says how long you can be down, the other says how much data you can lose. The problem lies elsewhere. In most organisations these two numbers get entered into a form, approved, and then left untouched until the next audit. They exist as a commitment on paper rather than a design constraint.
This article takes the opposite route: where the numbers should come from, who owns them, how they change the shape of a runbook, and how to tell the difference between a number you have published and a number you can actually hit.
Derive the numbers from business impact, not engineering instinct
The most common mistake is asking the infrastructure team how fast they could restore, then writing that down as the RTO. This inverts the causality. RTO is a business requirement, and infrastructure’s job is either to meet it or to say clearly that it cannot be met at the current level of investment.
Start from business processes, not servers
A server inventory tells you nothing about how much downtime the business can absorb. Start from the processes that generate revenue or create obligations to customers: order intake, payments, fulfilment, support, period close. For each one, ask the business owner something very specific: if this process stopped on an ordinary working day, how long before the consequences move from inconvenient to serious, and how long before they move from serious to unrecoverable.
The answer is almost never a single number, and that is useful. What you want is the shape of the damage curve over time. Some systems are flat for several hours and then rise steeply, usually because a manual workaround holds up to a certain threshold. Others rise from the first minute. Those two shapes lead to entirely different recovery designs, even when the RTO written on paper happens to be the same.
RPO is a question about rework
RPO is frequently mistaken for a technical parameter of the backup mechanism. It is really the question: if a window of data is lost, who re-enters it, where do they get it from, and how long does that take. If transactions can be reconstructed from paper records or from a partner’s system, a wider RPO is acceptable and considerably cheaper. If the data exists only in that system with no reconstruction source, every lost minute is lost permanently, and the number has to be much tighter.
A quick test: ask the business team whether any process exists for re-entering data after an incident. If the answer is no, then no matter how generous the RPO on paper, it does not reflect real tolerance.
Do not give every system the same pair
Assigning one RTO and RPO pair across the whole estate always produces one of two outcomes: either you spend money protecting systems that never needed that level, or you leave the most important system protected at an average level. Both are bad, and the second only reveals itself at exactly the moment you least want it to.
The workable approach is a handful of groups, each with its own pair and a description of the mechanism that delivers it. Keep the number of groups small enough that the operations team can recall them without looking anything up.
Writing the numbers into the recovery plan
A number without an owner is not a commitment. This is the part most recovery plans are missing, and also the cheapest part to add.
Who owns the number
Each RTO and RPO pair needs a business owner: someone with the authority to say this tolerance is correct and to accept the budget consequences that follow. If the owner is a technical role, the number will drift towards whatever the current infrastructure happens to achieve, and lose all force as a constraint.
Who is accountable for delivering it
Alongside the business owner, each system needs a named technical owner: someone who knows the dependency chain, knows the startup order, and can say immediately whether the current mechanism is sufficient. This list should carry names and named deputies, not department titles. In an incident, a department does not answer the phone.
Who declares, and who decides
This is where many recoveries overrun their RTO for reasons that are not technical at all. The plan must state who has authority to declare a disaster and activate the process, because the time that passes while people debate whether this counts as serious still counts against the RTO.
Several decision rights should also be assigned in advance, because they reliably come up under pressure: authority to accept some data loss in exchange for a faster return to service, authority to fail over rather than continue repairing the primary, authority to suspend service for one user group to concentrate capacity on another, and authority to spend outside plan. If these are not assigned beforehand, they will be argued about while the clock runs.
Write time-based escalation thresholds
Good plans attach specific actions to elapsed-time markers rather than to a single deadline. For example: at one third of RTO, notify business leadership; at two thirds, begin preparing the fallback option in parallel rather than waiting; at RTO, switch to the prepared option. This turns the number into a sequence of decisions instead of a finish line you only notice after crossing it.
Stated RTO versus tested RTO
Every organisation has two RTOs. The first lives in documents and in answers sent to customers. The second is the elapsed time your team actually needs, measured with a clock, during a real restore. The distance between them is your real exposure, and the only way to measure it is to drill.
The tested number is usually larger than the stated one, because paper estimates almost always omit the same group of factors: time to detect the incident, time to reach the right people outside working hours, time to make decisions, time to locate and decrypt credentials, time to recover dependencies before the main system’s turn comes, and time for the business to validate the data before reopening it to users.
An honest plan records both numbers side by side, with the date of the most recent measurement. Recording that a tested RTO currently exceeds the target is useful management information. Recording a target nobody has ever measured is not.
How the numbers shape the runbook
This is the real reason it is worth the effort to get RTO and RPO right: they determine what kind of runbook you have to write.
- An RTO in days permits a descriptive runbook: an ordered outline of steps, assuming whoever executes has time to look things up and think. Automation at this level usually does not pay for itself.
- An RTO in hours requires a procedural runbook: exact commands, exact paths, a verification criterion after each step, and no step that requires the operator to work something out.
- An RTO in minutes largely removes documentation from the critical path. At this level the process has to be automated and regularly exercised, and the runbook mostly covers how to confirm the automation ran correctly and what to do when it did not.
- An RPO in days suits scheduled backups. An RPO in minutes requires continuous capture plus a defined procedure for selecting the exact recovery point, which turns out to be a surprisingly time-consuming step during a real incident.
The numbers also set drill cadence. The system with the tightest RTO needs the most frequent drills, because that is where a stale procedure does the most damage. Systems with generous RTOs can be drilled less often, but not never. A practical rule: re-drill after any significant architectural change, after any personnel change in the accountable group, and on a fixed cycle committed to a calendar.
When the number cannot be met
At some point a drill will show that a system cannot meet its committed RTO at current cost. This is not a failure of the process; it is exactly the finding the process exists to produce. From there only three valid options remain: invest to close the gap, widen the number and record the accepted risk at a level with authority to accept it, or design a temporary business workaround that keeps the organisation functioning across the difference. The one invalid option is leaving the paper number unchanged and hoping.
How HiTechCloud can help
HiTechCloud is an AWS partner and a Google Premier Partner, and operates in-country infrastructure. We help organisations work with business stakeholders to set RTO and RPO per system group, compare those targets against current infrastructure capability, write runbooks at the level of detail the chosen numbers demand, and run recovery drills with measured elapsed times. If you want to know the distance between your stated and achievable numbers, our team can help you measure it.
