A 99.9% uptime SLA sounds reassuring until you do the arithmetic: that figure permits just under nine hours of unplanned downtime across a full year. What it does not tell you is how long any single outage lasts, how quickly your provider is contractually obliged to restore your systems, or whether “restored” means your data is intact. For organisations in finance, healthcare, and energy, those omissions are not fine print. They are the gap between a recoverable incident and a regulatory breach.
The distinction between uptime guarantees and actual recoverability has moved from procurement detail to board agenda, driven by obligations that treat recovery time as a hard metric rather than a vendor aspiration. Understanding what your SLA actually covers, and what it deliberately leaves out, is the starting point.
What uptime SLAs actually measure
Uptime is an aggregate: the percentage of total hours in a period during which a service was nominally available. A 99.9% guarantee allows roughly 8.7 hours of downtime per year; 99.99% tightens that to around 52 minutes. Both figures are calculated across the measurement window, which means a single six-hour outage can be absorbed inside a 99.9% SLA without triggering any penalty at all.
The structural problem is that uptime says nothing about any individual event. It does not specify how quickly the provider must begin responding, how long restoration may take, or what state your data is in when the service comes back. A provider can meet its uptime commitment while leaving you dark for hours on end, as long as the annual aggregate stays above the threshold.
SLA exclusion clauses compound this. Most managed service agreements carve out scheduled maintenance windows, incidents attributed to the customer’s own configuration, third-party network failures, and force majeure events. Each exclusion shrinks the denominator of hours the provider is actually accountable for, often without the customer realising how much coverage has been stripped away.
RTO vs uptime SLA: a different question entirely
A Recovery Time Objective defines the maximum acceptable duration between a disruption and full restoration of a named function. It is a commitment about a specific incident, not an annual average. An uptime SLA and an RTO can coexist in a contract, but they answer completely different questions, and a provider who offers only the former is not answering the one that matters most when something goes wrong.
Uptime tells you how often a system is available. RTO tells you how quickly it comes back. Conflating the two is how organisations discover, mid-incident, that their SLA covered the wrong metric.
The same logic applies to Recovery Point Objectives. An RPO defines how much data loss is tolerable: the maximum age of the backup that can be used to restore a system. Without an explicit RPO in the contract, a provider may restore from a backup that is 24 hours old and remain fully compliant with every SLA term, even as your transactional data disappears.
Why regulators have stopped treating this as optional
DORA, Regulation (EU) 2022/2554, makes the RTO and RPO conversation legally mandatory for financial entities. Article 12(6) requires that recovery time and recovery point objectives be set and documented for each function, distinguishing between critical and non-critical workloads. The RTS on ICT Risk Management (2024/1774) extends this to require recovery strategies for multiple failure scenarios, including cyberattack and technical failure, and mandates annual testing of continuity plans against realistic scenarios. DORA has applied to all covered financial entities since 17 January 2025.
Critically, Articles 28 through 30 of DORA establish that outsourcing to a managed service provider does not transfer regulatory accountability. Financial entities remain fully responsible for compliance even when the infrastructure sits with a third party. That means the RTO your provider informally promises, but does not contractually commit to, offers you no regulatory protection at all. Your contracts with ICT third parties must include explicit SLAs covering performance standards, incident management, and business continuity provisions.
NIS2, Directive (EU) 2022/2555, applies the same logic more broadly. Article 21(2)(c) requires business continuity measures including backup management and disaster recovery, and the directive places accountability explicitly at board level. Senior management is directly responsible for the creation, implementation, and oversight of continuity and recovery plans. Penalties for essential entities reach €10 million or 2% of global turnover. NIS2 does not prescribe universal numeric RTO thresholds the way DORA does for finance, but the obligation to define, document, and test recovery capabilities is equally binding, and plans must be reviewed at least every two years or after significant incidents.
The cloud recovery time objective in practice
When evaluating a managed service for workloads that carry regulatory weight, the questions to ask are more specific than “what is your uptime SLA?” They include: what is the contractually committed RTO for this service tier, per function? What is the RPO, and what backup frequency does it imply? How are exclusion clauses defined, and does a cyberattack qualify as force majeure? What does the provider’s incident response process look like, and at what point does escalation to your team begin?
For bare metal workloads, the hardware replacement timeline is part of the RTO calculation. If a node fails and a spare takes four hours to provision, that four hours belongs in your recovery planning whether or not the provider’s SLA acknowledges it. For managed database services, the RPO depends entirely on how frequently snapshots are taken and where they are stored. A managed MongoDB instance with daily snapshots stored in a single region carries a very different risk profile from one with continuous replication to a geographically separate site.
We operate managed MongoDB and managed Redis across our infrastructure with explicit backup cadences and documented recovery procedures, because our customers in finance and energy cannot treat those details as assumptions. The SLA they sign covers uptime; the recovery conversation happens before the contract is signed, not after an incident.
What a contract should actually contain
A managed service agreement that takes cloud recovery time objective seriously will include: a defined RTO per service tier or function category, not a single figure applied across the entire estate; a defined RPO with the backup frequency and retention policy that supports it; explicit incident response timelines, including the point at which the provider notifies the customer and the escalation path beyond that; clarity on which failure scenarios are excluded from SLA calculations and whether cyberattacks are treated differently from hardware failures; and audit rights that allow you to verify that recovery procedures have actually been tested.
The 24-hour incident notification requirement under NIS2 means that while your technical team is working on restoration, someone else must be filing regulatory notifications. That handoff needs to be defined in the contract, not improvised during the incident. Managed services incident response provisions that stop at “we will restore the service” leave the regulatory reporting burden entirely with you, often at the worst possible moment.
The board conversation that procurement keeps deferring
Under both DORA and NIS2, the accountability for recovery planning sits with senior management, not with the procurement team that signed the original managed service contract. That means the gap between an uptime SLA and a genuine recovery commitment is ultimately a board-level risk, even if it was created by a line item in a vendor agreement.
The practical implication is straightforward: review every managed service contract against the RTO and RPO your organisation has actually documented for each function. Where the contract is silent on recovery, that silence is a risk position, and it is one your regulators will not accept on your behalf. Uptime is a baseline. Recovery is the obligation.
