During business impact analysis for a cloud-hosted order system, the business states it can survive at most eight hours without the system. The IT recovery team then commits to restoring the system to operation within four hours of a disaster being declared. Which recovery metric is the four-hour commitment?
Select an answer to reveal the explanation.
Short Explanation
Here's the easy way to keep them straight: MTD is the business saying how long it can hold its breath, and RTO is IT promising to get air back sooner than that. The eight hours is MTD; the four-hour restore target sits inside it, and that's your RTO. Don't let 'data loss' or 'capacity' words pull you toward RPO or recovery service level.
Full Explanation
The recovery time objective is the target duration within which a system must be restored to operation after a disruption. It is a commitment made by the recovery function and must be set below the maximum tolerable downtime, which is the business's own limit on how long it can operate without the function before the impact becomes unacceptable. In this scenario the eight-hour figure is the MTD and the four-hour restoration target is the RTO; the gap between them is margin for detection, decision-making and validation. The recovery point objective measures data, not time to recover: it states how much recent data, expressed as time before the incident, the business can afford to lose, and it drives backup and replication frequency. Maximum tolerable downtime was the business statement already given, not the recovery team's commitment. The recovery service level describes how much of normal capacity or performance must be available while operating in a degraded recovery mode, which says nothing about how quickly service returns. Exam caveat: RTO must always be shorter than MTD; a plan whose RTO exceeds the MTD is defective by definition. Operational check: compare measured restoration times from the last DR exercise with the documented RTO, and confirm the RTO is recorded against the MTD in the BIA.