Start with a service you cannot afford to lose
A backup dashboard can be entirely green while a business remains unable to recover. The missing pieces are often outside the backup itself: an identity service, a signing key, a supplier account, a network configuration or the one person who knows how to rebuild an application. Ransomware preparation should begin with a complete service rather than a collection of files.
Choose one critical workflow, such as receiving orders or delivering a customer report. Map the systems and people it needs. Ask the business owner how long the workflow can stop and how much recent work could be recreated. Record those answers as recovery objectives, then test whether the technical plan can achieve them. A target is a decision to validate, not evidence that recovery already works.
Separate the ability to operate from the ability to destroy
An attacker who controls everyday administration should not automatically control every recovery copy. Examine who can delete backups, shorten retention, change backup jobs and recover the credentials for the backup platform. Include the identity provider and email accounts used to reset those credentials. Separation on a diagram is weak if the same compromised account can undo it.
Use the isolation and immutability options appropriate to the platform, and verify their actual behaviour with a harmless test dataset. A disconnected copy, a protected retention policy and separate administration solve different problems. Document the combinations you depend on and who can override them. Confirm alerts reach someone who can act when a protected job stops or retention settings change.
Make the restore sequence explicit
Write the recovery order as a dependency list. A database may need a key service; the key service may require identity; identity may require DNS and time synchronisation. Those circular dependencies should be resolved before an emergency. Keep an accessible recovery runbook outside the systems it describes, with controlled access to sensitive material.
For each stage, name a primary operator and a backup, the prerequisite systems, the expected duration and the evidence of success. “Restore application” is too vague. A useful completion check might be that a test customer can authenticate, submit a synthetic transaction and retrieve the correct result without reaching production services. Use invented test data rather than copying sensitive records into an unprotected exercise environment.
Restore into an environment you can trust
Restoring quickly onto systems still under attacker control can restart the incident. Plan a clean recovery environment with known configurations, reviewed access and monitoring. Investigators and recovery operators need a shared decision about which images, data and credentials are safe enough to use. Preserve relevant evidence before making irreversible changes where operational circumstances allow.
A recent backup is not automatically a clean backup. Compare candidate recovery points with the incident timeline and investigate signs of persistence or tampering. Rotate exposed credentials and review integrations before reconnecting. These decisions are specific to the incident; the runbook should identify the decision-maker and the information they need rather than promise a universal safe waiting period.
Run a small exercise that can fail honestly
Start with a bounded scenario: the primary application and its normal administrator account are unavailable. Give the recovery team only the materials they would actually possess. Record elapsed time, requests for undocumented information, unavailable credentials and every manual correction. The exercise is useful precisely because it reveals work that the written plan omitted.
For example, a team might restore a database in forty minutes but spend three hours obtaining a supplier token. The database backup worked; the service recovery objective did not. Assign the token dependency to an owner, add an approved recovery route, and repeat that part of the exercise. Avoid reporting a successful restore as a successful business recovery until the end-to-end workflow has been checked.
Turn the findings into routine maintenance
Keep a short register of recovery blockers with owners and due dates. Rehearse again after material changes to identity, hosting, applications or suppliers. Check that departing staff lose backup access and that new administrators understand recovery responsibilities. The exercise schedule should follow the importance and rate of change of the service.
Useful measures include the age of the last successful end-to-end restore, unresolved recovery dependencies and the difference between the recovery target and observed exercise time. These measures help people make decisions. Counting stored terabytes or completed backup jobs alone tells a much narrower story. This article is a planning guide; response actions during an active compromise should be coordinated with the incident lead.