Do Not Renew Backup Until You Have Restore Evidence
A green backup dashboard can be telling the truth and still give you the wrong answer.
It may prove that jobs ran, data moved, retention policies applied, and storage stayed available. Good. You need all of that.
It does not prove that a critical system can be restored within the time the business expects. It does not prove that the restored data is usable. It does not prove that your team and provider know who does what when production is down.
That is the decision hiding inside your next backup renewal.
Do not renew based on successful-job percentages and a product demo. Renew when you have restore evidence for the workloads that matter. If that evidence is missing, the decision is not automatically to replace the platform. The decision is to find out whether you have a product problem, a service problem, a design problem, or a test nobody bothered to run.
Start with the recovery promise you are paying for
Pull the contract, implementation scope, service description, invoices, recovery plan, and current workload inventory. Then write down what the organization believes it bought.
For each critical workload, capture:
- The business process it supports
- The system owner and recovery decision owner
- The recovery time objective, or RTO
- The recovery point objective, or RPO
- The backup frequency and retention policy
- The recovery method the provider is expected to use
- The work retained by internal IT
- Any identity, network, application, encryption-key, or third-party dependency
This sounds basic. It is also where the first gap usually appears.
The business may expect the ERP back in four hours while the agreement only covers backup jobs and support response. The provider may protect the database but not the application server, identity service, DNS, firewall rules, or integration credentials needed to make the workflow usable. A SaaS platform may retain some deleted data, while the buyer assumes that retention is a full backup service.
The Backup and Disaster Recovery Guide for Mid-Market IT Leaders explains the broader design, including recovery tiers and SaaS coverage. At renewal, narrow the question: can the service you are paying for meet the recovery promise attached to each critical workload?
A restore test should prove more than file retrieval
Restoring one file is useful. It is not proof that a finance, customer service, manufacturing, or clinical workflow can return to operation.
Match the test to the promise.
If the agreement covers file-level backup, test representative files, permissions, versions, and user access. If it covers Microsoft 365 or another SaaS platform, test the objects and recovery granularity you expect to need. If it covers servers or cloud workloads, restore the system into an isolated environment and verify that it boots, authenticates, reaches its dependencies, and serves the intended application. If you are paying for disaster recovery as a service, test the failover and the path back to normal operations.
NIST Special Publication 800-53 Rev. 5 gives buyers a useful standard for thinking about this. Control CP-4 calls for testing contingency plans, reviewing the results, and starting corrective action when needed. Its discussion lists several test methods, from tabletop exercises through full-interrupt exercises. The full recovery enhancement calls for recovery and reconstitution to a known state as part of testing.
NIST control CP-10 connects recovery to a known state within a defined period consistent with recovery time and recovery point objectives. That is much closer to the evidence a buyer needs than a screenshot showing last night’s job completed.
CISA’s current #StopRansomware Guide makes the same practical point for ransomware readiness. It recommends offline, encrypted backups of critical data and regular tests of backup availability and integrity in a disaster recovery scenario. The word “restore” needs to show up in your evidence, not only in the sales presentation.
Build a renewal evidence packet
Ask the internal team or provider for the most recent completed restore records. A usable packet should show:
| Evidence | What it should answer |
|---|---|
| Workload tested | Was this a critical production workload or an easy sample? |
| Recovery point selected | How much data would have been lost at that point? |
| Test environment | Was the restore isolated, and did it reflect the real architecture? |
| Start and completion times | Did measured recovery fit the approved RTO? |
| Data validation | Did the owner confirm records, files, permissions, and transactions were usable? |
| Dependency validation | Did identity, network, DNS, keys, applications, and integrations work? |
| People and provider actions | Which manual steps, escalations, and approvals were required? |
| Failures and exceptions | What broke, and what business impact would it have caused? |
| Corrective actions | Who owns each fix, when is it due, and when will it be retested? |
| Final acceptance | Which business and IT owners accepted the result? |
Do not let “test completed” close the issue. A failed test can be extremely useful if it produces a corrective plan and a successful retest. A clean report with no workload detail, timestamps, validation, or exceptions is weaker evidence than an honest test that found a problem.
You should also compare the test date with material changes. A restore completed before a cloud migration, identity redesign, major application upgrade, acquisition, or provider handoff may no longer prove much about the current environment.
Measure the full recovery path
Backup vendors often report the portion of recovery they control. The business experiences the whole path.
Suppose the provider restores a server in two hours. Internal IT then spends three hours rebuilding network access, finding an encryption key, correcting DNS, reconnecting an integration, and waiting for the application owner to validate the data. The vendor metric says two hours. The business was down for five.
Record both.
The same issue appears with provider support. A platform may be technically capable of a fast recovery, but your service tier, escalation process, or staffing model may not make that speed available when needed. Ask whether the test used standard support, a special engineer, or steps that are outside the agreement.
This is why a restore test is also a service test. It measures the product, the design, the documentation, the people, and the contract at the same time.
Find the work nobody priced
Renewal conversations usually focus on protected capacity, retention, license count, and price changes. Recovery work gets buried.
Check the agreement for:
- Restore requests included in the base service
- Charges for test recoveries, cloud compute, data retrieval, or egress
- Support hours and emergency escalation
- Provider response targets versus actual recovery commitments
- Customer tasks and prerequisites
- Recovery testing frequency and scope
- Isolated recovery environment access
- Ransomware recovery assistance and clean-data validation
- Data access, export, and deletion after termination
- Transition support if you change providers
Pay close attention to language that sounds like a recovery commitment but only promises a support response. “We will respond within one hour” does not mean the system will be operational within one hour.
Also ask what happens when the test exposes a design gap. Is remediation included? Does it require a project? Will storage, bandwidth, replication, licensing, or service-tier costs change? You need that answer before the renewal term removes your leverage.
Choose one of four renewal decisions
Restore evidence should lead to a decision, not another dashboard review.
Renew as designed when representative tests show that critical workloads recover within approved targets, the data is usable, responsibilities are clear, and the contract matches the service being delivered.
Renew with a corrective plan when the platform is a fit but testing exposes documentation, configuration, dependency, staffing, or service-scope gaps. Put the fixes, owners, dates, retest, and any commercial remedy in writing.
Reduce or redesign the service when you are paying for protection or recovery capability that does not match current workloads and business priorities. This may mean changing tiers, retention, coverage, architecture, or the split between internal and managed work.
Run a competitive review when the provider cannot produce credible evidence, repeated failures remain unresolved, important workloads are outside scope, recovery economics no longer work, or the contract blocks a practical exit.
Do not confuse switching vendors with fixing recovery. A new platform can inherit the same bad inventory, missing dependencies, vague ownership, and untested runbook. If the problem is operating discipline, buying another tool just gives the problem a new logo.
Use a simple approval gate
Before approving the renewal, ask the accountable IT and business owners to sign off on five statements:
- We know which critical workloads are protected and which are not.
- We have completed representative restores using the current architecture.
- Measured recovery time and recovery point results are compared with approved business targets.
- Failed tests and coverage gaps have owners, due dates, and retest plans.
- The renewal agreement prices the recovery service, support, testing, and exit terms we expect.
If you cannot sign one of them, write the gap into the renewal record. Decide whether it blocks signature, requires a contract condition, or becomes an accepted risk with a named owner.
A backup renewal should not be a vote of confidence in storage. It should be a decision about recoverability.
Bring evidence. Bring the failures too. That is how you find out whether the organization can recover before an outage runs the test for you.
If your backup or managed recovery agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the contract, invoices, workload list, restore reports, recovery targets, and open corrective actions. Catch Advisors will help you separate product capability from proven recovery and decide what to renew, fix, redesign, or compare.