What is maximum tolerable downtime?
Maximum tolerable downtime (MTD) is the longest a business function or process can be disrupted before the damage to the organization becomes unacceptable. Beyond that point the losses may not be recoverable: customers leave, contracts are breached, regulators step in, or, in a hospital, patients are put at risk. The business owner of the function sets the MTD using the business impact analysis, and IT designs recovery to beat it.
You will also see it called maximum allowable downtime or maximum acceptable outage (MAO), and ISO 22301 and other business continuity standards use maximum tolerable period of disruption (MTPD).
How MTD relates to RTO and RPO
MTD is a business limit. The recovery time objective (RTO) is the technical target for restoring a system, and it must be shorter than the MTD of every function that depends on that system. The gap between the two isn't slack. After a system comes back, staff still need time to check data, reprocess interrupted transactions and work through the backlog. Many continuity guides call this the work recovery time (WRT) and express the relationship as:
RTO + WRT ≤ MTD
The recovery point objective (RPO) measures something else, how much data loss is acceptable, so it has no direct arithmetic link to MTD. It does affect WRT: the more data that has to be re-entered after a restore, the longer the business takes to recover.
Example: a mail-order pharmacy
A business impact analysis of a mail-order pharmacy's prescription system finds that after 12 hours of outage, orders for time-sensitive medication start missing their shipping window, and patients and regulators are affected. The pharmacy director sets the MTD at 12 hours. Pharmacists need about 4 hours after the system returns to re-verify queued prescriptions, so the system's RTO can be no more than 8 hours. The order database, the e-prescription interface and the identity service they rely on all inherit that ceiling, because the function isn't working until every dependency is back. A tape restore that takes 20 hours can't meet it, so the design calls for a standby database at a warm site.
Why MTD matters
- It ranks recovery: functions with the shortest MTD come back first, along with everything they depend on.
- It drives cost: a short MTD calls for hot or warm sites, replication and failover, while a long one can be met with backups and a cold site.
- It exposes gaps: if a system's tested recovery time is longer than its function's MTD, the plan has failed before any disaster happens, and leadership must fund a fix or accept the risk in writing.
MTD vs. RTO, RPO and MTTR
| Metric | What it measures | Where it comes from |
|---|---|---|
| MTD | Longest a business function can be down | Business owner, from the BIA |
| RTO | Deadline for restoring a system | Derived from the MTD |
| RPO | Most data loss that is acceptable, measured in time | Business owner, from the BIA |
| MTTR | Average time actually taken to repair a component | Measured from history |
Maximum tolerable downtime on the CompTIA Security+ exam
MTD is an output of the business impact analysis, which SY0-801 covers under risk management in objective 5.2, and it sets the ceiling for the RTO. Objective 3.4 covers the recovery metrics RTO, RPO, MTTR and MTBF; MTD is the business limit the RTO has to fit inside. If a scenario asks for the longest outage the business can survive, the answer is MTD; the restore deadline IT designs around is RTO; the amount of data that can be lost is RPO. A common distractor is MTTR, which measures how long repairs actually take, not how long the business can wait.