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 maximum tolerable downtime (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
Each metric answers a different question, and confusing them is the most common source of unrealistic recovery targets. They are defined in turn below.
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.
Definitions at a glance: RTO, RPO, MTD, and MAO
Before diving into how these metrics interact, it helps to see them side by side. Each answers a distinct question about organisational tolerance for disruption.
Recovery Time Objective (RTO): How quickly must this function be restored? Set by the business, used by IT and operations as a design constraint for recovery solutions.
Recovery Point Objective (RPO): How much data loss is acceptable, expressed as time? An RPO of two hours means the restored system must reflect data no older than two hours before the failure.
Maximum Tolerable Downtime (MTD): What is the absolute ceiling on outage duration before harm becomes irreversible? MTD is defined in ISO 22301:2019 Clause 8.4 as the period after which a disruption has consequences that the organisation cannot recover from, including regulatory penalties, contract breach, or permanent reputational damage.
Maximum Acceptable Outage (MAO): The ISO 22301 and UK regulatory term for the same concept as MTD. In practice, MAO and MTD are used interchangeably. ISO 22301:2019 Annex A uses MAO explicitly; many US-origin BCM frameworks use MTD. The calculation method is identical.
A critical relationship to remember: RTO must always be shorter than MTD/MAO. The gap between them is intentional buffer. If that buffer disappears, any delay in recovery execution immediately breaches the irreversible-harm threshold.
How RTO, RPO, MTD, and MAO compare across industries
The metrics look different depending on the sector. The following examples reflect ranges practitioners typically encounter during BIA workshops; they are not regulatory mandates, and every organisation must validate its own numbers through impact analysis.
Retail payments processing
- MTD/MAO: 4 hours (customer-facing transaction failure, card scheme contractual obligations)
- RTO: 1–2 hours
- RPO: 15–30 minutes
- Who sets MTD: CFO and Head of Payments, informed by card scheme rules
Inpatient hospital admissions
- MTD/MAO: 2–4 hours (patient safety escalation, regulatory notification triggers)
- RTO: 30–60 minutes for critical clinical systems
- RPO: Near-zero for patient records; point-of-failure recovery expected
- Who sets MTD: Clinical governance lead and Chief Medical Officer
Corporate HR and payroll
- MTD/MAO: 72–120 hours (depending on payroll cycle proximity)
- RTO: 24–48 hours
- RPO: 24 hours (one business day of transaction data)
- Who sets MTD: HR Director and Finance, cross-checked against employment law obligations
B2B SaaS platform (mid-market)
- MTD/MAO: 24–48 hours (SLA breach triggers, customer contract penalties)
- RTO: 4–8 hours
- RPO: 1–4 hours
- Who sets MTD: Commercial/Legal team informed by customer SLA portfolio
These ranges illustrate a consistent pattern: MTD is a business and legal determination first, and a technical constraint second. IT inherits RTO as a requirement; it does not set MTD.
How these metrics interact during a BIA, and where teams miscalibrate
In most BIA workshops, the most common miscalibration is teams treating RTO as a synonym for MTD. They ask: "How quickly do you need this back?" and record the answer as both the recovery target and the tolerable ceiling. That collapse of two separate metrics into one number creates a false picture of resilience.
Here is the practical difference. MTD is the point of no return, the moment at which consequences become catastrophic and unrecoverable. RTO is the target that gives you enough buffer before that point. If a payments function has an MTD of 8 hours and you set RTO at 8 hours as well, any slip in recovery execution, a failed failover, a missing configuration file, a vendor callback delay, immediately pushes you past the catastrophic threshold. There is no margin.
A well-calibrated BIA ensures that RTO is set with enough lead time before MTD to account for realistic execution variability. A reasonable rule of thumb is that RTO should sit at no more than 50–60% of MTD for any critical function. For functions where the MTD is itself very short (under 4 hours), that gap needs to be even more deliberate.
The second common miscalibration is RPO drift. Business stakeholders often set an RPO during a BIA workshop without understanding the infrastructure reality. An RPO of one hour sounds conservative until you discover that backup jobs run nightly and the replication lag on the secondary database is six hours. The BIA process must include a validation step where stated RPOs are checked against actual infrastructure capabilities. Fortiv's dependency mapping surfaces the systems and data flows underpinning each business process, which makes this validation step significantly faster than doing it manually in spreadsheets.
A third miscalibration is failing to distinguish between MTD for a process and MTD for the underlying technology. A finance reconciliation process might have an MTD of 48 hours, but it depends on three separate systems, each of which has a shorter individual MTD if they fail in combination. BIA practitioners need to analyse dependency chains, not just individual function tolerances.
Worked example: payments processing at a financial services firm
Consider a mid-sized UK payment institution running its own payment gateway and settlement function. The BIA team is working through the payment processing function with the Head of Payments, the CTO, and Legal.
Step 1: Determine MTD/MAO
The Legal team confirms that FCA operational resilience rules (PS21/3) require the firm to remain within its impact tolerances at all times. The Head of Payments knows from card scheme rules that a continuous processing outage beyond 4 hours triggers a mandatory incident notification and may result in suspension of scheme membership. The firm's own customer SLAs specify that any outage exceeding 2 hours entitles enterprise customers to penalty credits. The BIA team sets MTD at 4 hours, driven by the scheme notification obligation.
Step 2: Set RTO
Working back from a 4-hour MTD, and accounting for realistic failover time (30 minutes), incident triage (15 minutes), and approvals to invoke the recovery plan (15 minutes), the team sets RTO at 2 hours. This leaves a 2-hour buffer before MTD. The CTO confirms the primary failover architecture can achieve a 90-minute restore under normal conditions, so RTO of 2 hours is achievable.
Step 3: Set RPO
The payments function processes transactions continuously. A data loss of more than 10 minutes would mean unreconciled transactions that could result in double-charges or missed settlements. RPO is set at 10 minutes. The infrastructure team confirms that synchronous replication to the secondary data centre achieves a real-world recovery point of under 5 minutes, so the RPO is met.
Step 4: Record and test
The metrics are documented in the BIA output: MTD 4 hours, RTO 2 hours, RPO 10 minutes. They are assigned to the payments function in the BCM platform so they can be reviewed annually and after any material change to the payments architecture. The recovery capability is tested in a tabletop exercise simulating a primary data centre failure, using the 4-hour MTD as the hard boundary for the scenario timeline.
This example shows why the order of operations matters. MTD came first, driven by regulatory and contractual obligations. RTO was derived from MTD with margin. RPO was set by business data tolerance and validated against infrastructure.
Sources
ISO 22301:2019 Business Continuity Management Systems, Clause 8.4 and Annex A. FCA/PRA PS21/3 Building Operational Resilience, effective March 2022. ISO 22301:2012 (superseded; MTD terminology originated here). BCI Good Practice Guidelines 2018 Edition.
