Skip to main content
Control Institute
Category: Business Continuity

Maximum Tolerable Downtime

Also known as: MTD, Maximum Allowable Downtime, MAD
Simply put

Maximum Tolerable Downtime (MTD) is the longest period that a critical business function or system can be unavailable before the disruption causes significant harm to the organization. It represents the outer limit of acceptable outage that the organization is willing to tolerate. Beyond this threshold, the impact on the mission or business process is considered severe.

Formal definition

MTD is the total duration a mission or business process can be disrupted or a system can remain inoperable before causing significant or severe harm to the organization, as determined and accepted by the system owner or authorizing official. In continuity planning it typically serves as an upper boundary against which related recovery objectives are aligned; for example, the combined Recovery Time Objectives (RTOs) of dependent components should not exceed the MTD of the overall process. The specific value is set through business impact analysis and scoping decisions and varies by process, organization, and criticality.

Why it matters

Maximum Tolerable Downtime establishes the outer boundary of acceptable disruption for a critical business function or system, giving continuity planners a hard reference point against which all recovery efforts must be measured. Without a defined MTD, an organization has no objective way to determine whether its recovery capabilities are adequate or whether a given outage has crossed from manageable inconvenience into severe, mission-threatening harm. The value anchors the design of disaster recovery and business continuity strategies, and it forces leadership to make explicit decisions about how much downtime the organization is genuinely willing to accept.

MTD also plays a governing role in relation to other recovery metrics. Because it represents the total tolerable outage for an overall process, the combined Recovery Time Objectives of dependent components should not exceed it; for example, where an MTD is set at a given number of hours, the RTOs of the systems supporting that process must together fit within that window. When recovery objectives drift beyond the MTD, it signals that the recovery architecture cannot restore operations before significant harm occurs, prompting reassessment of resources, redundancy, or scope.

In a compliance context, MTD supports the business continuity and disaster recovery expectations that appear in frameworks such as SOC 2 and ISO 27001. Auditors and certification bodies often look for evidence that recovery objectives are grounded in a business impact analysis rather than assumed, and a documented MTD demonstrates that the organization has deliberately reasoned about the consequences of prolonged unavailability. The specific threshold is determined through scoping decisions and accepted by the system owner or authorizing official, so it should be treated as an organization-specific parameter rather than a universal figure.

Who it's relevant to

Business Continuity and Disaster Recovery Planners
BCDR planners use MTD as the anchoring metric for continuity strategies, defining it through business impact analysis and ensuring that recovery objectives for dependent systems are aligned beneath it. It gives them a defensible basis for prioritizing recovery resources across processes of differing criticality.
Compliance and GRC Professionals
Those preparing for a SOC 2 examination or an ISO 27001 certification rely on documented MTDs to demonstrate that recovery objectives are grounded in analysis rather than assumption. A clearly reasoned and accepted MTD helps evidence the business continuity considerations that auditors and certification bodies typically look for, though the specific value and its adequacy depend on the organization's scope.
System Owners and Authorizing Officials
MTD is ultimately set and accepted by the system owner or authorizing official, who formally acknowledges the total outage duration the organization is willing to tolerate for a given process. This makes them accountable for ensuring that the recovery capability in place is consistent with the accepted threshold.
Security and Infrastructure Engineers
Engineers responsible for recovery architecture translate MTD constraints into concrete Recovery Time Objectives and redundancy designs, ensuring that the combined recovery time of dependent components does not exceed the MTD for the overall process. Where it does, they revisit the design to close the gap.

Inside MTD

Maximum Tolerable Downtime (MTD)
The longest period a business process or service can remain unavailable before the resulting harm to the organization becomes unacceptable. It represents an upper limit on outage duration and is typically established through business impact analysis rather than a single technical measurement.
Recovery Time Objective (RTO)
The targeted duration within which a process or system should be restored following a disruption. RTO is set to fall within the MTD so that recovery completes before the tolerable threshold is exceeded; the gap between RTO and MTD typically accommodates activities such as damage assessment and switchover.
Recovery Point Objective (RPO)
The maximum acceptable amount of data loss measured as a period of time, indicating how current recovered data must be. RPO addresses data currency and is distinct from MTD and RTO, which address downtime duration.
Business Impact Analysis (BIA) linkage
MTD is typically derived from a BIA that evaluates the operational, financial, reputational, and regulatory consequences of a process being unavailable over time. The tolerability threshold depends on scoping and organizational context rather than a universal figure.
Availability considerations
Where the Availability category of the Trust Services Criteria is in scope for a SOC 2 examination, or where availability-related controls are selected in an ISO 27001 ISMS, MTD-related recovery objectives can inform the controls an organization designs. Availability is optional under SOC 2 and any specific control selection under ISO 27001 depends on the Statement of Applicability and risk assessment.

Common questions

Answers to the questions practitioners most commonly ask about MTD.

