Recovery time objective and recovery point objective both use time, but they describe different targets. RTO concerns how long recovery can take before the outage has an unacceptable impact. RPO concerns the point in time to which data must be restored, often expressed as the acceptable data-loss window.
Work through an original outage example
A service fails at 14:00. Its RTO is two hours, so the exercise’s restoration target is 16:00. The service is restored at 15:30. Measured from the stated failure time, recovery took 90 minutes and met the two-hour RTO.
The latest successfully recoverable data is from 13:45. That leaves a 15-minute gap between the recovery point and the failure. If the RPO is 30 minutes, this exercise meets it. If the RPO is ten minutes, it does not.
The service can therefore meet RTO while failing a stricter RPO. Treating “back online quickly” as proof of both objectives would miss the data-loss question.
Draw each measurement separately
For RTO, draw forward from the failure to restoration. For RPO, look backward from the failure to the most recent recoverable data point. Keep the business targets separate from the actual results measured in the example.
Use the Security+ recovery practice questions to practice labeling these two intervals. If an answer option gives “90 minutes of lost data,” check whether it has accidentally substituted the recovery duration for the data-loss window.
NIST’s RTO definition and RPO definition provide the underlying distinction. A study question may simplify the environment, so use its stated failure time, restoration time, and recoverable-data point consistently.
A schedule is not evidence of a recoverable backup
A backup scheduled every 15 minutes does not prove that each run succeeded or that the data can be restored. The example deliberately says “successfully recoverable data.” Recovery testing matters when determining whether an actual system can meet its objectives.
Likewise, a backup with very recent data can still take too long to restore. More recent data and faster restoration address different parts of the recovery problem.
Keep the Security+ recovery revision notes with one worked timeline. Then change just the restore time and recalculate RTO performance without changing RPO. Next, change only the recoverable-data timestamp. Being able to alter one result while preserving the other is a strong check that you understand the distinction rather than merely remembering which acronym contains the word “point.”