A disaster recovery SLA is the contract that tells you, in writing, how fast your provider will bring systems back after an outage, how much data loss you have agreed to accept, and what you collect when the provider misses either number. Everything else in the document — exclusions, reporting, credits, caps, termination rights — exists to protect or undercut those two commitments. Negotiate them deliberately before signing, because arguing about them mid-outage is a losing position.
The Two Metrics That Anchor Everything
The Recovery Time Objective is the maximum window your systems can stay down before the provider must have them running again. NIST defines it as the length of time a system’s components can remain in the recovery phase before negatively impacting the organization’s mission.1National Institute of Standards and Technology. Computer Security Resource Center Glossary – Recovery Time Objective If the contract says four hours, then at four hours and one minute the provider has breached. Shorter RTOs drive the cost of the whole DR solution up because faster failover infrastructure is more expensive.
The Recovery Point Objective measures the maximum acceptable age of the data your provider restores. NIST frames it as the point in time, prior to a disruption, to which data must be recovered from the most recent backup.2National Institute of Standards and Technology. NIST SP 800-34 Rev. 1 Business Impact Analysis Template A one-hour RPO requires backups at least every sixty minutes. A fifteen-minute RPO pushes you toward near-continuous replication, with the price tag that implies.
Tier these numbers by system criticality rather than applying one standard across the board. A customer-facing payment platform may warrant a one-hour RTO and fifteen-minute RPO. An internal knowledge base might tolerate twenty-four hours and four hours. Tiering keeps spend proportional to real risk.
Maximum Tolerable Downtime
Behind every RTO sits a larger number: the Maximum Tolerable Downtime, the outer limit before an outage causes irreversible harm. Your RTO must stay comfortably below the MTD. If the MTD for a payment system is eight hours, an RTO of seven hours and fifty minutes leaves no room for a complication during recovery. A Business Impact Analysis calculates both figures by estimating the financial and operational damage each hour of downtime inflicts on a given system.2National Institute of Standards and Technology. NIST SP 800-34 Rev. 1 Business Impact Analysis Template Run the BIA before you negotiate the SLA. Targets set by gut feel tend to collapse under scrutiny.
Name the Systems the Provider Must Recover
Every system the provider is responsible for recovering must appear by name in the contract. “All company data” invites a dispute during the exact hours you cannot afford one. List specific servers, virtual machines, database clusters, applications, and the networks that tie them together. Use concrete identifiers: hostnames, IP addresses, serial numbers, application registry names. If a system isn’t on the list, assume the provider will argue it wasn’t covered.
The inventory also marks what sits outside scope. A provider protecting your production database has no obligation to recover a development environment unless the contract says so. Build in a formal update process for additions and decommissions, because stale asset lists are one of the most common reasons organizations discover coverage gaps in the middle of a real incident.
Uptime, Maintenance, and Exclusions
DR SLAs usually include an overall availability percentage alongside RTO and RPO. The gap between tiers is larger than it looks. A 99.9% commitment permits roughly eight hours and forty-six minutes of downtime per year. Moving to 99.99% cuts that to under an hour. Match the tier to each system’s criticality rather than defaulting to the highest number and paying for it everywhere.
Scheduled and Emergency Maintenance
Maintenance windows come out of the availability calculation, so they need firm boundaries. A typical SLA permits one scheduled window per month during off-peak hours with advance notice. Emergency maintenance for urgent security patches may also be excluded if the provider follows a defined notification procedure. Without caps on frequency and duration, maintenance becomes a loophole that eats into breach penalties.
Force Majeure and Client-Caused Failures
Exclusions define what the provider isn’t on the hook for. Force majeure covers extraordinary events like natural disasters, wars, and widespread infrastructure failures. Outages caused by your own staff, your local equipment, or third-party dependencies outside the provider’s control are also carved out. These are reasonable in principle. Watch the wording. A vague exclusion for “network issues” with no definition can be stretched to cover problems the provider should have owned.
Incident Notification and Escalation
How fast you learn about an outage determines how fast your own response kicks in. Require the provider to acknowledge a critical outage within fifteen minutes and a high-priority issue within one hour. Acknowledgment and resolution are different commitments; the SLA should set both.
Escalation timelines belong in writing. If a critical incident is not resolved within a defined period, it moves automatically to senior engineers, and then to executive contacts on both sides. Without those triggers, incidents stall at the wrong level while your downtime clock keeps running. Name the communication channel too — a dedicated phone line, a status page, or an incident platform — so you are not waiting on email during an emergency.
Testing and Validation
An untested recovery plan is a collection of good intentions. NIST recommends testing at least annually and whenever significant changes are made to the covered systems or the plan itself.3FISMA Center. NIST SP 800-34 Contingency Planning Guide for Federal Information Systems For infrastructure that changes quickly or runs high-criticality workloads, quarterly is a better baseline.
Specify which types of tests the provider will run:
- Tabletop exercises walk the team through recovery steps in a conference room without touching any systems. They are cheap and good at surfacing logical gaps — a wrong contact number, an outdated procedure. NIST recommends completing tabletops before attempting anything more involved.3FISMA Center. NIST SP 800-34 Contingency Planning Guide for Federal Information Systems
- Functional exercises simulate a real disaster. Systems actually fail over, data is actually restored, and the team confirms that everything works. This is the only way to prove the provider can hit the contracted RTO and RPO.
A provider that only ever runs tabletops has not demonstrated that recovery will work under pressure. Define what a passing result looks like: the system restored within the RTO window, recovered data within the RPO threshold, dependent applications functioning. Failed tests should trigger a documented remediation plan with a retest deadline.
Performance Reporting
You cannot enforce an SLA you cannot measure. Require monthly or quarterly reports with timestamps showing when a failure was detected, when recovery began, and when systems were fully restored. That data lets you calculate actual recovery time against the contractual RTO. Reports should also log backup frequency and the age of the most recent backup at the time of any incident, validating RPO compliance.
Nail down the report format, the monitoring tools used to generate the figures, and who has access to the raw data. If the provider controls both the monitoring and the reporting, build in audit rights or arrange independent monitoring. A gap in backup logs is evidence of a potential RPO breach even if no disaster has occurred during that gap. Reporting is the paper trail you will rely on in any dispute, so treat its requirements as seriously as the recovery metrics they document.
Service Credits When the Provider Misses
The standard remedy for a missed target is a service credit against a future bill, tiered by severity. Google Cloud’s Compute Engine SLA, for example, awards a 10% credit when monthly uptime drops below 99.99%, 25% below 99%, and 100% below 95%.4Google Cloud. Compute Engine Service Level Agreement (SLA) Most enterprise DR agreements follow a similar pattern, with the exact percentages and thresholds open to negotiation.
Credits do not arrive on their own. You usually have to file a formal claim within a set window. Google Cloud requires notification within 60 days of becoming eligible.4Google Cloud. Compute Engine Service Level Agreement (SLA) AWS requires the claim by the end of the second billing cycle after the incident, supported by logs documenting the errors.5Amazon Web Services. AWS Deadline Cloud Service Level Agreement Miss the window and the credit is gone even if the breach was obvious. Calendar the deadline the moment an incident ends.
Credits rarely cover the real cost of an outage. A 25% rebate on monthly hosting fees might be a few thousand dollars when the outage itself cost six figures in lost revenue and customer trust. Credits are a pricing adjustment that nudges the provider toward performance; they are not designed to make you whole. The provisions that actually move money at scale are liability and termination.
Liability Caps and Consequential Damages
Almost every DR SLA caps the provider’s total financial exposure, and the most common cap in negotiated IT agreements is twelve months of fees. Around 39% of deals land on that figure; roughly 30% go higher. Fewer than 4% of providers successfully push the cap below twelve months. Whatever the number, it is the maximum you can recover from the provider regardless of what the outage actually cost.
Most agreements also exclude consequential damages — lost profits, reputational harm, costs flowing through to your own customers. Under the Uniform Commercial Code, consequential damages in commercial contracts can be limited or excluded so long as the exclusion isn’t unconscionable.6Legal Information Institute. UCC 2-719 Contractual Modification or Limitation of Remedy Courts have generally upheld these exclusions between sophisticated commercial parties. The practical result: service credits address service quality, and the real financial fallout of a prolonged outage stays with you.
When Liability Caps Fall Away
Caps are not absolute. Courts in many jurisdictions refuse to enforce them when the provider’s conduct crosses certain lines:
- Gross negligence or willful misconduct. If the failure reflected reckless disregard or intentional wrongdoing rather than an accident, courts will strip the cap. Definitions vary by jurisdiction, but the principle holds: a provider that barely tried cannot hide behind a contractual ceiling.
- Fraud or bad faith. No contract shields a party from its own fraud. Misrepresentation of capabilities or bad-faith performance removes the cap entirely.
- Failure of essential purpose. When the exclusive remedy — typically service credits — becomes meaningless because the provider simply cannot perform, courts allow the injured party to pursue the full range of legal remedies. A DR provider that repeatedly fails to recover systems at all has arguably rendered the credit remedy useless.6Legal Information Institute. UCC 2-719 Contractual Modification or Limitation of Remedy
In negotiation, push for explicit carve-outs that remove the cap for data breaches caused by the provider’s negligence, confidentiality violations, and intellectual property infringement. These carve-outs are increasingly standard and give you real recourse for the harms that hit hardest.
Termination Rights for Chronic Failure
Service credits handle isolated incidents. When failures become a pattern, you need the contractual right to walk away without an early termination penalty. The standard formulation defines chronic failure as the provider missing its service levels in any three consecutive months, or in any five months within a rolling twelve-month period. Hitting either threshold triggers an unconditional right to terminate on written notice.
Without this clause, you can get stuck in a multi-year contract with a provider that underperforms consistently but never quite badly enough to support a material breach claim under general contract law. Make the trigger apply to any SLA target miss, not only RTO and RPO. Backup frequency gaps, missed reporting deadlines, and failed recovery tests should all count. Confirm that chronic-failure termination comes with transition assistance; the right to leave is hollow if the provider can hold your data or stall your migration.
Data Return and Exit
How you get your data back deserves as much attention as how it is protected during the engagement. Require the provider to return all your data in a standard, machine-readable format within a specified window after termination. Once you confirm receipt, the provider should erase every copy from its systems and any subcontractors, and certify the destruction in writing.
Egress Fees
Moving large volumes of data out of a cloud environment can trigger egress charges that mount quickly. The major cloud providers have moved toward waiving these fees at termination, with conditions. AWS provides free data transfer via credits but requires a 60-day exit period and complete removal of all data and workloads. Google Cloud offers a one-time egress waiver with a similar 60-day migration window. Microsoft Azure removes transfer fees when you cancel or delete the subscription. Address egress in the contract itself so you are not negotiating under pressure during the exit.
Starting January 12, 2027, the EU Data Act will prohibit cloud providers from charging switching or egress fees to customers in EU jurisdictions.7European Commission. Data Act Explained During the transition through that date, providers may still charge for costs directly related to switching. If your business operates in the EU or stores data with EU-based providers, the regulation may override the contract’s egress terms.
Transition Assistance Period
Include a defined transition assistance period, typically 60 to 90 days, during which the outgoing provider keeps delivering at the contracted level while you migrate. Without it, obligations end the moment the contract does, which can leave you without DR coverage mid-migration. Lock in the fee structure for transition assistance upfront. Providers sometimes quote reasonable monthly rates during the sales cycle and then charge premium rates for post-termination work, when your leverage is gone.