Disaster Recovery Clause
Definition
Disaster Recovery Clause
A disaster recovery clause sets out how quickly a provider must restore systems and data after a defined disaster, and how much data loss is acceptable in the process. Two numbers carry the clause — recovery time and recovery point.
Everything else in the clause supports those two figures. The strategy, the infrastructure, the testing regime and the cost all follow from how fast you need to be back and how much you can afford to lose.
Buyers routinely ask for numbers they have not costed. Near-zero recovery time and near-zero data loss are technically achievable and priced accordingly, which is usually discovered after the requirement has been written down.
A disaster recovery clause without a testing obligation is a statement of intent. Untested recovery fails at the moment it is needed, and the failure is discovered by customers rather than by engineers.
Key takeaways
- Recovery time objective (RTO) sets the maximum acceptable downtime after a disaster.
- Recovery point objective (RPO) sets the maximum acceptable data loss.
- Cost rises steeply as both figures approach zero, so they must be justified per service.
- Regular invocation testing is what turns a documented capability into a real one.
How it works
The contract defines what counts as a disaster, states the recovery objectives for each service, describes the recovery approach, and sets a testing frequency with evidence obligations and a route for declaring invocation.
The two objectives have settled definitions. Microsoft defines recovery point objective as “the maximum duration of acceptable data loss in the event of a disaster”, measured in units of time.
Recovery time is its counterpart, defined as “the maximum duration of acceptable downtime in the event of a disaster” — again in time, not in percentages.
| Recovery strategy | Relative cost | Recovery speed |
|---|---|---|
| Backup and restore | Lowest | Slowest |
| Pilot light | Low | Faster, needs activation first |
| Warm standby | Higher | Fast, scaled-down capacity available |
| Multi-site active/active | Highest | Near immediate for most disasters |
Amazon’s guidance draws the line between the two middle options precisely, noting that “pilot light cannot process requests without additional action taken first, whereas warm standby can handle traffic (at reduced capacity levels) immediately”.
The same guidance is direct about the testing obligation, warning that a strategy must be regularly assessed and tested so that a buyer has confidence in invoking it when it becomes necessary.
Examples
Recovery objectives should differ by service, and contracts that apply one figure to everything overpay in one place and underprotect in another. Four cases show the spread.
A bank sets a fifteen-minute recovery point for payments and a four-hour one for internal reporting. The cost lands where the risk actually sits.
A retailer specifies near-zero objectives across every system in scope. The price comes back at three times the budget and the requirement is rewritten.
An insurer tests failover twice a year with the buyer observing. The second test overruns its stated recovery time and the gap is fixed before a real event.
A logistics firm documents strong objectives and never tests them. A regional outage takes eleven hours to recover against a stated four-hour commitment.
Related terms
Resilience terms cover keeping a service running, restoring it afterwards and excusing failure altogether. The entries below separate the three and the capabilities behind them.
- Business continuity plan (BCP): the wider plan that keeps the business operating while systems are down.
- Data center outsourcing: the infrastructure arrangements recovery objectives depend on.
- Redundancy: the duplicated capability that makes fast recovery possible at all.
- System availability rate: the day-to-day uptime measure, distinct from disaster recovery.
- Cybersecurity outsourcing: the controls addressing ransomware, now a leading disaster scenario.
- Private cloud outsourcing: a hosting model with its own recovery characteristics.
- NIST Cybersecurity Framework: the framework whose recover function these clauses operationalise.
FAQ
How is this different from a business continuity clause?
A business continuity clause keeps the service running through disruption, including manually. A disaster recovery clause restores systems and data afterwards, measured by recovery time and recovery point.
How are RTO and RPO agreed?
Service by service, from the business impact of downtime and of data loss. Applying one pair of figures across every system is the commonest and most expensive mistake.
Why does near-zero recovery cost so much?
Because it requires duplicated, continuously running capacity rather than something activated on demand. The price tracks the standby capability, not the disaster.
How often should recovery be tested?
At least annually, and twice yearly for critical services. Tests should be observed by the buyer and should measure against the contracted objectives.
Does a disaster recovery clause cover ransomware?
Only if the definition of disaster includes it. Many older clauses contemplate physical events, and data corruption needs its own recovery path from clean backups.
What if the provider misses its recovery objective?
The consequence is whatever the contract specifies, usually service credits and, after repeated failures, a termination right. Clauses with no consequence change nothing.
Learn how outsourcing contracts handle service resilience at Outsource Accelerator.
Independent
