ISO 22301 FAQ RPO

RPO means the maximum age of data the organization is willing to recover from after a disruption. A four-hour RPO means the organization has accepted that up to four hours of records, transactions, messages, telemetry, or other recoverable data may need to be restored, replayed, reconciled, or manually rebuilt.

ISO 22301 grounds recovery targets in the business impact analysis rather than in technology preferences. The BIA identifies activities that support products and services, assesses impacts over time, identifies unacceptable disruption time frames, sets prioritized time frames for resuming activities, and determines resources, dependencies, partners, suppliers, and interdependencies. RPO should be recorded alongside those outputs so the data-loss target fits the actual activity and its dependencies.

RPO is about data loss or rework. RTO is about how quickly a disrupted activity should resume at a specified minimum acceptable capacity. MTPD is the wider time frame after which the impact of not resuming the activity becomes unacceptable to the organization.

The three targets should be internally consistent. If a service has a two-hour RTO but a twenty-four-hour RPO, the business is saying it can resume quickly while accepting much older data. That may be valid for a static reference system, but it is usually wrong for order processing, financial records, safety logs, customer communications, or regulatory evidence.

A useful RPO record shows the target, the business reason, the dependency chain, and the proof that the target can be met. The evidence should connect the BIA row to the continuity strategy, backup or replication design, runbook step, supplier commitment, exercise result, exception, and review date.

For each material service or activity, keep the current RPO, the data source covered, the recovery method, backup or replication frequency, last successful restore or replay test, expected manual reconciliation, owner, approver, exception status, and link to the related RTO and MTPD. The record should be clear enough that an incident team can use it and an auditor can trace it.

RPO should be validated through exercises, restore tests, failover tests, post-incident reviews, supplier capability reviews, and performance evaluation. The test should answer whether the organization can recover data to the agreed point and operate the prioritized activity at the required minimum capacity.

Review RPO when there is a significant change in products, services, systems, data volumes, integrations, suppliers, legal or customer commitments, backup architecture, cloud region design, operational capacity, incidents, near misses, audit findings, or management-review decisions. A stale RPO can be worse than no target because teams may design around a number the business no longer accepts.