The recovery time objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.
It can include the time for trying to fix the problem without a recovery, the recovery itself, testing, and the communication to the users. Decision time for users representative is not included.
The business continuity timeline usually runs parallel with an incident management timeline and may start at the same, or different, points.
In accepted business continuity planning methodology, the RTO is established during the Business Impact Analysis (BIA) by the owner of a process (usually in conjunction with the business continuity planner). The RTOs are then presented to senior management for acceptance.
The RTO attaches to the business process and not the resources required to support the process.
The RTO and the results of the BIA in its entirety provide the basis for identifying and analyzing viable strategies for inclusion in the business continuity plan. Viable strategy options would include any which would enable resumption of a business process in a time frame at or near the RTO. This would include alternate or manual workaround procedures and would not necessarily require computer systems to meet the RTOs.
The "O" in RTO stands for objective, not mandate. In reality, tactics are often selected that will not meet the RTO. In this instance, the RTO will not be met but should still remain an objective of future strategy revision.
In a good deal of the literature on this subject, RTO is spoken of as a complement of recovery point objective (RPO), with the two metrics describing the limits of acceptable or "tolerable" ITSC performance in terms of time lost (RTO) from normal business process functioning, and in terms of data lost or not backed up during that period of time (RPO) respectively.