Setting RTO and RPO targets for each agency system

Reference article · 6 min read

Disaster recovery spending is usually decided one system at a time, under pressure, after an outage or during a contract renewal. The result is a set of arrangements nobody can defend in front of a budget committee: a permitting system replicated across two data centers because the vendor included it, and a jail management system on a nightly job because that is how it was configured years ago. The fix is rarely a larger budget. It is a short, written set of recovery targets that the people who own each system have agreed to, produced before anyone asks for a quote.

Two numbers carry most of the weight. A recovery time objective (RTO) is how long a system can be unavailable before the consequences become unacceptable. A recovery point objective (RPO) is how much recent data the agency can afford to lose and re-create by hand. They are independent of each other. A cashiering system might tolerate a half-day outage but almost no lost transactions, while a GIS basemap could lose a week of edits and still need to be back within an hour.

Define the two numbers precisely before you assign them

Loose definitions cause arguments during the recovery, which is the worst time to have them. Settle these points first and write them at the top of the tier list.

• RTO starts at declaration, not at the first symptom. Decide who can declare an incident and how quickly that happens, then treat detection and decision time as its own budget.
• "Restored" means staff can work. A database that is up but has no interfaces, no printing, and no connection to the identity provider has not met the objective. Define restoration as the point where the department can process real work.
• RPO is a data-loss budget, not a backup schedule. A four-hour RPO means the agency accepts re-creating up to four hours of work, and someone has to be able to describe how that re-creation would happen.
• Targets are planning commitments, not capabilities. The current environment may not meet them. That gap is the point of the exercise.

Run a lightweight impact analysis by asking what stops

A full business impact analysis can take months. A usable version takes about an hour per department if you ask concrete questions and write the answers down.

• What work stops the moment this system is unavailable, and who notices first?
• What is the manual fallback, and how long can it realistically hold? Paper dispatch cards and hand-written receipts work for a shift, not for a week.
• Who is harmed, and how quickly? Residents waiting on a benefit determination, an officer without records access, and a contractor waiting on an inspection are different clocks.
• If data is lost, who re-enters it, from what source, and how long does that take?
• Is there an external deadline attached? Payroll runs, court filing windows, tax and utility billing cycles, and state or federal reporting obligations create hard dates. Confirm the specifics with counsel or the relevant oversight agency, because those requirements change.

Build a small tier list rather than negotiating system by system

Four tiers are usually enough, and a short list is easier to defend than sixty individual numbers.

• Tier 0, minutes. Dispatch and CAD, 911 call handling, jail booking and release, and operational control systems where an outage creates immediate safety exposure.
• Tier 1, a few hours. Records systems, permitting and inspections, case management, and public-facing payment intake during business hours.
• Tier 2, by the next business day or the next processing run. Payroll, accounts payable, asset management, and most back-office finance and HR functions.
• Tier 3, several days. Recreation catalogues and registration outside peak enrollment, intranet content, and historical reporting or analytics environments.

Two adjustments matter. Tier by the worst window rather than the average: payroll is idle most of the month and unforgiving in a specific two-day window. And tier the dependencies, not just the applications. Identity, DNS, network transport, the integration bus, and print services must meet the most demanding target of anything that relies on them.

Get department heads to own the numbers

IT cannot set these targets alone, and a target set by IT will not survive the first budget cycle. Ask the question in the department's own terms: how long can your staff work without this before you have to stop taking cases, close the counter, or call in overtime? Then show what each tier costs, in rough relative terms, so the answer is a tradeoff rather than a wish. Capture the agreed RTO, RPO, the name of the person who approved it, and the date. Revisit annually and whenever a system changes ownership, adds a major function, or moves to a new hosting model.

Let the targets drive backup and replication design

Once tiers exist, most design decisions follow from them. Short RPO systems need continuous or near-continuous data movement, log shipping, or synchronous replication, and the cost rises sharply as the number approaches zero. Longer RPO systems can live on scheduled snapshots. Short RTO systems need warm or active standby capacity, tested failover, and runbooks that non-experts can follow at 3 a.m.

Ransomware changes the arithmetic. Replication copies corruption faithfully, so a low RPO does not protect you if every copy is encrypted. Pair replication with backups that are immutable or otherwise isolated, held under separate credentials, and retained long enough to reach a recovery point that predates the intrusion. Test restores on a schedule and record how long they actually took, because measured restore time is the only honest input to an RTO.

Put the targets into solicitations and contracts

For hosted and SaaS systems, the vendor controls whether your targets are achievable. Ask before award:

• What RTO and RPO does the service commit to contractually, and how are they measured?
• What is the remedy when they are missed, and does it escalate for repeated failures?
• Where are backups stored, are they isolated from production credentials, and how long are they retained?
• Who declares a disaster, and when are customers notified?
• When was the last full recovery test, and will the agency receive the results?
• Can the agency export its full dataset in a usable format on a routine schedule and at contract exit?

In the contract, state the targets as obligations rather than as marketing statements, require periodic test evidence, and include data export and transition assistance. Service credits rarely cover the cost of an outage, so treat them as an escalation trigger rather than as compensation. Have counsel and procurement review the terms before issuing the solicitation.

To start, list every system with an owner, hold the one-hour sessions, draft the tier list, collect signatures, then compare current capability against the targets. The gap list that falls out is the justification for your next DR purchase.

HQT works with state and local agencies on cloud and infrastructure planning, including continuity and recovery architecture for government systems.

Frequently asked questions