Should recovery time and recovery point objectives be set at process level or application level?
RTO belongs to the business process: it states how long the business can be without the process running, which is a business judgement. RPO belongs to the application: it states how much data loss is acceptable for a specific system, which is a technical judgement about that system's backup and replication design. Recording RPO at process level instead produces backups configured at the wrong frequency on the wrong systems, and the error usually surfaces only during a real outage.
Published
Maximilian Bazzi, Founder and CEOWhy the two objectives belong at different levels
Recovery time objective and recovery point objective answer different questions and are set by different people, which is why placing them at the same level of the organisation produces a mismatch. RTO states how long the business can be without a process running before harm becomes unacceptable, which is a business judgement made by the process owner and the people accountable for the harm of it being unavailable. RPO states how much data loss, measured in time, is acceptable for a specific application, which is a technical judgement about that application's backup frequency, replication design and storage architecture, made by whoever owns that system.
Why setting RPO at process level fails in practice
A business process is rarely supported by a single application. A claims process, for example, might touch a policy administration system, a document repository and a payments interface, each with a different data change rate and a different backup or replication capability. Setting one RPO figure for the process as a whole and applying it uniformly across all three systems either overstates what the least capable system can actually deliver, creating a false assurance that recovery will meet a figure it cannot, or understates what the most capable system already achieves, wasting investment tightening a backup regime that did not need it.
Where this goes wrong in practice
Backup and replication schedules get configured against the recorded figure, whichever level it was set at. When RPO has been recorded at process level, the systems underneath it inherit a target that was never actually assessed against their own data characteristics. The mismatch does not surface in normal operation, because backups run on schedule regardless of whether the schedule was set correctly. It surfaces during an actual recovery, when the data genuinely available does not match what the recovery plan assumed, at exactly the point where discovering the gap is most expensive.
What correct placement looks like
RTO stays at process level, set by the business against the harm of the process being unavailable. RPO moves down to each application that supports the process, set against that application's actual data volatility and technical recovery capability. Where an application cannot meet the RPO the process needs, that gap is a specific, named finding against a specific system, rather than an undifferentiated concern about the process as a whole.
How Bazzi Consulting helps
We set recovery objectives at the level each one actually belongs to, surfacing application-specific RPO gaps against the process-level RTO they need to support, rather than recording a single figure that fits neither. See risk and resilience advisory.