MTPD/MAO describes how long disruption can be tolerated before impacts become unacceptable. RTO is the target time to restore a process, service or technology resource. RPO is the maximum acceptable data-loss window. MBCO describes the minimum acceptable service level during disruption. They answer different questions and should be derived from business impact and recovery capability rather than selected independently.
Recovery objectives compared
| Measure | Question it answers | Example |
|---|---|---|
| MTPD / MAO | How long can disruption continue before impact becomes unacceptable? | 12 hours |
| RTO | By when do we target restoration? | 4 hours |
| RPO | How much recent data can we afford to lose? | 15 minutes |
| MBCO | What minimum service level must be available during disruption? | 60% of normal payments, with priority customers first |
A simple timeline
Imagine a payment service fails at 09:00. Its BIA shows that disruption becomes unacceptable after 12 hours. Management therefore sets an MTPD of 12 hours. The organization targets restoration by 13:00, giving an RTO of four hours and leaving eight hours of margin before the maximum tolerable point. The service database has a 15-minute RPO, meaning the recovery design should be capable of restoring data to within approximately 15 minutes of the failure point.
The service also has an MBCO: during disruption it must process at least 60% of normal transaction volume and prioritize defined customer segments. This prevents the plan from treating “system available” as the only success condition.
RTO is not the same as demonstrated recovery time
An approved four-hour RTO is a requirement. If the latest recovery test took 6.5 hours, demonstrated capability is 2.5 hours outside the target. BCM should report this as a gap and link it to an action, funded strategy or explicit risk decision. Hiding the difference creates false assurance.
Recovery capability gap = demonstrated recovery time − target RTO. A positive number means recovery is slower than the target. Try it in the RTO Capability Gap Checker.
How to derive MTPD or MAO in a BIA
Do not start by asking, “What RTO do you want?” Instead, examine impact over time. Ask what happens after two hours, eight hours, one day, three days and one week—or use time bands appropriate to the service. Consider safety, legal/regulatory, customer, financial, operational and reputation impacts. Record the evidence behind each threshold. The point where the combined impact becomes unacceptable helps inform the maximum tolerable disruption.
How to set the RTO
RTO should normally be inside the tolerable disruption window and should account for dependencies and operational sequencing. A process cannot realistically have a two-hour RTO if its required application has an eight-hour technical recovery target. This is why BIA data should be reconciled across business services, applications, facilities and suppliers rather than stored in separate spreadsheets.
How to set the RPO
RPO is about data, not downtime. Ask how much transaction history, case work, orders, configuration or other information can be recreated manually without creating unacceptable impact. A zero or near-zero RPO usually requires stronger replication, journaling or transaction design than a 24-hour RPO. The business requirement should be validated against technical architecture and cost.
When MBCO is useful
Some services do not need to return immediately at 100% capacity. MBCO lets the organization define a minimum viable operating level: number of cases per hour, percentage of normal capacity, specific customer classes, critical locations, priority products or a minimum staffing model. It turns “recover the service” into a more operationally testable statement.
Common mistakes
- Copying the same RTO across every process because it is easier to administer.
- Setting RTO equal to MTPD and leaving no recovery margin.
- Calling backup frequency an RPO without proving restores are possible.
- Ignoring dependency RTOs and supplier recovery commitments.
- Reporting approved targets as if they were tested capability.
- Using extremely aggressive targets without linking them to investment and architecture decisions.
Worked example: payroll
Payroll may tolerate several days during a normal week but have a much shorter tolerable outage immediately before payroll cut-off. The BIA therefore needs peak-period logic. The RTO can vary by period, and the continuity strategy may include an alternate approval process, pre-positioned payroll files and a defined manual emergency payment method. Recovery objectives should reflect how the business actually operates, not only an annual average.
Use the numbers as one connected decision
The most useful recovery-objective record stores the target, the reason, owner, approving authority, upstream/downstream dependencies, technical capability, last exercise result, date reviewed and any gap action. That turns a number into an auditable management decision.
Use the BCM System Playground to create a service, enter MTPD/RTO/RPO/MBCO values, connect dependencies and see how they flow into strategy, planning and assurance.