Maximum Tolerated Downtime: how IT recovery speed impacts trust, revenue and compliance

This series of blogs covers the impact of IT resilience and what companies can do to weather business disruption. Read the other blogs here and here.

You have recovery time objectives. You track mean-time-to-detect and mean-time-to-respond. Your teams document failover tests. You probably have disaster recovery rehearsals and hot-site simulations on the calendar. 

On paper, recovery looks sound. So why does it still feel uncomfortable when a real incident hits? Because what’s changed isn’t the importance of recovery speed. It’s how that coordination and efficacy is judged. 

You probably measure response time. But do you measure it the way you’re judged? 

Most enterprises track post-incident recovery through domain-specific metrics: 

• Cloud teams track Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). 

• Cybersecurity teams track Mean-Time-to-Detect (MTTD) and Mean-Time-to-Respond (MTTR). 

• Infrastructure teams track uptime, SLA adherence and failover test results. 

Individually, those metrics are sensible. They align to technical responsibilities and supplier management. They often map into your risk register and reporting framework, and should all be translatable to an overall metric – MTD, or Maximum Tolerated Downtime. 

The challenge is not that these metrics are wrong, but that boards and regulators assess recovery end-to-end. 

They don’t ask whether cloud hit its RTO while security was still containing. They don’t care if your infrastructure team met their uptime SLA while business services remained offline. They look at the full range of impact on customers, revenue and business continuity. 

For regulated financial services firms in the UK, this distinction is formalised. Under the Financial Conduct Authority’s Operational Resilience framework, firms must define impact tolerances for important business services, the maximum level of disruption that can be tolerated before harm becomes unacceptable. 

Recovery time objectives are expected to sit well within those declared tolerances. 

That requirement applies specifically to FCA-regulated firms. But the underlying principle is broader. Whether you are regulated by the FCA or not, the concept is the same: recovery is not judged at the level of infrastructure. It is judged at the level of business service and real-world impact. 

In financial services, that expectation is codified in regulation. In other sectors, it is increasingly embedded in board oversight, audit scrutiny and customer expectation.

The FCA itself has noted that impact tolerances are often primarily time-based and should be complemented with additional metrics such as customer impact, transaction values and potential losses. 

In other words, recovery is no longer judged solely on whether you restored a particular technology within an SLA. It is judged on whether you remained within business-level tolerances. 

Speed is necessary. It is no longer sufficient. 

Let’s be clear. Speed still matters. 

The Information Commissioner’s Office requires organisations to report certain personal data breaches within 72 hours of becoming aware of them. Regulators do consider response timeliness when assessing enforcement outcomes. 

But speed without clarity or coordination can create new problems. 

Restoring a system quickly without understanding dependencies can reintroduce security vulnerabilities. Containing a threat aggressively without considering business continuity can prolong downtime. Declaring “service restored” before you’ve validated its integrity and stability can leave you technically back online but still vulnerable to repeat failure. 

Recovery speed is judged alongside: 

• Real-world impact on customers or users