Maximum Acceptable Outage (MAO) is used by some organizations to describe the point beyond which disruption becomes unacceptable. Terminology differs across methods and standards, so the first governance rule is to define exactly what MAO means in your BCMS and use it consistently.
MAO is a boundary, not a recovery promise
If unacceptable impact occurs after 24 hours, setting an RTO of 24 hours leaves no margin for activation, degraded recovery or validation. Recovery targets should normally sit inside the tolerance boundary and reflect dependencies, strategy and risk appetite.
Derive the boundary from impact
- Define the service and disruption scenario.
- Assess consequences at meaningful time bands.
- Identify legal, safety, customer, financial and operational thresholds.
- Locate the earliest point where consequences exceed approved tolerance.
- Record the evidence and assumptions.
- Set recovery objectives inside that boundary and validate feasibility.
Example
| Elapsed outage | Observed consequence | Assessment |
|---|---|---|
| 2 hours | Queue grows; no missed commitment | Tolerable |
| 8 hours | Priority cases require manual handling | Material |
| 16 hours | Customer SLA breaches begin | Severe |
| 24 hours | Regulatory deadline cannot be met | Unacceptable |
In this example the tolerance boundary is driven by the 24-hour regulatory consequence. A defensible RTO might be 12 or 16 hours depending on validation and management risk appetite, not 24 hours by default.
Test competing impact dimensions
The earliest unacceptable consequence should drive the boundary. A financial loss threshold at three days is irrelevant if a safety or statutory obligation becomes unacceptable at eight hours. Conversely, do not inflate urgency with vague reputation language when measurable consequences occur much later.
Account for timing and seasonality
An outage on payroll cut-off day, during a market settlement window or at peak production can have a different tolerance from the same outage during a quiet period. Record whether the value is worst-case, typical, or scenario-specific. If timing materially changes the result, use conditional objectives or plan for the stricter case.
Dependency consistency
Compare the service boundary with application, data, supplier, facility and staffing recovery. If a required dependency cannot recover before the service objective, either improve the dependency strategy, establish a workaround, change the service objective with approved risk acceptance, or challenge the original BIA conclusion.
Common mistakes
- Asking the owner to guess MAO without impact analysis.
- Setting MAO equal to RTO.
- Using one standard value for all services.
- Ignoring calendar deadlines and peak periods.
- Confusing technical downtime with business disruption.
- Failing to document why impact becomes unacceptable.
Review evidence
- Time-based impact rationale.
- Legal or contractual deadlines.
- Transaction/backlog volumes.
- Manual workaround capacity.
- Customer and supplier commitments.
- Approved impact criteria and risk appetite.
- Dependency recovery capability.
Frequently asked questions
Is MAO the same as MTPD?
Organizations use terminology differently. Define the term in your methodology and map it to the concept your chosen standard or regulator uses rather than assuming acronyms are interchangeable.
Can MAO change by scenario?
Yes. Loss of a site, data corruption and supplier failure may create different consequences and workaround options. Governance should specify whether one conservative value or scenario-specific values are maintained.
Who approves it?
The accountable business owner should approve the impact conclusion through the BIA governance process, with challenge from BCM and relevant risk, compliance and dependency owners.
Use impact curves, not a single interview answer
Plot impact across agreed time bands and note when each consequence becomes unacceptable. Financial loss may rise gradually while regulatory, safety or customer impacts cross a threshold suddenly. The MAO should reflect the earliest point at which the combined consequence is no longer acceptable, not the average of several estimates.
Ask what evidence supports the threshold: service-level commitments, statutory deadlines, inventory limits, customer behavior, safety constraints or backlog capacity. This creates a defendable rationale when different stakeholders propose different values.
Link MAO to minimum service and recovery sequencing
MAO is more useful when paired with the minimum service that must exist before the boundary is reached. A service may not need full capacity immediately; it may need 25 percent capacity within six hours, 60 percent by twelve hours and normal capacity by forty-eight hours. These milestones give strategy designers something practical to build and test.
Portfolio consistency check
Compare MAO values for services sharing the same dependencies. If several services require restoration before the same database, building or supplier can recover, the portfolio contains an infeasible set of expectations. Resolve the conflict through architecture, additional capacity, alternative workarounds or explicit risk acceptance.
Assurance evidence
During exercises and tests, record when minimum service was actually achieved and compare it with the approved boundary. If the test only proves technical restart but not business processing, do not treat the MAO as validated. The evidence should show that the service can operate at the required level before unacceptable impact occurs.
Review MAO after real disruption
Incidents often reveal that impact accelerates differently from the original analysis. Compare the actual sequence of customer, regulatory, operational and financial effects with the approved assumptions. Where the observed threshold changed, update the BIA and recovery strategy rather than leaving the incident lesson disconnected from planning data.
Derive MAO from the impact curve, not from the current recovery solution
Maximum Acceptable Outage is meaningful only when it represents the point beyond which disruption can no longer be tolerated for the defined activity or service. Establish that point from impact evidence: safety consequences, missed external deadlines, customer harm, financial loss, data integrity, operational backlog, regulatory exposure and interdependent services. If the value is chosen because “IT can recover in eight hours”, the analysis has reversed the logic.
Use time bands that reflect the business. A payment or market process may have sharp cut-off times; a manufacturing process may accumulate backlog and spoilage; a customer service process may tolerate reduced capacity for a period before queues become unrecoverable. Record assumptions such as season, transaction volume, manual-workaround capacity and maximum sustainable staffing because they can materially change the outage tolerance.
Reconcile MAO with related recovery values
- Confirm that RTO is set inside the accepted outage tolerance with enough margin for uncertainty, restart and backlog recovery.
- Check whether MBCO or minimum service can be delivered before full recovery and whether that changes the practical outage tolerance.
- Compare application and supplier recovery commitments with the business requirement instead of copying them into the BIA.
- Document conflicts between related processes so one service is not assigned an MAO that depends on another service recovering later.
Approval should include the evidence used, key assumptions and the owner authorized to accept the tolerance. Revalidate the value when volumes, legal obligations, customer commitments, technology architecture or operating hours change; the number should not remain static simply because the BIA review date has not arrived.