Guide
RTO, RPO and MTPD: How much downtime can your process tolerate?
Derive recovery time and tolerable data loss from the business process. Includes a worked example, time buffer and recovery test questions.
“Four hours of downtime is fine.” For whom, at what time and at what level of service? Without those answers, a number quickly becomes an untested promise. RTO, RPO and MTPD help only when you derive them from a specific business process.
Three measures, three different questions
MTPD is the maximum tolerable period of disruption of a business process. Beyond it, the impact becomes unacceptable. RTO is the recovery time objective. RPO describes how old the available data may be, meaning the data loss you tolerate. BSI Standard 200-4, chapter 7 places these measures within the business impact analysis.
In the BSI model, RTO starts when an emergency is declared and ends when the business continuity solution is required to be operational. Response time and an additional buffer must therefore fit within the maximum tolerable disruption. Explicitly agree on the reference point: technical restoration time is not automatically the RTO of a usable business process.
Our example illustrates one possible plan. The figures are fictional, rather than industry requirements or recommendations for your business.
Start with a service, not a server
A spare parts distributor must be able to confirm urgent orders and pass them to its warehouse. The team examines an outage during staffed business hours. After four hours, this example would face unacceptable delays to promised deliveries. The owners therefore set MTPD at four hours.
That assessment needs justification. Check delivery windows, obligations, backlogs and the ability to catch up. A morning outage can have different consequences from the same outage shortly before dispatch closes. A business impact analysis concerns the process and its dependencies, rather than the convenience of an existing backup schedule.
For this distributor, fallback operation initially means processing urgent orders. Full speed and every reporting function need not yet be available. Without this minimum level, “recovered” remains ambiguous.
Calculate the time budget
The team reserves 30 minutes for detection, assessment and declaring an emergency. Recovery to the agreed fallback service level is allocated 150 minutes. Another hour remains as a buffer.
| Phase | Time in this example | Outcome |
|---|---|---|
| Detect and decide | 30 minutes | Emergency declared; responsible people working |
| Recovery: RTO | 150 minutes | Urgent orders can be processed again |
| Reserve before MTPD | 60 minutes | Room for deviations |
| Maximum tolerable disruption | 240 minutes | Limit established by the business assessment |
The calculation is 30 + 150 + 60 = 240 minutes. The buffer is not extra time after MTPD. Business acceptance also belongs before recovery ends: if the database is reachable after two hours but nobody can complete orders, the objective has not been met.
Include dependent steps. Identity services, network, application and warehouse interfaces may have different owners. Where tasks must occur sequentially, their combined duration cannot be replaced by the fastest individual time.
Decide tolerable data loss separately
In this example, no more than 15 minutes of order data may be lost. That is the agreed RPO. Ask the business team how those orders could be reconstructed and which information would need to remain available. Losing an order differs from losing a statistic that can be generated again.
A backup every 15 minutes does not alone prove compliance. If the last job failed or its output is unusable, the last usable data state is older. Test the state actually restored and its business consistency.
RPO also says nothing about how quickly you retrieve the data. A very recent backup may take too long to restore. Conversely, a fast restore may deliver data that is too old.
A test must represent the work
Define success before testing. For our distributor, that could mean correctly entering, confirming and passing three urgent test orders to a test warehouse. Use a suitable test environment and data that cannot trigger real deliveries.
The record should include starting points, interruptions, available data states and business acceptance. Missing a time objective is a result, rather than a reason to adjust the target retrospectively. Decide between a better recovery solution, a different fallback operation or a reasoned reassessment of business needs.
In Kopexa, you can connect the BIA and affected assets with risks and measures. Attach test records as evidence to measures. This shows which gap the team must close. For the next risk assessment, the measured workflow matters alongside the planned value.
Next step: Choose a time-critical process. Ask business and IT teams to agree which service must function after recovery. Set the numbers afterwards.