FAQGlobalISO 22301

ISO 22301 FAQ RTO

How should teams set recovery time objectives under ISO 22301?

Use the to set realistic recovery targets for prioritized activities, then prove them with resources, dependencies, exercises, and review records.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Overview

Under ISO 22301:2019, the BIA sets prioritized timeframes for resuming disrupted activities at a specified minimum acceptable capacity. The standard notes that this timeframe may be called the (RTO). The requirements can apply to any type or size of organization, or part of one, with implementation shaped by its operating environment and complexity. ISO 22301 is a voluntary standard rather than legislation; its "shall" clauses are requirements for conformity, while this page's implementation examples are guidance. ISO lists the 2019 second edition as published with Amendment 1:2024 and an edition 3 committee draft under development; the draft has not replaced the published requirements. Set RTO within the timeframe in which the impacts of not resuming would become unacceptable, using business impacts rather than an unsupported IT estimate or contract value.

Search this module

Find a question or answer quickly

6 of 6 questions
Question 1

What does RTO mean in ISO 22301?

RTO means : the target timeframe for resuming a disrupted activity at a specified minimum acceptable capacity. ISO 22301 places it inside the , 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 . 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.

  • Define the product or service that depends on the activity.
  • Identify the prioritized activity and the minimum acceptable capacity after disruption.
  • Set the RTO within the and document the assumptions behind it.
  • Assign an accountable owner who can fund and maintain the recovery capability.
Question 2

How should the BIA produce the RTO?

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.

  • Keep one RTO per prioritized activity or service dependency, not one generic RTO for the whole company.
  • Record the impact criteria used to justify the target, such as customer harm, financial loss, safety, regulatory commitments, or contractual commitments.
  • Link the RTO to required people, sites, applications, data, suppliers, workarounds, communications, and approval authority.
  • Capture any gap between the desired RTO and the current tested capability as a risk, exception, or corrective action.
Question 3

How is RTO different from RPO?

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.

  • Use RTO to size recovery sites, failover design, staffing, supplier response, and manual workarounds.
  • Use RPO to size backup frequency, replication, transaction logging, reconciliation, and data recovery testing.
  • Do not treat backup success as proof of RTO; backup evidence usually proves only part of the recovery capability.
  • When current capability cannot meet the BIA-derived RTO, record the gap and change the solution, resources, supplier arrangement, or justified continuity requirement. Risk acceptance alone does not show that the ISO 22301 strategy-selection requirement has been met.
Question 4

What evidence shows the RTO is achievable?

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.

  • Test the end-to-end recovery path, including activation, people, access, data restoration, supplier response, communications, and stand-down.
  • Record actual recovery times from exercises and incidents instead of only recording that a test occurred.
  • Tie missed RTOs to corrective actions with owners and due dates.
  • Use management review to decide whether the RTO, strategy, budget, supplier contract, or plan needs to change.
Recommended next step

Assign recovery owners and verify elapsed times

This ISO 22301 RTO FAQ helps assign owners, connect BIA records to recovery strategies, test real recovery paths, and keep missed targets visible as corrective actions.

Question 5

When should an RTO be reviewed or changed?

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.

A failure to review can leave 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.

  • Review after incidents, activations, failed tests, supplier changes, infrastructure changes, and major product or service changes.
  • Update RTOs when impact criteria, minimum acceptable capacity, , dependencies, or resources change.
  • Escalate unresolved capability gaps to risk acceptance, corrective action, budget planning, or management review.
  • Keep a change history so auditors and service owners can see why each RTO was set or revised.
Question 6

Questions and answers

What does RTO mean in ISO 22301?

RTO means : the prioritized timeframe for resuming a disrupted activity at a specified minimum acceptable capacity. ISO 22301 places it inside the BIA and requires that timeframe to be within the period in which the impacts of not resuming would become unacceptable. Equal RTO and values leave no planned recovery margin and need a defensible rationale.

How should the BIA produce the RTO?

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 and document the resources, partners, suppliers, and interdependencies required to meet the target.

How is RTO different from RPO?

RTO is about the time to resume an activity at a specified minimum acceptable capacity. RPO is a separate supporting target for the information recovery point and resulting data loss or rework. ISO 22301:2019 does not define or explicitly require RPO, though an organization can use it where information recovery affects continuity.

When should an RTO be reviewed or changed?

Review RTOs at planned intervals and whenever the organization, service, supplier, technology, legal context, customer commitment, or disruption experience changes. New customer promises, cloud architecture, supplier dependencies, product launches, staffing changes, and failed exercises can all make an older target unrealistic or too weak.

Primary sources

References and citations

doi.org3 citations
Referenced sections
  • Used for operational resilience guidance that discusses RTOs, RPOs, SDOs, contingency plans, tests, and recovery-objective monitoring.
  • ENISA guidance discusses RTOs, RPOs, maximum acceptable outage, and testing recovery objectives in operational resilience measures.
  • Supports operational testing and monitoring of successful and failed recovery objectives in cybersecurity continuity planning.
