When Change Healthcare went offline in February 2024 after a ransomware attack, pharmacies across the United States found themselves unable to process claims for days. The outage exposed a brutal fact: many organisations had never asked how long they could actually survive without a given system before the damage became irreversible. That question , asked and answered rigorously before the incident , is exactly what BIA metrics are designed to address.
What is RTO RPO MTD?
RTO (Recovery Time Objective), RPO (Recovery Point Objective), and MTD (Maximum Tolerable Downtime) are quantitative thresholds produced during a business impact analysis (BIA) to define how quickly a function must be restored, how much data loss is acceptable, and how long the organisation can endure an outage before consequences become unacceptable. MAO (Maximum Acceptable Outage) is a functionally equivalent term to MTD used in ISO 22301 and UK regulatory guidance.
The four metrics and what they actually measure
Recovery Time Objective (RTO)
RTO is a target. It says: *this function must be operational again within X hours*. The number comes from business analysis , how long before customers churn, regulators intervene, revenue damage becomes existential, or downstream processes collapse?
RTO is not a technical capability statement. It is a business requirement handed to IT and operations so they can design recovery solutions that meet it. If your payments function has an RTO of four hours but your backup restoration takes six, you have a gap. Closing that gap is the work. A business continuity plan without validated RTOs is essentially a document with placeholders.
Recovery Point Objective (RPO)
RPO answers a different question: how much data can we afford to lose? It is expressed in time , the maximum age of data that a restored system can tolerate.
An RPO of one hour means that if a system fails at 3:00 PM, you must be able to restore data from no earlier than 2:00 PM. If your last backup ran at midnight, your actual recovery point is 15 hours, not one. That gap between the RPO the business sets and the RPO the infrastructure actually delivers is one of the most common , and most dangerous , disconnects in continuity planning.
RPO is primarily relevant to data-bearing systems, which is why it is often discussed in the context of IT disaster recovery. For a deeper treatment of how RTO and RPO interact specifically in DR contexts, see RTO vs RPO explained. This article focuses on how both metrics originate in the BIA, before they become DR design constraints.
Maximum Tolerable Downtime (MTD)
MTD is the hard ceiling. It defines the point after which a disruption causes harm that cannot be recovered from: regulatory penalties crystallise, contracts are breached, reputational damage becomes permanent, or the organisation itself is at risk.
MTD is always longer than RTO. The gap between the two is deliberate buffer. If MTD for a payroll function is 72 hours and RTO is 24 hours, the 48-hour difference gives room for things to go wrong during recovery. Collapse that buffer , by setting an RTO too close to MTD , and any recovery hiccup tips the organisation over the edge.
ISO 22301, the international standard for business continuity management, uses MTPD (Maximum Tolerable Period of Disruption) as its preferred term, which maps directly to MTD.
Maximum Acceptable Outage (MAO)
MAO is the same concept as MTD, expressed slightly differently. The Financial Conduct Authority, APRA, and several European regulatory frameworks use MAO as the primary term. Under the Digital Operational Resilience Act (DORA), for example, financial entities must define impact tolerances for critical functions , a concept that maps closely to MAO.
In practice, if your organisation uses MTD and MAO interchangeably, that is fine. What matters is that the concept , the absolute outer boundary of tolerable disruption , is clearly defined, agreed upon, and documented per function.
How the metrics relate to each other
These four metrics form a logical hierarchy for each business function. Getting the relationships wrong is a common source of planning failure.
| Metric | What it measures | Expressed as | Who sets it | Relationship to others |
|---|---|---|---|---|
| RPO | Maximum tolerable data loss | Time (hours, minutes) | Business + IT jointly | Must be ≤ RTO for data-dependent functions |
| RTO | Target recovery time | Time (hours, days) | Business owners | Must be < MTD/MAO |
| MTD / MAO | Absolute outer boundary of tolerable downtime | Time (hours, days) | Business owners, validated by leadership | Always > RTO; defines the buffer |
One practical rule: RTO should sit at no more than 50-60% of MTD. If your MTD is 24 hours and your RTO is 23 hours, a recovery that takes 25 hours , entirely plausible during a chaotic incident , blows straight through your absolute tolerance.
Where these metrics come from: the BIA process
None of these numbers should be invented by an IT team alone. They emerge from structured interviews and workshops with process owners, typically using a BIA template that asks questions like:
- What is the financial impact of this function being unavailable for 1 hour? 4 hours? 24 hours? 72 hours?
- At what point do regulatory reporting obligations begin to be missed?
- Which downstream functions depend on this one, and when do they fail?
- What is the minimum resource set needed to operate this function at reduced capacity?
The answers create impact curves , showing how damage accumulates over time , from which RTO and MTD values can be read off rather than guessed. The BIA interview questions used at this stage significantly affect the quality of the metrics you get.
MTD is usually set first, because it defines the envelope. RTO is then set within that envelope. RPO is set based on data sensitivity and dependency analysis.
Common mistakes when setting these metrics
Setting RTOs aspirationally, not analytically. The most frequent error is process owners declaring an RTO of "four hours" for every function because it sounds rigorous. Without impact data backing the number, the RTO is meaningless. Four hours may be wildly expensive to achieve for a low-criticality function, and completely insufficient for a customer-facing one.
Treating MTD as equivalent to RTO. When the buffer between RTO and MTD disappears, recovery plans have no margin. The CrowdStrike Falcon outage in July 2024 took most affected organisations far longer to remediate than initial estimates suggested , machines required manual intervention, and at scale that took days. Organisations whose RTOs sat right at their MTD had no room for that kind of reality.
Setting RPO without knowing actual backup frequency. RPO is only useful if IT has verified that infrastructure can actually deliver it. An RPO of 15 minutes implies near-continuous replication. Many organisations discover during a disaster recovery test that their actual recovery point is measured in hours, not minutes.
Failing to differentiate by function. A single enterprise-wide RTO is almost always wrong. Payroll, customer authentication, internal HR reporting, and executive dashboards have fundamentally different impact curves. A proper BIA produces metrics per function, not per organisation.
Metrics in a regulatory context
For regulated industries, these metrics are not optional documentation. Under DORA, financial entities in the EU must set impact tolerances and demonstrate they can meet them. ISO 22301 requires that MTPD (MTD) be determined for each activity and that recovery objectives be set within it.
The BCM maturity benchmark consistently shows that organisations with formally validated, function-level metrics score significantly higher on recovery capability than those with generic, organisation-wide thresholds.
For business continuity strategies to be credible, they must be anchored to these metrics , not drafted in isolation and then labelled with arbitrary timeframes after the fact.
Keeping metrics current
BIA metrics decay. A function's criticality changes as the business changes , new products, new dependencies, new regulations. The RTOs and MTDs set three years ago for a payment system may be completely misaligned with today's transaction volumes and regulatory expectations.
Always-on BCM programs build review cycles directly into operations rather than treating the BIA as a periodic project. When metrics are reviewed continuously, they remain actionable rather than becoming artifacts that practitioners distrust.
