What evidence proves a disaster recovery service can restore your systems?

Proof that a disaster recovery service can restore systems is a repeatable, auditable chain of evidence showing that protected data can be located, recovered into a usable environment and brought back into business operation. A backup inventory or a supplier’s assurance is not enough on its own; the evidence must demonstrate that the recovery process works for the systems, dependencies and data the organisation actually relies on.

Useful evidence includes the following:

• A clearly defined recovery scope. Records should identify the servers, applications, databases, configurations and business data covered by the service. This makes it possible to compare the promised protection with the organisation’s real technology estate and identify exclusions before an incident occurs.
• Recovery runbooks. A runbook should set out the order of recovery, prerequisites, access requirements, configuration steps and validation checks. It should explain how infrastructure is established, how applications are started, how data is attached or restored, and how users are returned to service. Instructions should be specific enough for an authorised person to follow rather than relying on undocumented knowledge.
• Dependency mapping. Applications often depend on identity services, DNS, databases, certificates, network connections, file shares and third-party integrations. Evidence of recovery capability should show that these relationships have been considered. Restoring one server proves little if the application cannot authenticate users or connect to its database.
• Recovery logs and system records. A credible recovery exercise produces technical records such as job results, timestamps, error messages, resource allocation details and validation outcomes. These records provide an audit trail and show whether the process followed the documented method, rather than merely recording that someone declared the exercise successful.
• Data integrity checks. Recovery evidence should show how the restored data was checked. Depending on the system, this may involve application-level consistency checks, database integrity commands, file comparisons, checksum validation or confirmation that recent transactions are present. A system that starts but contains incomplete or corrupt data has not been usefully recovered.
• Application and user acceptance checks. Technical availability is only one part of recovery. Evidence should include checks that applications open correctly, users can authenticate, permissions remain appropriate, key records are accessible and important workflows can be completed. Business owners or nominated system specialists should take part where their knowledge is needed to confirm that the service is usable.
• Proof of recovery into a separate environment. Where appropriate, recovery should be demonstrated without damaging production systems or overwriting live data. A segregated recovery environment can show whether the service can recreate the required infrastructure and expose hidden dependencies that a simple file-level restore would not reveal.
• Evidence of configuration recovery. Data alone is not the whole system. Records should show whether operating system settings, application configuration, network rules, permissions, encryption keys and other required components are protected or can be rebuilt. If these elements must be recreated manually, that requirement should be documented as part of the recovery method.
• Exception and corrective-action records. Failed jobs, missing permissions, incompatible versions, incomplete data or manual workarounds should be recorded rather than concealed. Strong evidence shows what went wrong, how the issue was resolved, whether the runbook changed and whether the correction was subsequently checked.

The evidence should also be tested against realistic conditions. A recovery process may appear effective when all administrators, documentation and network routes are available, but fail when a primary site is inaccessible or key personnel cannot be reached. Exercises should therefore consider the scenarios relevant to the organisation, including loss of infrastructure, accidental deletion, malware-related recovery and failure of a critical dependency. The scenario, assumptions and limitations should be written down so that the result can be interpreted accurately.

Independent review strengthens the conclusion. The person who operates a recovery process may not be the best person to judge whether it meets business requirements. A system owner, internal risk lead or suitably independent reviewer can confirm that the recovered service is complete, the validation criteria are appropriate and any residual risks have been accepted. For regulated or contract-sensitive organisations, this review can also support audit requirements.

Recovery evidence should be current and traceable. A test completed before a major application upgrade, infrastructure change or alteration to the backup design may no longer represent the live environment. Each record should therefore identify the systems and versions involved, the date of the exercise, the people responsible, the evidence retained and the changes made afterwards. Comparing successive exercises can reveal whether recovery capability is improving, declining or being affected by technology changes.

When assessing a disaster recovery service, ask to see an anonymised recovery report, the relevant runbook, the stated scope and exclusions, the validation method, the exception log and the resulting improvement actions. The most persuasive evidence is not a certificate or a verbal assurance; it is a consistent body of records showing that the organisation’s own systems can be rebuilt, its data remains usable and known weaknesses are actively managed.