"RTOs, RPOs and SDOs"
More quoted passages
"successful and failed RTOs"
iso.org3 citations
Referenced sections
  • Official ISO lifecycle page confirming that ISO 22301:2019 edition 2 remains published, has Amendment 1:2024, and is due to be replaced by an edition 3 draft that is still under development.
  • Primary ISO listing for the ISO 22301:2019 business continuity management system requirements standard and its edition status.
  • ISO 22301 requires exercising, testing, evaluating, and improving business continuity strategies, solutions, plans, and procedures.
"Business continuity management systems — Requirements"
iso.org3 citations
Referenced sections
  • Companion ISO guidance for applying, maintaining, and improving an ISO 22301 business continuity management system.
  • Companion guidance for applying ISO 22301 and maintaining a business continuity management system.
  • Supports maintaining and improving the BCMS over time, including review and update of continuity arrangements.
"guidance and recommendations for applying the requirements"
More quoted passages
"maintain and improve a BCMS"
iso.org3 citations
Referenced sections
  • Used for the ICT-continuity distinction between BIA-derived recovery time objectives and recovery point objectives.
  • Supports the distinction between ICT continuity requirements, BIA-derived RTOs, and RPOs for information needed during disruption.
  • Supports BIA-derived ICT continuity requirements, including RTOs for prioritized activities and supporting ICT resources.
"Information security controls"
More quoted passages
"Information security, cybersecurity and privacy protection"
doi.org3 citations
Referenced sections
  • Used for recovery controls that align alternate sites, backups, and recovery capability with RTO and RPO targets.
  • NIST contingency controls distinguish recovery time and recovery point objectives for alternate storage, alternate processing, backups, and recovery.
  • NIST recovery controls support aligning alternate sites, backups, and recovery capabilities with recovery time and recovery point objectives.
"recovery time and recovery point objectives"
More quoted passages
"Organizations establish recovery time objectives"
Show all related guides (19)

ISO 22301 Testing Exercises FAQ

How ISO 22301 teams should plan, run, evidence, and improve business continuity exercises and tests.

ISO 22301 Audit Readiness and Certification Evidence

Prepare ISO 22301 BCMS audit evidence for scope, BIA, risk assessment, objectives, exercises, internal audit, management review, corrective actions, and retained documented information.

ISO 22301 BCMS Requirements: Clauses 4-10

A practical ISO 22301 requirements guide for BCMS scope, leadership, planning, support, operation, BIA, risk assessment, continuity strategies, plans, exercises, audits, management review, corrective action, and evidence.

ISO 22301 BCMS Scope and Boundaries

Define an ISO 22301 BCMS scope that names the organization, products and services, sites, dependencies, outsourced processes, exclusions, interfaces, evidence, and review triggers.

ISO 22301 BIA to Recovery Strategy Workflow

Turn ISO 22301 business impact analysis into recovery priorities, continuity strategies, solutions, exercises, and audit-ready evidence.

ISO 22301 Business Continuity Strategy and Solutions

Build ISO 22301 business continuity strategies and solutions from BIA outputs, recovery objectives, resource needs, supplier dependencies, exercises, and evidence records.

ISO 22301 Business Impact Analysis Template

Build an ISO 22301 business impact analysis template that captures activities, impacts over time, MTPD, RTO, dependencies, resource needs, evidence, review cadence, and continuity-strategy handoff.

ISO 22301 Certification Evidence Checklist

A practical ISO 22301 certification evidence checklist for BCMS scope, BIA, risk assessment, continuity plans, exercises, audits, management review, and corrective actions.

ISO 22301 Compliance Guide | BCMS Requirements

Build ISO 22301 compliance evidence across BCMS scope, leadership, BIA, risk assessment, continuity strategies, plans, exercises, audit, management review, and corrective action.

ISO 22301 FAQ: BCMS, BIA, MTPD, RTO and Audit Evidence

Practical ISO 22301 FAQ for business continuity teams: BCMS scope, BIA, MTPD, RTO, RPO, strategies, exercises, audits, management review, and certification evidence.

ISO 22301 Testing and Exercises Guide

Plan, run, evidence, and improve ISO 22301 business continuity exercises that validate strategies, plans, RTOs, MTPDs, communication procedures, and corrective actions.

ISO 22301 vs DORA: BCMS and Digital Operational Resilience

Compare ISO 22301 business continuity management with DORA digital operational resilience for financial entities, ICT risk, incidents, testing, third-party risk, and reusable evidence.

ISO 22301 vs ISO/IEC 27001: BCMS and ISMS Comparison

Compare ISO 22301 business continuity management with ISO/IEC 27001 information security management: scope, risk work, evidence, certification boundaries, overlap, and common mistakes.