Search every question across sub-FAQs

Connect the MTPD to the BIA rather than leaving an unexplained number in a spreadsheet. A reviewer should be able to trace the activity to the product or service it supports, impact criteria, impacts over time, RTO, required resources, dependencies, continuity strategy, exercise results, and open actions. Include RPO only where the organization uses it as a supporting data-recovery target.

Good evidence also shows ownership. The business owner should approve the impact tolerance, continuity or resilience teams should challenge consistency across activities, and management review should see unresolved gaps where recovery capability cannot meet the agreed time frames.

Review MTPD at planned intervals and whenever the facts behind the BIA change. Typical triggers include a new or changed product, site, process, system, supplier, customer promise, legal or contractual duty, incident lesson, failed exercise, resource constraint, or management decision that changes impact tolerance.

The update should not stop at the MTPD field. If the tolerance changes, check whether RTOs, RPOs, continuity strategies, resource requirements, procedures, supplier agreements, exercises, and management-review actions still make sense.

A business continuity strategy is the selected approach for protecting, continuing, or recovering prioritized activities. Each strategy must comprise one or more solutions that can be activated when needed, such as an alternate site, manual workaround, supplier substitution, technology failover, staffing arrangement, inventory buffer, or communication path.

The strategy should also address the disruption risks identified for the activity and its required resources. A page that only says "restore service quickly" is not enough; the record should show which product, service, activity, dependency, resource, and owner the strategy protects.

Start with BIA outputs: products and services in scope, impacts over time, the unacceptable-impact timeframe, prioritized resumption timeframes, minimum acceptable capacity, prioritized activities, resources, and dependencies. Add RPO only where the organization has chosen a supporting data-loss target; ISO 22301:2019 does not define or explicitly require it. Then compare feasible strategies against disruption risks for the activities and resources.

Selection must consider whether the strategy meets the identified timeframes and agreed capacity, the amount and type of risk the organization may or may not take, and associated costs and benefits. For example, a warm standby environment only supports the BCMS if it covers the required application, data, people, supplier links, access rights, communications, capacity, and activation conditions.

Evidence should show that the strategy can be activated, not merely that it was named in a document. Keep the selected strategy, resource requirements, implemented solution, continuity plan or procedure, exercise/test result, post-exercise actions, and any management-review decision together or cross-linked.

Good evidence covers the resource categories ISO 22301 identifies: people; information and data; physical infrastructure and utilities; equipment and consumables; ICT systems; transportation and logistics; finance; and partners and suppliers. Name owners and verify that each resource will be available when the solution is activated.

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 expresses the point in time to which information should be recovered after a disruption, commonly translated into a maximum data-age or data-loss window. A four-hour RPO means the recovery design must reach a point no more than four hours before the disruption; records created after that point may need replay, reconciliation, or manual reconstruction.

ISO 22301 grounds continuity priorities 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 and dependencies. If the organization uses RPO, record it alongside those outputs so the separate data-loss target fits the actual activity and its dependencies.

RPO is about the recovery point for information and the resulting data loss or rework. RTO is the prioritized timeframe for resuming a disrupted activity at a specified minimum acceptable capacity. MTPD is the optional ISO 22301 name for the wider timeframe within which the impacts of not resuming the activity would become unacceptable.

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, business reason, covered data, dependency chain, and proof that the target can be met. Backup frequency alone is not proof: retention, replication lag, corruption detection, access, encryption keys, restore order, transaction consistency, and reconciliation can all change the point actually recovered.

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 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 change. Reconcile the changed target with the BIA, RTO, continuity solution, supplier commitments, and exercise programme.

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 must be set within the unacceptable-impact timeframe, which the standard notes may be called MTPD. Setting both to the same value leaves no planned margin for activation, failed steps, verification, or dependency delays, so any equal values need a defensible impact and capability rationale.

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 the time to resume an activity at minimum acceptable capacity. RPO is a separate supporting target for the point to which information should be recovered and the resulting data loss or rework. ISO 22301:2019 does not define or explicitly require RPO, although organizations often use it where information recovery affects continuity.

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.

Evidence should show that the selected strategy and solution, plan, resources, dependencies, and exercise results can support resumption within the RTO at the agreed capacity. Measure from the defined disruption or activation trigger and state when the minimum acceptable capacity was reached; otherwise actual recovery times cannot be compared consistently.

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.