The Disaster Recovery Clause: What It Means and How to Negotiate It (2026)

What is a disaster recovery clause? A disaster recovery clause requires a supplier, usually of IT, cloud or outsourced services, to maintain and test a plan to restore the service after a disruptive event such as a data-centre failure, a cyber attack or data loss. Its core is two numbers: how quickly the service will be back (the recovery time objective, or RTO) and how much data can be lost in the process (the recovery point objective, or RPO). You see this clause in cloud and hosting contracts, software and managed-services agreements, and any deal where the customer depends on the supplier's systems to run its own business. It matters because when something breaks, the clause is the only thing that turns a vague promise of "resilience" into measurable, enforceable recovery targets. This article is general guidance, not legal advice. Resilience obligations are mandated by sector regulators in some industries, and those rules vary by jurisdiction, so have a qualified professional adapt any clause to your deal and your regulatory position. ## What a disaster recovery clause actually does A clear clause settles five things: 1. The plan. A documented disaster recovery plan the supplier must maintain.

2. The targets. The RTO (how fast service is restored) and the RPO (how much data may be lost).
3. Testing. How often the plan is tested and what evidence the customer gets.
4. Invocation. When the supplier must trigger the plan and how it keeps the customer informed.
5. Force majeure interplay. Whether the duty still applies when the disaster is also a force majeure event, which it usually should. ## Sample disaster recovery clause wording Use this as a starting point, not a finished clause. Adapt the brackets to your deal. ``` DISASTER RECOVERY 1. DR Plan. The Supplier shall maintain and keep current a documented disaster recovery plan (the "DR Plan") designed to restore the Services after a Disaster (a loss of the primary processing environment). 2. Targets. The DR Plan shall meet the following targets for the Services: Recovery Time Objective (RTO): [N] hours. Recovery Point Objective (RPO): [N] hours (maximum data loss). 3. Resilience. The Supplier shall replicate data to a geographically separate site and shall not have a single point of failure for the Services. 4. Testing. The Supplier shall test the DR Plan at least [annually], provide the Customer a summary of results within [N] days, and remediate any material failure. 5. Invocation. On a Disaster the Supplier shall invoke the DR Plan without undue delay, keep the Customer informed, and use the DR Plan to mitigate even where the Disaster is also a Force Majeure event.

- **Resilience (clause 3).** Geographic separation of the backup site matters, both for resilience and for data residency. A backup in the same building as the primary is barely a backup.
- **Testing (clause 4).** A plan that is never tested is a document, not a capability. Require regular tests and the right to see the results, and ideally to witness or audit a test.
- **Invocation and force majeure (clause 5).** This is the trap. If a disaster is also treated as force majeure that excuses performance, the recovery duty can evaporate exactly when it is needed. Say that the DR obligations survive and must be used to mitigate. ## Negotiation points **If you are the customer:** - Set RTO and RPO against your real tolerance for downtime and data loss, and attach credits or a termination right if they are missed.
- Require regular testing with shared results, and a right to witness or audit a test.
- Make clear the DR duty is not excused by force majeure; the whole point is to recover from disasters.
- Pin down where the backup site is, for both resilience and data residency. **If you are the supplier:** - Offer achievable RTO and RPO targets you can actually meet, and tier them by service criticality.
- Keep testing proportionate and define what a material failure is.
- Be clear about the customer's own dependencies, since recovery can depend on the customer restoring its side.
- Separate genuine force majeure (such as a regional catastrophe) from ordinary failures the DR plan must cover. ## Common mistakes to avoid - No RTO or RPO numbers, leaving "recovery" undefined and unenforceable.
- A plan that is never tested, or tested with no evidence shared.
- Letting force majeure excuse the recovery duty, which defeats the purpose of the clause.
- Ignoring where backup data sits, creating a data-residency problem.
- Confusing disaster recovery with business continuity, and covering only the IT restore while the wider operation is left out. ## A note on jurisdiction Disaster recovery is mostly a contractual matter, but in regulated sectors it is reinforced by rules that vary by jurisdiction. In financial services, operational resilience and outsourcing rules often require firms to ensure their critical suppliers can recover: in India, the Reserve Bank of India has issued outsourcing and IT governance directions; in the EU, the Digital Operational Resilience Act (DORA) sets requirements for ICT risk and third-party resilience; in the UK, the FCA and PRA have operational resilience rules. The widely used management standard for IT service continuity is ISO/IEC 27031, and ISO 22301 covers business continuity more broadly; these are standards, not laws, but contracts often reference them. If you are in a regulated sector, align the clause with your regulator's expectations, and get local advice. Last verified October 2026. ## Keeping recovery promises real over the life of a contract Agreeing RTO and RPO once is the easy part. The hard part is making sure the supplier actually tests the plan each year, that you receive and review the results, that the backup site still meets your residency needs, and that you can find the recovery targets fast when a system is down at 3am. The idea worth taking from this is that drafting, reviewing, tracking and governing disaster recovery terms can live in one AI workspace tuned to your company, where a recovery duty quietly excused by force majeure is flagged and the obligations and dates, including annual test dates, sit in one live view rather than several disconnected places. A tool like [Adira](https://adiralaw.com) gathers recovery targets and test dates in one place. This guide alone is enough to negotiate a fair disaster recovery clause; a workspace simply keeps the targets and the test evidence findable when you need them.