Disaster Recovery: RTO and RPO as Business Decisions, Not Technical Ones

Ask an IT team for their disaster recovery objectives and you’ll get two numbers. Ask the board whether it approved those numbers, knowing what they actually mean for the business if invoked, and the honest answer is almost always no — because RTO and RPO were set as technical parameters, in a technical conversation, and never actually translated into what they cost the business when the day comes.

Recovery Time Objective and Recovery Point Objective sound like engineering settings, and they get treated that way — configured, documented, occasionally tested, rarely revisited by anyone outside the technology function. They are not engineering settings. They are two of the most consequential business decisions a board makes without realising it’s making them.

What the two numbers actually mean, translated

RTO — how long can the business function be down. An RTO of four hours for a customer-facing platform is a statement that the business can absorb four hours of complete unavailability without it becoming existential — lost revenue, reputational damage, contractual penalties, regulatory exposure, all bounded and survivable within that window. Whether four hours is actually survivable is not a technology question. It’s a question about revenue concentration, contractual SLAs with your own customers, and regulatory expectations — DORA and NIS2 both increasingly test exactly this — and none of that lives in the technology function’s domain of judgment alone.

RPO — how much data can you afford to lose. An RPO of one hour means that in the worst case, the last hour of transactions, records, or customer interactions before a failure simply doesn’t exist afterward. For a company with modest transaction volume, an hour might be a genuine non-event. For a trading platform, a payments processor, or anything recording safety-critical operational data, an hour of silent loss can be catastrophic in ways a technology team, however competent, is not positioned to weigh against the business’s actual risk appetite — because that weighing is a business judgment, not a technical one.

Why the numbers drift from reality

The recurring failure I see is not that RTO and RPO are wrong. It’s that they were set once, early, by a technical team estimating conservatively against the infrastructure available at the time, and never revisited as the business changed around them. A company that had modest revenue concentration when its four-hour RTO was set may now run a platform where four hours of downtime is genuinely business-threatening — and nobody has gone back to ask whether the number that was fine three product launches ago is still fine now.

The second recurring failure is worse: the numbers were set and never actually tested against reality. A documented four-hour RTO that has never been rehearsed is a hope, not a capability, and the gap between the two is invisible until the day it’s tested for real — which is precisely the wrong day to discover it. Supervisors across DORA, NIS2 and comparable regimes have started asking specifically whether the recovery plan has been tested recently and against what scenario, because a written objective with no rehearsal behind it is, in a very real sense, indistinguishable from no objective at all.

Making it a genuine board decision

The fix is not a technical one. It’s putting the translated version of both numbers — what four hours of downtime actually costs, in revenue and obligation, and what an hour of lost data actually means for the specific records at risk — in front of the board as an explicit risk-appetite decision, the same way the board would decide any other risk it’s choosing to accept. If the board, informed, decides four hours and one hour are acceptable, that’s a legitimate decision made by the people with the authority to make it. If nobody with that authority has ever actually seen the translated version, the current numbers are a technical estimate wearing the authority of a decision nobody actually made.

What the translation actually reveals

A payments-adjacent fintech had a documented eight-hour RTO for its transaction-processing platform, set three years earlier when transaction volume was a fraction of current levels and set by the engineering team based on what the infrastructure of the time could realistically achieve — a reasonable technical estimate at the time it was made. Translated into business terms for the board — eight hours of inability to process payments, against current transaction volume, current contractual SLAs with merchant customers that specify maximum outage windows, and current DORA incident-reporting exposure — the number was not something any board member would have knowingly approved once they saw it stated plainly. Nobody had ever asked the board to approve it in the first place; it had simply persisted as a technical parameter nobody outside engineering had reason to revisit. The number didn’t need better engineering. It needed to be put in front of the people with the authority to decide whether it was still acceptable, which it wasn’t, once they actually saw it.

An RTO or RPO target is meaningless without the discipline covered in backups aren’t backups until you’ve restored one.

Translating RTO and RPO into numbers a board can actually weigh — and testing whether the current numbers are real capability or hopeful documentation — is core technology control assessment work, and it tends to be one of the more uncomfortable findings when it hasn’t been done before.