Business process owners should define recovery requirements based on operational impact. The business continuity team facilitates and challenges the analysis, IT validates technical feasibility, and the appropriate risk owner or leadership group approves material cost and risk decisions.
IT is central to recovery planning, but it should not set RTOs and RPOs alone. Technical recovery time describes capability, not necessarily business tolerance.
In short
- Process owners propose acceptable downtime and data-loss requirements.
- The BC team challenges assumptions and maintains the decision process.
- IT maps business processes to technology and validates recovery capability.
- Authorized risk owners approve significant gaps, investments, or risk acceptance.
- Targets should be documented, tested, and reviewed as operations change.
Who Owns RTO and RPO Decisions?
The process owner starts because that person knows when delayed work affects customers, revenue, safety, contractual commitments, compliance, or downstream operations.
That does not mean a process owner can choose any number. “We need it back immediately” is a preference, not a supported requirement. Test the target against impact over time, peak periods, dependencies, workarounds, and backlogs.
The BC team guides the analysis and compares targets across the organization. IT determines whether current recovery arrangements can meet the requirement. If a material gap remains, the appropriate risk authority decides whether to fund an improvement, change the process, approve a workaround, or accept the exposure.
| Decision | Primary role | Supporting roles |
|---|---|---|
| Propose process RTO and RPO requirements | Process owner | BC team, data owner |
| Challenge and normalize proposed targets | BC program | Process owners, risk or compliance |
| Set supporting technology recovery targets | IT/DR | Process owner, application owner, BC team |
| Validate current recovery capability | IT/DR | Vendors, application owners |
| Approve material gaps or risk acceptance | Authorized risk owner or leadership | Business, IT, BC, finance |
| Maintain the record and review schedule | BC program | Business owners and IT |
| Revalidate requirements and capabilities | Process owner and IT/DR | BC program |
Separate the Requirement From the Capability
A common mistake is to begin by asking IT, “How quickly can you restore this system?” The answer is useful, but it describes capability. Recovery planning needs to establish the business requirement first, then compare the two.
Process and Technology RTOs
A process RTO defines when an operation must resume. A technology RTO defines when an application or infrastructure component must be available to support that resumption.
They are related but not interchangeable. A workaround may keep a process running temporarily. An application supporting several processes should be available before the earliest validated business need, with time left for system validation and operational resumption.
Copying a process RTO into every related application record can create false precision and unnecessary cost.
RTO and RPO
RTO addresses restoration time. RPO expresses how much recent data or work the organization can tolerate losing, usually measured backward in time from the disruption.
Assess the two separately. A process may need to resume quickly even if several hours of data can be recreated. Another may tolerate a longer outage but be unable to reconstruct lost transactions. Business owners define the acceptable outcome. IT explains what current data-protection methods can deliver.
Maximum Tolerable Downtime and RTO
NIST defines maximum tolerable downtime as the time a mission or business process can be disrupted without significant harm. Other methods use terms such as maximum tolerable period of disruption or maximum acceptable outage, sometimes differently.
The RTO should normally be shorter than the applicable maximum tolerance. That difference provides time for the full recovery sequence, including detection, escalation, technology restoration, operational validation, and resumption of normal processing.
How to Set and Approve Recovery Targets
A defensible process has five parts:
- Define the process, outputs, peak periods, customers, dependencies, and available workarounds.
- Assess how operational, financial, legal, safety, and reputational impacts change over relevant time intervals.
- Propose RTO and RPO separately, with the assumptions and evidence behind each value.
- Compare the requirement with tested technical capability, vendor commitments, backup schedules, staffing, and known constraints.
- Document the approved target, capability gaps, owner, decision authority, actions, and review triggers.
If capability falls short, do not quietly change the business requirement to match IT’s current performance. Put the gap in front of the right decision-maker.
Signs That Recovery-Target Governance Is Weak
Recovery targets may need review when:
- Every critical process has the same RTO.
- Targets were copied from an old BIA without validation.
- Current IT capability is recorded as the business requirement.
- Process owners request zero downtime or data loss without evidence.
- Application targets do not trace back to supported processes.
- Known gaps have no owner, action, workaround, or risk decision.
- Exercise results do not lead to updated targets or strategies.
These are governance problems. Changing a number without revisiting the decision will not resolve them.
What Standards and Guidance Support
ISO 22301 sets BCMS requirements. ISO/TS 22317 guides a formal BIA process without prescribing one method. NIST SP 800-34 Revision 1, for federal information systems, uses the BIA to determine contingency requirements and priorities.
These sources connect recovery requirements to business impact, operational priorities, and technical planning. They do not prescribe the responsibility model in this article, but they support treating recovery targets as more than isolated IT settings.
Sector guidance may add specific expectations. The FFIEC Business Continuity Management booklet addresses recovery planning, testing, governance, and critical operations. FFIEC Appendix J separately states that outsourced-technology contracts should address clear RTOs and RPOs.
Keep Recovery Targets Current
Approved targets should stay connected to assumptions, dependencies, capabilities, gaps, decisions, and review dates. BCMMetrics BIA On-Demand can record impact categories, RTO and RPO selections, process dependencies, and reports. Software maintains the information. It does not decide what disruption the organization should accept.
Review targets on schedule and after material changes, incidents, exercises, acquisitions, vendor changes, or new obligations.
Frequently Asked Questions
Who is responsible for setting recovery time objectives?
Business process owners should propose RTOs based on operational impact. The BC team facilitates the analysis, IT validates feasibility, and the appropriate authority approves material tradeoffs or accepted risk.
What role should IT play in setting RTOs and RPOs?
IT maps processes to supporting technology, documents current recovery capability, estimates what is required to close gaps, and tests whether approved objectives can be met.
Does an application RTO have to match the business-process RTO?
No. The application target should reflect when supported processes need the system, available workarounds, dependencies, and the time needed for validation and operational resumption.
How often should recovery targets be reviewed?
Review them on a defined schedule and after material changes, incidents, exercises, acquisitions, technology migrations, vendor changes, or new obligations.
