A successful backup proves that something was copied
It does not prove that the copy is clean. It does not prove the keys are available, the application can be rebuilt, the identity system can authenticate, the provider will cooperate, or the business knows which service should return first. A backup can be technically successful every night and operationally useless on the morning it matters. This distinction becomes severe during ransomware and destructive incidents. The organization may possess every file while lacking a trustworthy control plane in which to use them.
Recovery has six components
- Data — the required records exist, are intact and represent an acceptable point in time.
- Identity — administrators, users, machines and services can authenticate without relying on compromised authority.
- Configuration — infrastructure, policies, certificates, secrets and dependencies can be reconstructed.
- Application — software, licenses, integrations and runtime requirements remain available.
- Operation — people know the minimum service, manual workarounds and order of return.
- Authority — someone can accept the consequences of the selected recovery point and reconnect the environment.
If one component is missing, the organization may restore data into a system it cannot trust or operate.
The clean-room problem
After compromise, the original environment is evidence and a potential source of reinfection. Recovery should therefore have a clean path: trusted administration, controlled network boundaries, known build material and observation before broader reconnection. This is where many backup strategies collapse. The backups sit under the same identity provider, cloud administrator or vendor account as production. The attacker who controls the environment may also control deletion, retention and restoration. Isolation must be architectural, not a checkbox in the backup console.
What a recovery test must prove
- A named service can be restored from a defined recovery point.
- The restoration can occur without using a suspected identity or device.
- Required keys, certificates, software and vendor contacts are available.
- Data integrity and business meaning can be validated.
- Dependent services can be reconnected in a controlled order.
- The restored environment can be monitored for residual compromise.
- Decision owners can accept data loss, service degradation and return-to-operation risk.
CISA’s ransomware guidance emphasizes offline or protected backups and regular testing. The material point is the test: integrity and availability under a disaster scenario, not the green status of the last job.
A simple recovery exercise
- Choose one critical business service, not an isolated server.
- Define the latest acceptable recovery point and maximum tolerable interruption.
- Assume normal administration and the primary communications channel are unavailable.
- Rebuild the minimum environment required to deliver the service.
- Validate a real transaction, record or workflow with the business owner.
- Record every undocumented dependency, unavailable credential and provider delay.
- Destroy or isolate the test environment appropriately after evidence is captured.
The value of the exercise is not a perfect recovery time. It is the discovery of assumptions while there is still time to repair them.
The position
Backup is a storage control. Recovery is an operating capability. An organization that conflates the two is not protected by its backups. It is comforted by them.