Your Vendor Says Backups Are Covered. Which Document Says They Were Tested?

The sentence that causes the most trouble in a vendor contract is the one that says data is backed up. It is almost always true and almost never sufficient, because it describes an activity the provider performs for its own continuity rather than a service it performs for yours. Providers replicate to survive hardware failure, data center loss and their own bad deploys. Restoring one customer's mailbox, one deleted project, one table a contractor truncated at eleven at night is a different operation with different tooling, different access rules and, frequently, a different answer about whether it is available at all.

Three places the second copy can live, and what each one is actually promising

Native retention inside the platform is the cheapest option because it is already paid for. It also tends to be defined in the provider's terms as a convenience rather than an obligation, with windows quoted in round numbers, thirty days, ninety days, a year, that should prompt a question about where the figure came from. Ask whether the clock starts at deletion, at the end of a billing cycle, or at some internal garbage collection pass, because those are not the same date. Ask, too, whether an account closed for nonpayment keeps its retention window or loses it immediately.

A third-party backup service that connects through the platform's API sits in the middle. It gives you a copy outside the provider's administrative boundary, which is the part that matters when the failure mode is a compromised admin credential rather than a disk. Its weakness is coverage: APIs expose some object types and not others, and the gap is usually in the unglamorous places, permissions, sharing links, workflow configuration, audit history. Those are the items that make a restored dataset usable rather than merely present, and vendors rarely list what they cannot reach.

The third option is a copy you hold yourself, in storage you control, written by an export job you wrote. It is the most work and the most honest, because nothing about it can be assumed. You know the format, you know the schedule, and you discover quickly whether anyone on staff can read the export without the original application. Larger organizations usually end up running two of the three rather than choosing, with native retention handling routine user error and an independent copy handling the scenarios where the provider itself is the problem.

The standards that give the question teeth

Contingency planning is a recognized control family rather than a matter of local preference. The National Institute of Standards and Technology is responsible for the federal information security control catalogs and the contingency planning guidance that most private-sector programs borrow from, and those controls separate backup from testing deliberately: taking a copy and proving the copy restores are two distinct obligations, assessed separately. That separation is the single most useful thing to carry into a vendor conversation, because a provider can answer the first question honestly while having nothing at all to show on the second.

In sectors with their own rules, the obligation sits closer to the surface. Health care contingency planning requirements name data backup, disaster recovery and emergency mode operation as separate plans, and they apply to the covered entity, not only to the vendor holding the records. Financial institutions are examined on resilience testing. Public companies answer for material incidents. In each case the regulator's interest is in what you can demonstrate, which is why a SOC 2 Type II report naming backup and restoration in scope is worth more to you than a marketing page, and why the exceptions section of that report is the part to read first.

What a tested restore looks like when the estate is large

Full-scale restores of everything are rare for good reason: they are expensive, they consume the same engineers who would handle a real incident, and they are often not representative anyway. What mature programs do instead is sample. Pick a system, pick a date in the middle of the retention window rather than yesterday, and restore to an isolated environment with someone from the business present to confirm the data is correct rather than merely nonempty. Record the elapsed time, the person who performed it, the tooling gaps found, and the ticket opened for each one.

Recovery point and recovery time objectives deserve the same scrutiny as the retention figure. An RPO of fifteen minutes stated in a contract usually describes replication lag between the provider's own sites, not the age of the copy you would be handed after a logical corruption that replicated cleanly in both directions. The useful number is the one your own test produced, and it is reasonable to report it as a range: a small database came back in under an hour on two attempts, a large one took most of a shift, and the variance itself is the finding.

Writing the requirement into the agreement

Procurement leverage is highest before signature and roughly zero after. What belongs in the contract is narrow and achievable: a defined retention window with a defined start event, a commitment to restore at customer request within a stated period, an annual restore test with results shared, and notice before the provider changes any of it. Add a data export right that survives termination, with a format named. Providers that already run disciplined programs agree to this language quickly, which makes the negotiation itself a diagnostic worth running early.

The organizations that come through a bad week well are rarely the ones with the most copies. They are the ones that know, from a dated record rather than an assumption, how long the restore took and who did it.