Search every question across sub-FAQs

Review strategies at planned intervals and after significant changes to the organization, context, prioritized activities, resource requirements, suppliers, sites, systems, legal obligations, customer commitments, or disruption risks. ISO 22301 also expects exercising and testing over time to validate business continuity strategies and solutions.

If a test shows the selected solution cannot meet the required time frame or capacity, the issue should not stay buried in the exercise report. Update the strategy, plan, resource decision, corrective action, and management-review inputs so the BCMS reflects the real recovery capability.

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.

RTO means recovery time objective: the target timeframe for resuming a disrupted activity at a specified minimum acceptable capacity. ISO 22301 places it inside the business impact analysis, after the organization has assessed impacts over time and identified the maximum tolerable period of disruption.

The RTO should normally sit inside the MTPD, not equal it by default. MTPD is the point where the impact of not resuming becomes unacceptable; the RTO is the operational target that gives the organization time to recover before that outer limit is reached.

Start from impact, not from available technology. The BIA should define impact types and criteria, identify activities that support products and services, assess the impacts over time, and identify when not resuming the activity becomes unacceptable.

After that, set prioritized timeframes for resuming disrupted activities at minimum acceptable capacity. That is where the RTO belongs. The record should also identify the resources, partners, suppliers, and interdependencies required to meet the target.

RTO is about time to restore service or activity capability. RPO is about how much information loss is tolerable. A service can have a short RTO and a longer RPO, or the opposite, depending on the business impact and data requirements.

For example, a customer portal might need to be usable within a few hours, while some reporting data can be restored to the last completed batch. A payment, safety, clinical, or operational-control process might need both a short RTO and a strict RPO. The BIA should make that distinction explicit.

A target is not enough. Evidence should show that the strategy, plan, resource model, supplier dependency, and exercise results can actually support recovery within the RTO and agreed capacity.

Useful evidence includes the BIA record, approved recovery strategy, continuity plan, dependency map, resource requirements, supplier commitments, exercise scenario, post-exercise report, corrective actions, and management review decisions.

Review RTOs at planned intervals and whenever the organization, service, supplier, technology, legal context, customer commitment, or disruption experience changes. ISO 22301 ties BIA and risk assessment review to planned intervals and significant changes.

The most common failure is leaving the RTO unchanged after the business changes. A new customer promise, cloud architecture, supplier dependency, product launch, staffing model, or exercise failure can all make the previous target unrealistic or too weak.

The programme should be planned against the BCMS scope and business continuity objectives, not as a loose calendar of tabletop meetings. Each exercise or test should name the activity, site, product, service, dependency, plan, team, and scenario being validated.

A useful programme mixes exercise types over time. Tabletop exercises can test decision paths and escalation. Communication tests can validate warning and contact procedures. Technical or operational tests can check recovery steps, resource availability, alternate work arrangements, supplier handoffs, and restoration procedures.

Exercises should test whether the BIA and risk assessment still describe reality. If the BIA says an activity has a maximum tolerable period of disruption, an RTO, an RPO, critical suppliers, required people, minimum resources, or a recovery sequence, the exercise should check whether those assumptions survive contact with the scenario.

Do not record a pass just because the meeting happened. The report should say which continuity objective, recovery target, communication path, plan step, workaround, or resource dependency was validated, partially validated, or failed.

The post-exercise record should be formal enough that an internal auditor, certifier, customer, or management reviewer can see what was tested and what changed because of the result. The record should not be a slide saying the exercise was completed.

Keep the evidence close to the BCMS record set: exercise plan, scenario, objectives, participants, roles, scripts or injects, observations, decisions, timings, issues, recommendations, action owners, due dates, closure evidence, and links to updated plans or BIA records.

Exercise results should trigger action when they show that a strategy, solution, plan, role, supplier dependency, communication procedure, or recovery assumption is not suitable, adequate, or effective. A finding is not closed when it is assigned; it is closed when the correction is implemented and its effectiveness is checked.

Management review should see the patterns that matter: repeated exercise failures, overdue corrective actions, changes in BIA or risk assumptions, capability gaps, supplier issues, near-miss lessons, and decisions that require budget, scope changes, resource changes, or revised continuity objectives.