Is Maximum Tolerable Downtime a mandatory metric required by SOC 2 or ISO 27001?
Neither framework prescribes MTD as a universally mandatory metric by that name. MTD is a business continuity and resilience concept that organizations may use to inform their controls. Under SOC 2, if Availability is included in scope, an auditor typically evaluates whether the controls the organization designed to meet its own recovery objectives operate as described, but the specific metric and its threshold are set by the organization's scoping decisions rather than dictated by the AICPA criteria. Under ISO 27001, the ISMS requirements in clauses 4 through 10 and the reference controls in Annex A may address business continuity, but the standard does not impose a fixed MTD value. In most engagements, whether and how MTD is used depends on the organization's risk assessment and defined scope.
Does having a defined Maximum Tolerable Downtime guarantee that a service will never exceed it during an outage?
No. MTD is a planning threshold that expresses the longest interruption an organization judges it can tolerate before consequences become unacceptable; it is not a guarantee of actual performance. A SOC 2 report attests only to the design, and for a Type II report the operating effectiveness, of the controls over the period covered, and it does not guarantee freedom from breaches or outages. Similarly, an ISO 27001 certificate covers only the defined scope of the ISMS and does not warrant that recovery will always occur within any stated target. Actual recovery outcomes depend on the incident, the controls in place, and how they perform in practice.
How does MTD relate to Recovery Time Objective (RTO) when defining recovery capabilities?
MTD typically represents the outer boundary of acceptable disruption, while RTO is generally set as a target that falls within that boundary, leaving room for activities that may occur after systems are technically restored. In most implementations, organizations derive RTO and related recovery parameters so that they remain shorter than the MTD. The exact relationship, values, and terminology depend on the organization's business impact analysis and scoping decisions, so these figures vary between organizations and engagements.
How can MTD be documented so it supports a SOC 2 examination?
If Availability is within the SOC 2 scope, organizations typically document how MTD and related recovery objectives were determined, the controls intended to meet them, and evidence that those controls operate as described. For a Type I report, the focus is on the suitability of the design of these controls at a point in time; for a Type II report, the auditor also assesses operating effectiveness over the defined review period, the length of which varies by scoping. Clear documentation linking the objective to specific controls and to supporting evidence generally helps demonstrate alignment during the examination.
Where does MTD fit within an ISO 27001 ISMS?
Within an ISO 27001 ISMS, recovery objectives such as MTD are typically informed by the risk assessment and the organization's business continuity considerations. The certifiable requirements are in clauses 4 through 10, while Annex A provides reference controls that are selected through the Statement of Applicability based on risk. Any control that addresses continuity or recovery would be included only if the organization determined it applicable. Whether MTD is explicitly used, and how it is expressed, depends on the organization's scope and risk decisions.
Can a single MTD value be applied across an entire organization?
In most engagements, a single organization-wide MTD is uncommon because different systems, services, and processes usually have different tolerances for disruption. Organizations typically derive distinct MTD values from a business impact analysis for each critical function or asset, depending on scope. The appropriate granularity is a scoping decision, and the resulting values vary by organization, so applying one uniform figure everywhere is generally not advisable unless the organization's analysis specifically supports it.

Common misconceptions

MTD is a fixed, standardized value defined by SOC 2 or ISO 27001.
Neither framework prescribes a specific MTD value. MTD is determined by the organization based on business impact analysis and scoping decisions, and it varies by process, service, and organizational context.
MTD and RTO are the same thing.
They are related but distinct. MTD is the maximum outage a process can tolerate before harm becomes unacceptable, while RTO is the recovery target set to complete within the MTD. RTO is typically shorter than MTD to allow time for detection, assessment, and switchover.
Meeting a defined MTD through recovery controls guarantees continuous availability or protection from disruption.
A defined MTD and its supporting controls address planning and recovery objectives, not a guarantee of outcomes. A SOC 2 report attests only to the controls and period covered, and an ISO 27001 certificate covers only the defined ISMS scope; neither guarantees freedom from disruptions or breaches.

Best practices

Derive MTD from a documented business impact analysis that evaluates operational, financial, reputational, and regulatory consequences over time, rather than assigning arbitrary values.
Set RTO to fall within the MTD, leaving sufficient margin for detection, damage assessment, and switchover activities, and define RPO separately to address acceptable data loss.
Document MTD assumptions and the scope they apply to, since tolerable thresholds typically vary by process and depend on scoping decisions.
Where the Availability category is in scope for a SOC 2 examination, align recovery-related controls with the defined MTD and RTO so evidence supports the criteria being assessed.
For ISO 27001, reflect recovery objectives in the risk assessment and Statement of Applicability where relevant, recognizing that specific control selection depends on the ISMS scope and identified risks.
Periodically review and test recovery capabilities against the MTD, and update the objectives as business processes, dependencies, or impact tolerances change.