What recovery time objectives should your disaster recovery plan include?

An effective recovery time objective should be a measurable, system-specific limit that can be tested against the organisation’s actual recovery process. It should explain what must be restored, what “available” means, which conditions apply, and how the target will be verified rather than using a single broad objective for the whole business.

Define what the target applies to. Record the service, application, platform or operational capability covered by each objective. A customer relationship management system, file storage platform, authentication service and telephony system may support different activities and require different recovery approaches. Where a service contains several components, document whether the objective applies to the complete service or only to a particular function.

Describe the required level of service. Restoration does not always mean returning a system to full normal operation. The plan should state whether the objective means:

• the system is technically running;
• users can log in and access essential functions;
• critical data is available for authorised staff;
• customers or external partners can use the relevant service;
• the organisation can operate in a reduced or manual mode; or
• the service has been fully returned to its normal production configuration.

This distinction prevents a recovery target from being marked as achieved when a system is online but cannot support the business activity that depends on it.

Separate business priorities from technical convenience. The order in which systems are recovered should reflect the consequences of their unavailability. Consider contractual duties, safety implications, financial processing, customer commitments, regulatory obligations, production requirements and the effect on other departments. A technically important server is not automatically the first service that should be recovered if another platform is needed to continue a critical business process.

Include dependencies in every objective. A target for one application is only realistic if the services it relies on can also be made available within the required period. Dependencies may include:

• identity and access management;
• network connectivity and firewalls;
• virtualisation or hosting infrastructure;
• databases, storage and file shares;
• domain services and name resolution;
• security controls and endpoint access;
• third-party platforms and integrations; and
• specialist staff, suppliers or physical equipment.

Map these relationships before setting the final objectives. Otherwise, a short application target may depend on a longer infrastructure target and be impossible to meet in practice.

State when measurement begins. The plan should specify whether the elapsed period starts when an incident is reported, when the outage is confirmed, when a disaster declaration is made or when the recovery team begins its work. It should also clarify whether time spent assessing the incident, obtaining access, approving decisions and preparing replacement resources is included. Consistent measurement makes exercises meaningful and exposes unrealistic assumptions.

Set objectives for different operating scenarios. Recovery requirements can change depending on the cause and scale of the disruption. A plan may need separate expectations for accidental deletion, malware, hardware failure, loss of a site, cloud service unavailability, loss of connectivity and a widespread incident affecting several systems at once. If the same target applies to all scenarios, confirm that the recovery method and available resources support the most demanding case.

Account for degraded operation. Some organisations can continue limited work using manual procedures, read-only information, local records or an alternative channel. Others cannot operate safely without a particular service. Document what temporary arrangements are acceptable, which activities must stop, who can authorise them and how long they may be used. A degraded-service allowance should not hide an unresolved dependency or replace the target for full restoration.

Record the resources needed to meet the target. Each objective should be linked to a recovery procedure, the people responsible for carrying it out, the required permissions, relevant documentation, replacement equipment and the location of recovery copies. Include any supplier involvement and the decisions that must be made before restoration can proceed. A target without assigned ownership and practical resources is an assumption, not a dependable planning requirement.

Distinguish recovery from validation and handover. The process should allow time to check that systems are complete, secure and usable. Technical teams may need to verify data integrity, reconnect integrations, review security settings, test user access and confirm that business owners can perform essential tasks. The plan should state whether these checks form part of the objective or must be completed before the service is formally handed back.

Use achievable targets supported by evidence. Compare each proposed objective with results from restoration tests, supplier commitments, infrastructure capacity and the time required to rebuild or reconfigure services. A target should be revised if testing shows that the available backup, network, storage or staffing arrangements cannot support it. Testing should cover the dependencies and sequence described in the plan, not just the recovery of an isolated server or file.

Document exceptions and priorities clearly. Some systems may have no practical recovery route within the required period. In those cases, record the limitation, the business risk, the compensating procedure and the decision-maker who accepted it. Identify systems that can be retired, replaced, rebuilt from a clean baseline or operated through a supplier while recovery takes place. This gives management a clear view of residual risk rather than presenting every objective as equally achievable.

Review objectives after material change. Reassess them when the organisation introduces a new application, changes a supplier, moves workloads, adds a site, changes staffing, modifies business processes or experiences an incident. A formal review should also consider the results of recovery exercises, near misses and changes to legal or contractual responsibilities. Keeping objectives aligned with the current environment is as important as documenting them in the first place.

A useful RTO register therefore contains the service covered, required operating state, business justification, dependencies, recovery owner, scenario assumptions, measurement point, supporting procedure, test evidence and any accepted limitations. This level of detail allows the organisation to compare its objectives with its actual disaster recovery capability and identify where investment or process changes are needed.