BSI BS 25999, Part 2:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Recovery time objective: Target time set for resumption of product, service or activity delivery after an incident; the recovery time objective has to be less than the maximum tolerable period of disruption.
Maximum tolerable period of disruption: Duration after which an organization's viability will be irrevocably threatened if product and service delivery cannot be resumed.
Recovery point objective: Point in time to which work should be restored following an unplanned operational event that interrupts/disrupts the business, e.g., start of day, often used as basis for development of backup strategies, and as a determinant of the amount of data needed to run the organization after systems and/or functions have been successfully recovered.
Recovery time objective: Period of time within which systems, applications, or functions must be recovered after an outage (e.g., one business day); used to develop recovery strategies, and to determine whether or not to implement recovery strategies following a disaster situation; output from business impact analysis that identifies the time in which mission critical activities and/or their dependencies must be recovered.
Perhaps the easiest way to address this conundrum is to examine a timeline. The following diagram depicts the typical view of the relationship among these three terms.
In the figure below, we see that the recovery point objective is a point in time prior to the incident occurring. This point in time is where you want to be able to recover and restart operations, especially with regard to data and systems recovery.
RPO, RTO and MTPOD
Following the incident's occurrence, the recovery time objective is the goal in which a minimally acceptable level of business operations can be established. It may not be business as usual, but it usually means a point in time that the business can be assured that it will be able to resume business as usual, at some point in the future.
MTPOD implies a point in time -- even if some level of recovery has occurred -- beyond which the business may not, in fact, be able to fully resume business as usual. This suggests that the RTO level of recovery may not be sufficient to ensure full business recovery (and business as usual) unless some additional actions take place, such as relocating staff to an alternate location.
Although RTO and RPO metrics have been used satisfactorily for many years, disaster recovery/business continuity professionals ought to consider the implications of MTPOD when designing disaster recovery/business continuity strategies and plans.
Dig Deeper on Disaster recovery planning - management
Related Q&A from Paul Kirvan
When taking a hybrid disaster recovery approach -- using public and private components -- it's important to understand your requirements, assets and ...continue reading
If you're considering software-defined networking in your disaster recovery platform, define your DR requirements first. SDN can help support data ...continue reading
A call tree can be an important piece of disaster recovery planning. Follow these steps for call tree design and execution to ensure your company is ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.