Ransomware recovery: test a clean service, not just a successful restore

The backup console reports a successful job. The business asks whether the customer portal can be restored after a compromise. Those are different questions.

A successful backup confirms that a configured operation completed according to the backup system's checks. Recovery requires usable data, accessible recovery credentials, trusted infrastructure and the dependencies needed to run the service.

Ransomware recovery testing should prove that a clean, isolated service can perform an agreed business transaction. Include the time needed to obtain access, restore dependencies, reconcile data and get the service owner to accept the result.

Define recovery in business terms

Choose a service and describe the minimum useful state. A restored database without an application that can read it is not a recovered customer portal. A working PBX without routing and account configuration may not restore calling.

Define the recovery time objective and recovery point objective with the business owner. The first concerns the desired time to restore service; the second concerns the tolerated point of data loss. Treat them as objectives to test, not as capabilities established by a configuration screen.

Document which functions can return later. A limited service that safely accepts customer requests may be more valuable early in recovery than a complete reporting environment.

Include the acceptance transaction

Specify a representative action that proves the service is usable: an authorized login, a record lookup and a controlled write, for example.

Use test identities and test records. The exercise should avoid sending real customer messages or triggering production side effects merely to demonstrate recovery.

Protect the ability to recover

Backup copies should be protected from the same compromised authority that can damage production. Review administrative separation, storage access, deletion permissions and recovery credentials.

CISA's StopRansomware guidance recommends offline, encrypted backups of critical data and regular testing of their availability and integrity. The engineering goal is to keep a recoverable copy and prove that it can be used.

No single storage label proves the entire recovery path is protected. An immutable copy can still be unusable if the business has lost its encryption key, recovery account or required application software.

Inventory the dependencies before the exercise

List identity, DNS, certificates, secrets, databases, application services and external integrations. Include the tools needed to administer the recovery environment.

Identify circular dependencies. An administrator may need the identity system to reach the backup console while the identity system itself needs restoration. Plan a controlled recovery path that does not depend entirely on the affected environment.

Preserve necessary configuration and installation material according to the backup policy. Data alone may not be enough to reconstruct a supported application.

Separate restoration from trust

A backup can contain data and software from a period when the environment was already compromised. Restoring it does not automatically establish that the result is safe to reconnect.

Work with the incident-response owner to select recovery points and determine the required investigation and validation. Preserve necessary evidence before making changes that could destroy it.

Build the recovery environment with restricted connectivity. Reconnect only the services required for the exercise and keep production credentials and automatic outbound actions controlled.

Avoid reintroducing old authority

Review secrets, service accounts and access paths before reconnecting restored systems. A restored configuration may contain credentials or trust relationships that are no longer safe.

The appropriate remediation depends on the incident. The recovery plan should make room for that work rather than assuming a restore operation alone resolves the compromise.

Restore in a tested order

A service dependency map should drive the sequence. Foundational identity and network services may need to precede application restoration, while some recovery access should remain independent.

Record the actual sequence during the exercise. If engineers discover undocumented prerequisites, add them to the runbook.

Do not report only the time spent transferring backup data. Waiting for access, locating keys, rebuilding configuration and resolving dependencies all affect the business's recovery time.

Reconcile the restored data

Confirm that the restored application can read the data and that important relationships are intact. Sample records are useful, but critical workflows may also need counts, totals or referential checks.

For systems exchanging data, identify events that occurred after the recovery point. Decide how they will be replayed, reconciled or handled manually without creating duplicates.

A database restored to a consistent technical state can still disagree with a payment provider, CRM or carrier record. Business reconciliation addresses that gap.

Keep the data-loss decision explicit

The service owner should understand the selected recovery point and the records that may be absent. Do not describe an old restore as “fully recovered” without explaining the period not represented.

Where the business chooses speed over a more recent recovery point, record that decision and the follow-up work it creates.

Test the people and procedures

Have someone other than the original system builder follow the runbook. This reveals undocumented knowledge and access assumptions.

Check contact paths, ownership and decision authority. A technically sound plan can stall if nobody knows who may approve reconnecting a service or notify affected users.

Include the communications process in the exercise. Internal updates should distinguish investigation, restoration, validation and service acceptance rather than reporting all of them as one recovery percentage.

Measure the whole recovery

Record when the exercise starts, when access becomes available, when dependencies are restored, when technical validation passes and when the business accepts the service.

Compare the observed result with the objectives. A missed objective is useful evidence for deciding whether to change the architecture, process or target.

Do not hide manual work or pre-staged resources when reporting the result. If the exercise used infrastructure that would not be available during a real incident, say so.

