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
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 |
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.
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 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.
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.
A defensible process has five parts:
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.
Recovery targets may need review when:
These are governance problems. Changing a number without revisiting the decision will not resolve them.
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.
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.
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.
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.
No. The application target should reflect when supported processes need the system, available workarounds, dependencies, and the time needed for validation and operational resumption.
Review them on a defined schedule and after material changes, incidents, exercises, acquisitions, technology migrations, vendor changes, or new obligations.