What to remember.
- RTO and RPO are defined per business service, not as one value for everything.
- A shorter target normally requires more investment and operating discipline.
- An untested target remains an assumption.
The management answer
RTO is the maximum acceptable time to restore a service. RPO is the oldest acceptable data point to which the organisation can return, or the amount of new data it can lose.
If RTO is four hours, the service should be available within that period. If RPO is one hour, protection must allow restoration to a point no older than one hour. These values are not chosen by the backup administrator alone.
Start with business impact
For each service, ask what happens after one, four, eight and twenty-four hours of disruption. Consider revenue, contracts, customers, production, safety, reputation and manual work needed to recreate data.
Do not give every system the same target. Email, payroll, a production application and an archive may need different recovery objectives. Priority follows impact, not server size.
Dependencies change the sequence
An application with a two-hour RTO may depend on identity, network, database and storage. If any dependency has a weaker target or no plan, the application target is not achievable.
Create a service map and define the recovery sequence. Include external providers and confirm whether their commitments support your objectives.
The cost of a shorter target
A shorter RTO can require redundant infrastructure, automated failover, a prepared environment, extra capacity and on-call coverage. A shorter RPO can require frequent replication or transaction protection.
Present management with several levels, showing cost and residual risk. A target of minutes is not better if the business can tolerate hours and investment is more valuable elsewhere.
Verifying objectives
- Measure from incident declaration to business confirmation
- Record decision, access, restore and validation time
- Check the age and consistency of restored data
- Include manual steps and provider waiting time
- Compare actual results with targets and open corrective actions
The CoreTech approach
We connect RTO and RPO with a business-service map. We do not promise time based only on tool capability. We validate the target through dependencies, the operating model and a test in which the business owner checks the result.
Common questions
Does RTO include user verification?
It should cover the time to a genuinely usable service, including technical and business validation.
Can the whole company have one RTO?
That is usually too broad. Objectives are set per service or process, then aligned through their dependencies.
Who approves RTO and RPO?
The business owner accepts impact and cost, while IT confirms technical feasibility and the testing method.