What recovery point objectives should your disaster recovery plan define?

A useful RPO schedule should define an acceptable data-loss limit for every important workload, identify the protection method that supports that limit, and state who approves any exception. It should not assign one broad RPO to the whole organisation, because different systems create data at different rates and have different business consequences.

Start by grouping systems according to how much recent data the business needs to preserve. A practical plan may include the following categories:

• Mission-critical systems: platforms supporting active transactions, production, customer delivery, financial processing or essential communication. These may require continuous replication or very frequent protection, subject to the technology and network architecture available.
• Important operational systems: applications that can tolerate the loss of some recent changes but would disrupt normal work if unavailable for too long. Scheduled backups may be appropriate where replication is unnecessary or disproportionate.
• Reference and archival data: information that changes infrequently or can be recreated from an authoritative source. This still needs protection, but its RPO may be less demanding than that of live transactional data.

These categories are starting points rather than fixed standards. The correct limit comes from understanding what data would be lost, which processes depend on it, and what consequences would follow.

Define the RPO from the business process backwards. Ask when information becomes difficult or impossible to recreate, rather than choosing a backup frequency first. For example, losing a completed transaction, a customer record, a production change or a newly issued document may have a different impact from losing temporary working files. Speak with the owners of finance, operations, sales, production and other relevant functions to identify which changes must be retained.

Consider the full cost of data loss, including duplicated work, inaccurate records, delayed fulfilment, contractual problems, regulatory obligations and decisions made using incomplete information. The RPO should reflect the point at which the business would no longer regard the available data as an acceptable basis for continuing operations.

Record a separate RPO for each workload and data set. A single RPO for a server or application can be misleading where different data has different value. A database containing live orders may need more frequent protection than application logs, test data or static documents on the same infrastructure. Where several systems work together, record their relationship and establish whether they need a common recovery point to avoid inconsistent records.

The plan should identify:

• the system, service, database or data set covered;
• the business owner responsible for approving its RPO;
• the maximum acceptable age of recovered data;
• the backup, replication or snapshot process intended to meet the limit;
• the location and retention arrangements for the protected copies;
• the dependencies needed to recover usable information; and
• any assumptions, exclusions or accepted exceptions.

Check that the protection method can actually achieve the stated RPO. A target is not met simply because a backup job is configured to run at a particular interval. The plan must account for whether jobs complete successfully, whether data is still being written when protection occurs, and whether the copy can be accessed after an incident. Network capacity, storage performance, application consistency and replication lag can all create a gap between the intended and achieved recovery point.

For databases and other transactional applications, application-aware protection may be necessary to avoid restoring corrupted or incomplete information. For file data, the organisation may need version history as well as periodic backups. Replication can provide a more recent copy, but it may also replicate accidental deletion, corruption or malicious changes. A resilient plan therefore normally uses more than one protection approach, with recovery copies that are sufficiently independent to remain useful during a serious incident.

Do not confuse an RPO with an RTO. The RPO governs how much recent information may be lost. The recovery time objective governs how long it may take to restore the service or system. A business may require a recent recovery point but have more time to bring the system back into use, or it may accept older data while requiring the service to be restored quickly. Both objectives should be recorded together so that the selected recovery design is technically and financially realistic.

Test the achieved recovery point rather than relying on configuration. A test should establish the latest usable data available after recovery, not merely confirm that a backup task reported success. Select representative systems and verify that:

• the intended recovery copy can be located and accessed;
• the restored data opens correctly and is complete;
• transactions or files created before the incident are present up to the agreed point;
• connected applications and authentication services work as expected;
• the recovery process does not depend on the failed environment; and
• the measured result is recorded against the documented RPO.

Where the test reveals a larger data gap than the plan permits, the organisation should either improve the protection process or formally revise the RPO with the business owner. Quietly accepting the gap leaves the plan inaccurate.

Include systems outside the main data centre or office. Cloud applications, hosted platforms, remote endpoints, collaboration tools, operational technology and data held by third parties may each have different backup and recovery controls. Availability of a service does not automatically mean that historical data can be restored to the required point. Confirm what protection the provider supplies, what the customer is responsible for, how versions are retained and how data can be exported or recovered if the service is unavailable.

RPOs should also cover data created away from the main environment. Laptops, branch locations and mobile working arrangements can contain the only recent copy of a document or record. If those devices are excluded, the plan should state the exclusion and explain how the risk is managed.

Balance the target against complexity and cost without weakening essential controls. A more demanding RPO generally requires more frequent processing, greater storage, suitable network capacity, compatible application design and more involved monitoring. The decision should be based on the impact of data loss, not on an arbitrary preference for the most frequent possible protection. Where a demanding RPO cannot be justified or supported, document the business decision, the remaining exposure and any compensating process.

RPOs should be reviewed after significant changes to applications, transaction volumes, suppliers, office arrangements, legal obligations or business processes. They should also be reconsidered after an incident or recovery test identifies a previously unrecognised data dependency. A current plan links each RPO to an owner, a tested technical control and evidence that the control is producing the recovery point the business has approved.