How should organisations set recovery time objectives and recovery point objectives for critical applications?

How to set RTO and RPO without guessing

RTO and RPO should be set from business impact, not from infrastructure convenience. For each critical application, define how long the business can operate without it, what data loss is tolerable, and which dependent services would extend recovery time. That gives you a practical target that operations, application owners, and recovery teams can actually test against.

For a useful starting point, Business Continuity and Disaster Recovery Guide explains how RTO, RPO and business impact analysis fit together across recovery planning.

These objectives should also reflect the difference between outage tolerance and data-loss tolerance. A system may be unavailable for only a short period before the business is materially harmed, yet still tolerate a larger data gap if the work can be re-entered or reconciled. In other cases, such as transaction systems, the opposite is true and a short outage can be accepted only if near-zero data loss is achievable.

Business Impact Analysis Template is useful when you need to translate process criticality, dependencies and time-based impacts into explicit recovery targets.

What should drive the numbers for critical applications?

Set the numbers by combining business process criticality, dependency mapping, and realistic recovery capacity. The most important question is not whether an application is important in the abstract, but what breaks first if it is unavailable, which users or transactions are blocked, and whether upstream or downstream systems can continue in degraded mode. That is why recovery objectives should be anchored in measurable service impact, not just system tier labels.

Where the application supports a regulated or high-availability environment, treat the recovery target as a business commitment that must be feasible with your current architecture, backup regime, and support model. If the target is shorter than your actual restore path, failover design, staffing model, or verification process, the objective is unrealistic and will fail under stress.

For a practical planning artefact, Disaster Recovery Plan Template provides a recovery register, dependency map and restore order that help convert target setting into an executable plan.

Why RTO and RPO must be reviewed over time

RTO and RPO are not one-time assignments. Business expectations change, applications gain new dependencies, data volumes grow, and recovery methods age. A target that made sense for a standalone system can become wrong once the application depends on an identity provider, a shared database, a SaaS integration or a third-party platform that lengthens recovery.

The safest operating model is to review targets whenever the service changes materially, then test whether the recovery design still meets them. If the test shows you cannot restore within the promised window, the objective should be revised or the recovery design upgraded. If you cannot measure the actual restore point and restore duration, the objective is only a statement of intent.

Restore Testing and Recovery Assurance Guide helps teams validate that backup and restore assumptions are real, not theoretical.

Risk and Threat Considerations

Recovery objectives create a control boundary: if they are set too loosely, outages last too long; if they are set too tightly, organisations promise resilience they cannot deliver. The practical risk is not just downtime, but the gap between the recovery target and the actual ability to restore systems, data and dependencies under pressure.

Failure mechanism: Weak or outdated RTO and RPO setting usually fails because the business impact analysis is stale, dependencies were missed, or restore testing did not prove the target is achievable. When a critical dependency such as authentication, backup storage, or a shared platform is slower to recover than expected, the real outage exceeds the approved objective.

Impact: The result is prolonged service interruption, larger data reconstruction effort, missed contractual or regulatory commitments, and avoidable business loss. In the worst case, recovery teams discover the target was never realistic only after an incident has already consumed the recovery window.

Practitioner Guidance

What to prioritise: Set RTO first from business process tolerance, then set RPO from the maximum acceptable data loss for that same process. Do not let backup frequency or infrastructure capability dictate the business target unless the business has explicitly accepted that limitation.

What to verify: Confirm that each critical application has an owner, a dependency map, and a restore path that can meet the stated target in a test, not just on paper. The most common mistake is to document a recovery objective without proving that the necessary data, credentials, and supporting services can be restored in time.

Practitioner takeaway: Good recovery objectives are measurable promises tied to testable recovery paths, and they only stay credible when business impact, dependencies and restore performance are reviewed together.

Related resources from NHI Mgmt Group

• Who should be accountable for deciding recovery objectives across critical applications?
• When should organisations prioritise recovery planning over buying more point-in-time fixes?
• Why do point-in-time security checks fail for mobile applications?
• What breaks when security testing is only done at a single point in time for SaaS applications?