Maximum Allowable Outage (MAO) is the longest time a service or function can remain unavailable before the impact becomes unacceptable. It is used to set recovery targets, redundancy needs, and escalation thresholds. Practitioners should align MAO with business criticality, test restoration against it, and verify that backup, failover, and manual workarounds can meet the limit.
What MAO measures in a continuity plan
Maximum Allowable Outage is not just a recovery target, it is the business tolerance boundary for a specific service or function. It answers the question: how long can this be down before the organisation can no longer accept the impact? That makes MAO a planning input for resilience design, escalation timing, and recovery sequencing rather than a purely technical metric.
Because MAO is tied to business impact, it should be set by the process owner with continuity, operations, and technology input. The most important distinction is that MAO describes the maximum acceptable interruption, while recovery targets describe what the organisation is trying to achieve operationally. Those values may align, but they are not automatically the same.
How MAO drives recovery design and escalation
MAO is used to decide what level of redundancy, failover, and procedural fallback the service needs. If the allowable outage window is short, the design has to reduce dependency on manual restoration, single sites, or slow restore paths. If the window is longer, the organisation may accept less expensive recovery options, provided the service can still be restored before the limit is reached.
The practical value of MAO is that it turns continuity planning into a time-bound decision. Teams can use it to set escalation thresholds, trigger alternate processing, and decide when to move from passive restoration to crisis management. In that sense, MAO is a control point for both operational readiness and business acceptance of disruption.
For continuity planning, NHIMG’s Business Continuity and Disaster Recovery Guide covers how MAO fits alongside business impact analysis, recovery objectives, and failover design.
What practitioners should verify before trusting MAO
MAO is only useful if it has been grounded in a real dependency map. A service may look recoverable on paper but still exceed its outage tolerance because it depends on another platform, an identity provider, a data feed, or a manual approval step that was not accounted for. The figure should therefore be tested against the slowest credible restoration path, not the ideal one.
It is also important to test the human side of recovery. A service can meet MAO only if operators know when to declare the outage, which workaround is acceptable, who owns the decision, and how to verify that the restored service is actually usable. Backup and failover capability are not enough if the handoff and validation steps are unclear.
Decision rule: If the service cannot be restored within MAO under realistic conditions, treat the design as insufficient even if the technology is nominally redundant.
Risk and Threat Considerations
MAO becomes a risk issue when the organisation assumes it can tolerate more downtime than the business actually can. That mismatch creates exposure in revenue, operations, customer commitments, regulatory obligations, and downstream services that depend on the same function.
Failure mechanism: The outage window is exceeded because recovery depends on assumptions that break under real conditions, such as a failed dependency, incomplete runbook, or restoration path that is slower than the agreed tolerance.
Impact: The service remains unavailable beyond the acceptable limit, forcing manual workarounds, business interruption, or emergency escalation before the environment is ready.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | MAO depends on access continuity and restoration readiness across recovery paths. |
| Recommendation — Review account dependencies and recovery access so the service can be restored within the outage limit. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan is Executed | MAO is a recovery planning boundary that must be validated during restoration. |
| Recommendation — Test the recovery plan against the maximum acceptable outage window. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | MAO is a continuity planning input for acceptable downtime and recovery readiness. |
| Recommendation — Define and test continuity arrangements so essential services recover before the outage limit. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | MAO informs contingency planning for restoration timing and alternate processing. |
| Recommendation — Build contingency plans that restore the service within the approved outage threshold. | ||
Practitioner Guidance
What to verify: Validate MAO against an actual restoration exercise, not just a documented target. The exercise should prove that backup restoration, failover, and manual fallback can all complete before the limit is reached, including the time needed to detect the outage and declare escalation.
Common mistake: Teams often treat MAO as a document that can be copied from one system to another. In practice, each service has a different dependency chain, operational criticality, and acceptable workaround, so reuse without revalidation is a frequent source of false confidence.
What good looks like: The continuity plan has a clearly owned MAO, a tested recovery path that fits inside it, and an escalation trigger that tells operators when the outage is no longer acceptable and intervention must move to a higher response tier.
Practitioner takeaway: MAO is most useful when it is treated as an enforced business boundary, not a planning estimate, because the real test is whether restoration, validation, and handoff can all happen before the organisation crosses that line.