Resilience terms have become standard in enterprise software contracts. A security schedule states a recovery time objective of four hours and a recovery point objective of fifteen minutes, both parties sign, and the terms are filed. Several years later a provider has a significant outage, recovery takes considerably longer, and the customer discovers that the clause gave them a number and nothing else.
The gap between a stated objective and an enforceable commitment is wider than it looks. Was the objective measured from the start of the incident, from the vendor's declaration of a disaster, or from the decision to invoke failover? Did the clause apply to a regional cloud failure, or only to events at the vendor's own facilities? Was the vendor obliged to test, and if a test failed, was it obliged to tell anyone? What is the remedy, and is it anything beyond a service credit calculated on monthly fees?
These are drafting questions with operational answers. Getting them right costs very little at negotiation and is nearly impossible to fix afterwards.
What a usable recovery clause contains
Five elements separate a clause that can be relied on from one that states a number. Most contracts contain the first and omit several of the rest.
- The objectives themselves, the recovery time and recovery point objectives, stated per service or tier rather than as a single figure covering a diverse product set
- Scope of covered events, which categories of disruption the objectives apply to, including whether a failure at an underlying cloud provider or a subprocessor is in or out of scope
- Measurement definition, when the clock starts, what constitutes recovery, and whether degraded service counts as recovered, which is where most disputes actually land
- Testing and notification, the frequency and type of recovery testing, the obligation to provide results and remediation plans, and the duty to notify the customer of an invocation, a failed test or a material change to the recovery architecture
- Remedy for failure, what the customer is entitled to when objectives are missed, including whether it rises to a termination right for repeated or severe failure
These terms sit alongside the rest of the vendor's security and continuity schedule, and in a portfolio of any size they can only be managed as structured fields. The inventory discipline in the IT leader’s guide to SaaS vendor contract sprawl is the prerequisite, because recovery terms cannot be compared across a portfolio nobody has catalogued.
Availability service credits are typically calculated as a percentage of monthly fees and capped well below the cost of a prolonged outage. A clause that offers only credits for a recovery objective failure has priced the vendor's risk at a small fraction of the customer's exposure, which is worth knowing before the event rather than after.
Recording recovery terms so they can be used
The point of recording these terms is to answer two questions quickly: what did we agree with this vendor, and what evidence do we hold that it is true.
- Objectives per service and tier. Hold the RTO and RPO against the specific service, since a vendor with multiple products will often have materially different recovery profiles and a single contract figure obscures that
- Last test date and outcome. Record when recovery was last tested, what type of test it was and whether it passed. A commitment with no test evidence inside the last year should be treated as unverified
- Subprocessor and region dependencies. Note the underlying infrastructure and critical subprocessors, because the vendor's recovery objective cannot be better than theirs and this is the most common unexamined assumption
- Remedy and escalation path. Capture the remedy, any termination right and the notification contacts, so that during an incident the contractual position is a lookup rather than a research task
- Mapping to internal recovery requirements. Record the business recovery requirement for the process the service supports beside the contracted objective. Where the contracted figure is weaker, that is a risk acceptance somebody should have made explicitly
A five-step way to get this under control
Step 1, Rank services by business impact
Start from the processes that cannot tolerate interruption rather than from the vendor list. Most portfolios have a small number of services where recovery genuinely matters and a long tail where it does not.
Step 2, Extract the recovery terms for that set
Pull objectives, scope, measurement, testing and remedy provisions into structured fields. Extraction across a security schedule is straightforward; the work is in reading what is absent as carefully as what is present.
Step 3, Compare contracted against required
Place the contracted objective beside the internal recovery requirement for each critical service. The gaps are the agenda, and they are usually concentrated in a handful of vendors.
Step 4, Request current test evidence
Ask the critical vendors for their most recent recovery test results and remediation status. The response, including how long it takes, is itself a useful signal about the maturity of the vendor's programme.
Step 5, Fix the clause at renewal, prioritised by gap
Take the testing obligation, measurement definition and remedy into the next renewal for the vendors with the largest gaps. These are rarely contentious asks when raised at renewal, and nearly impossible to add mid-term.
Resilience terms you can actually check
Aavenir holds recovery objectives, test obligations and remedies as structured fields across the vendor portfolio.
The subprocessor problem
A vendor's recovery commitment is bounded by the recovery capability of everything it depends on. A software provider running on a single cloud region, with a critical identity provider and a payments subprocessor, cannot credibly recover faster than the slowest of those dependencies in a scenario that affects them. Most recovery clauses are silent on this, and most customers do not ask. The consequence appears during regional cloud incidents, where several nominally independent vendors fail simultaneously and recover on the underlying provider's timeline rather than their own. Addressing this contractually is modest: require disclosure of the regions and critical subprocessors the service depends on, require notification when they change, and make clear whether the recovery objectives apply to failures originating with those dependencies. That last point is the one vendors will negotiate hardest, and the answer, whichever way it goes, is worth having in writing rather than discovering during an incident. Recording concentration across the portfolio then shows how many critical services share a single point of failure, which is a question the clause alone cannot answer.
Clause elements and what their absence means
Reading a recovery clause is largely an exercise in noticing omissions. The table sets out what each missing element costs in practice.
| Element | If present | If absent | Priority to fix |
|---|---|---|---|
| Measurement start point | Objective is verifiable | Dispute over when the clock started | High |
| Scope of covered events | Clear whether cloud failure counts | Vendor argues exclusion after the fact | High |
| Testing obligation | Evidence exists annually | Commitment is untested and unverifiable | High |
| Failed test notification | Problems surface early | Customer learns during a real event | Medium |
| Remedy beyond credits | Meaningful consequence | Exposure priced at monthly fees | Medium |
Recovery objectives are among the easiest contract terms to agree and the hardest to rely on, because the number is the part everyone negotiates and the measurement, testing and remedy are the parts that decide whether it holds. Recording the full set as fields, comparing contracted against required, and asking for test evidence annually turns a line in a schedule into something an organization can plan around. Our deal desk guide covers getting these terms agreed without slowing the deal.
For related guidance, see Auto-renewal clause risk in enterprise SaaS contracts, Open source license clauses in customer contracts and Capacity reservation clauses in semiconductor supply deals.
