Two short abbreviations can shape a large part of a recovery proposal. You do not need to become an infrastructure specialist to use them well. You need to describe what interruption means for your business and how much missing information it could reasonably tolerate.
Recovery objectives should be business requirements that can be tested, not promises inferred from a product description.
Separate missing data from downtime
Recovery point objective, or RPO, expresses the acceptable period of data loss. Recovery time objective, or RTO, expresses the intended time to restore a service after interruption. AWS describes these as workload recovery objectives. They answer different questions. A service might tolerate some repeated data entry but require a quick return, while another can wait longer but needs a much more recent copy.
Technical background: AWS: Define recovery objectives for downtime and data loss ↗
Start with the business activity
Ask the process owner what would happen if the system stopped during a busy period. Identify which transactions could be reconstructed and which could not. Consider temporary workarounds and how long they remain practical. Use ranges and assumptions at first if exact numbers are unknown. The aim is a considered requirement, not a target chosen because a supplier’s presentation happened to mention it.
Check the complete dependency chain
Recovery time includes more than retrieving data. It may involve setting up infrastructure, restoring access, reconnecting services and checking the application with its users. Ask who performs each action and what must be available first. Likewise, backup frequency alone does not establish an achieved RPO. Check whether copies complete successfully and whether they can actually be used for the intended recovery scenario.
Treat targets as something to validate
Compare the proposed recovery arrangement with the objectives and test a suitable scenario. Record the starting point, elapsed time, data restored and remaining limitations. If the result misses the target, agree whether to improve the arrangement, change the business workaround or revisit the requirement. Keep objectives attached to named services and review them when the organisation or application changes.
PUT IT INTO PRACTICE
Your starting checklist.
Use these prompts to prepare your next decision or conversation.
YOUR NEXT STEP WITH IT MOUNTAIN
Turn the question into a plan.
Talk to IT Mountain about the activities your business needs to resume. Use those priorities to shape recovery objectives and the scope of testing.