Repeat after meaningful changes

A new identity provider, database version, storage design or integration can change recovery behaviour. Use those changes as triggers for targeted exercises.

Not every test needs to restore the entire estate. A focused exercise can verify a critical dependency, while periodic broader exercises confirm that the parts still work together.

A hypothetical customer-portal exercise

A business restores its portal into an isolated environment. The database restore succeeds, but the application cannot authenticate because the expected identity configuration was not included in the recovery material.

The team resolves the missing configuration and records the added time. It then discovers that a scheduled job would send customer notifications when the restored application starts.

The runbook is updated to suppress outbound actions in recovery until approved. A test user logs in, reads a permitted record and creates a controlled test request. The service owner reviews the data-loss period and accepts the recovered state for the exercise.

The result is a more credible recovery plan, even though the first test exposed several failures. The exercise found them before the business had to depend on the plan.

Examine the economics of recovery

Protected copies, isolated infrastructure and testing have costs. Compare those costs with the business consequence of losing the service and the time required to rebuild it manually.

Avoid a generic return-on-investment percentage. Use the organization's own dependency and continuity assessment, and make uncertain assumptions visible.

A more frequent backup can improve the available recovery point, but it does not necessarily shorten the time to restore a complex service. Invest according to the measured constraint.

Keep evidence the next team can use

Save the exercise scope, configuration versions, observed timings, validation results and unresolved limitations. Assign owners and due dates to corrective work.

Record where recovery credentials and key-access procedures are maintained without placing the secrets themselves in a broadly accessible report.

An exercise report should be a working operational document. A certificate-like statement that “backups tested successfully” loses the details needed when the next incident or staff change occurs.

Restore a business journey, not just a file

Choose a service that matters to daily operations and describe what must work for an employee to use it. The application may depend on identity, database records, file storage, network access and an external integration. Restoring only one component can produce a healthy-looking server with an unusable service.

Prepare an isolated recovery environment appropriate to the exercise. Decide how it will avoid sending real customer messages, processing duplicate transactions or connecting to production destinations unintentionally. A recovery test should provide evidence without creating a second incident.

Restore the selected components from the chosen recovery point and record the actual sequence. Note dependencies that required manual intervention, credentials that were unavailable and assumptions that proved wrong. These observations are more useful than a simple pass label.

Have a business representative complete an agreed task. For example, the representative might open a record, verify its supporting attachment and produce an internal test output. Define this task before the exercise so the result demonstrates useful service recovery rather than whichever feature happened to work.

Check the recovered data deliberately

A successful startup does not establish that the data is complete or consistent. Compare selected records, relationships and recent changes against the expected recovery point. Use checks appropriate to the application rather than relying only on the backup software's completion status.

Document the period of work that would need reconstruction after recovery. The business owner should understand what data is absent and which source systems might help reconcile it. Avoid presenting a recovery point as a promise that no work will be lost.

Where multiple systems are restored, inspect their relationships. A CRM restored to one point and a document store restored to another can leave missing references or mismatched states. Decide how the team will identify and resolve those discrepancies before the service returns to normal use.

Turn the exercise into a maintained recovery plan

Record the time taken for major stages, the people required and the decisions that delayed progress. Distinguish measured exercise results from future recovery commitments. Conditions during an actual incident may differ, especially when identity systems, networks or staff availability are affected.

Assign each unresolved issue an owner and a next action. A missing credential procedure, undocumented dependency or failed integrity check should lead to a concrete change and a focused retest. Storing the report without resolving these issues leaves the recovery risk in place.

Review the plan when the business adds a critical application or changes hosting arrangements. New dependencies can invalidate an otherwise successful earlier exercise. Keep recovery instructions accessible through an approved route that does not depend entirely on the affected production environment.

For a recovery-readiness discussion, bring the critical services, current backup arrangements and the business's tolerance for interruption and missing data. Include any previous restore results. KYCONNECTS can help translate those requirements into a scoped exercise and remediation plan.

A useful recovery test ends with evidence the business can interpret: which service worked, which data point was recovered, what remained unresolved and what must change before the next exercise. That is a stronger basis for planning than assuming a green backup dashboard guarantees recovery.

Keep a copy of the exercise evidence with the recovery instructions and the remediation record. The next test should confirm that previously identified weaknesses were addressed, rather than repeating the same recovery steps without checking whether the operating plan improved.

Recovery questions

Make recoverability observable

The strongest evidence is a tested service and a runbook another engineer can follow. A backup status is one input to that evidence, not its conclusion.