Most businesses guess at their RTO (recovery time objective) instead of calculating it and usually guess wrong in the optimistic direction. Here’s a practical, calculation-based method for finding your actual number.
Most businesses have an RTO documented somewhere often chosen based on what sounded reasonable, rather than calculated from any real measurement. This article walks through a practical, calculation-based method for finding your actual recovery time objective, tested against reality rather than assumed.
Why guessed RTOs are usually wrong in one direction
When people estimate an RTO without testing it, the number tends to skew optimistic nobody wants to document “we’d be down for two days” as an acceptable target, so the documented number often reflects an aspiration rather than a tested reality.
A simple cost-of-downtime calculation method
Rather than guessing, work backward from actual business impact: how much would each additional hour of downtime cost you, in lost revenue, customer trust, or operational disruption? The point where that cost becomes seriously damaging, rather than merely inconvenient, is a much more defensible starting point for your RTO target than an arbitrary round number.
The full method, step by step
- Find your pain threshold:Â
Ask: if we were down for X hours, is that a minor inconvenience or a serious problem? Increase X until the answer flips from “fine” to “serious.” That’s roughly your RTO target.
- Test it against a real restore:Â
Don’t estimate actually time a restore of representative data. This is the step almost everyone skips, and it’s exactly where documented assumptions and reality tend to diverge.
- Compare the two numbers:Â
The gap between your tested restore time and your target tells you exactly where to invest either in faster restore capability, or in a revised, honest target.
- Segment where it matters:Â
Customer-facing systems usually warrant a tighter RTO than internal tools. A single company-wide number often over-invests in some areas and under-invests in others.
Don’t skip the actual restore test
This is the step that turns an RTO from a guess into a genuinely useful number. Without it, you’re documenting an aspiration, not a capability — and the gap between the two often only becomes visible during an actual incident, which is the worst possible time to discover it.
Setting Your Recovery Time Objective by Department, Not Just Company-Wide
A single company-wide RTO often doesn’t reflect reality well customer-facing systems typically warrant a tighter target than internal tools like an HR system or an internal wiki. Segmenting your RTO by system criticality usually produces a more useful and cost-effective plan than one blanket number.
What to Do with Your Real Recovery Time Objective
Now you have something actionable
Once you know your genuine, tested restore time, you can make an informed decision: accept it if it meets your business needs, invest in faster restore infrastructure if it doesn’t, or adjust your documented target to reflect reality rather than aspiration. Any of these is better than an untested number nobody has verified.
Frequently asked questions
Q: What’s a realistic RTO for a small business that’s never thought about this before?
There’s no universal number it depends entirely on how quickly being down actually hurts your specific business. Work through the pain-threshold exercise above rather than borrowing a generic industry benchmark that may not reflect your actual situation.
Q: Is it normal for our tested restore time to be worse than our documented RTO?
Very common, and better to discover it through a deliberate test than during an actual incident. This gap is exactly the useful information this exercise is designed to surface.
Q: How often should we re-test our RTO?
At minimum annually, and after any significant change to your data volume, infrastructure, or systems a restore time that was accurate a year ago may not reflect your current reality.
Q: Should every system in our company have the same RTO?
Not necessarily. Segmenting by how critical each system is customer-facing versus internal, for example usually produces a more useful and cost-effective plan than a single blanket number applied everywhere.
Conclusion
The most valuable outcome of calculating your recovery time objective is often simply discovering the gap between your documented assumption and your tested reality far better to find that gap now, deliberately, than during an actual incident when it matters most.