Ransomware recovery exercises: prove the service can take an order again

The database has restored. The infrastructure console is green. The order-processing team still cannot log in. For the infrastructure lead responsible for recovery, this is the moment an exercise becomes valuable: it exposes the distance between recovering a technical component and returning a business service to use.

Design the exercise around that distance. Select one service whose interruption has a clear commercial consequence, such as orders that cannot be accepted before a fulfilment cut-off. Define the smallest useful operating state with its business owner. Full historical reporting may be deferrable; authenticating an operator, accepting an order and preventing duplicate dispatch may not be.

NIST’s Guide for Cybersecurity Event Recovery connects resource prioritisation with realistic test scenarios and continual improvement. The practical implication is to choose a recovery question narrow enough to answer with evidence. “Are we ransomware-ready?” is too broad. “Can this service resume its agreed minimum operation when normal identity access is unavailable?” gives the exercise a purpose.

Run the discussion and the technical test as different activities

A tabletop asks people to work through a scenario: who declares the incident, who authorises isolation, which recovery point is acceptable and who decides that the service can reopen. It can expose missing authority, inaccessible instructions and contradictory assumptions. A confident answer in that discussion is evidence of a decision, not evidence that a restore will work.

A controlled restore executes the relevant technical steps in an agreed test boundary. It can establish whether selected backups, credentials, configurations and application checks work under those conditions. Its findings should identify anything supplied in advance that would need to be obtained during an actual incident.

Use the tabletop to locate the uncertain decisions, then select the technical tests that can resolve them. If the discussion reveals that nobody knows how to access the backup console without the primary identity provider, test that access route before arranging a larger application exercise.

Define a safe boundary that still tests the difficult parts

Use an isolated recovery environment with approved data handling, controlled connectivity and no route for test transactions to reach live customers or suppliers. Nominate a controller who can stop technical activity. Stop conditions should include unexpected production connectivity, unintended outbound messages, exposure of data beyond the approved boundary or signs that the activity is affecting a live service.

Agree how credentials and encryption keys will be made available, which dependencies are real and which are simulated, and who checks that isolation is effective. If a supplier endpoint is represented by a stub, say which behaviour the stub demonstrates and which supplier behaviour remains untested. This makes the result interpretable without requiring a dangerous production disruption.

Preserve incident evidence separately from recovery work in the scenario. Ask the response lead what must be retained before rebuilding or changing affected systems. The exercise should test that handover, rather than encourage operators to erase information in pursuit of a faster restore.

Build the scenario around an order that crosses boundaries

In this hypothetical exercise, the order application is unavailable after a suspected ransomware incident. Its database backup can be restored, but the normal identity service is unavailable and the shipping integration is paused. The business owner needs staff to accept new orders without losing or duplicating those placed around the interruption.

Begin with a short incident statement and release new information as participants reach decisions. Useful injects include:

• The usual administrator cannot sign in. The identity and infrastructure leads must identify an approved recovery-access route. Note whether they can retrieve the necessary instructions without the unavailable service.
• The latest backup is technically readable, but its suitability is uncertain. The response lead and application owner must explain how they will select a recovery point and assess the restored environment before reconnection.
• The database is available, but operators cannot authenticate. The team must resolve the application dependency. Do not count database completion as service recovery.
• An order appears in the shipping system but not in the restored application. Operations must decide how to reconcile work around the interruption before replaying messages.

Keep expected actions in the exercise design and observations in the outcome record. If someone says they would call a supplier, distinguish that proposed action from successfully reaching the supplier through the agreed escalation route. The difference can matter more than the duration of the database restore.

Make application validation part of the restore

AWS Backup restore testing can automate periodic restores and record restore-job duration. AWS also provides a validation window before test-resource cleanup. Those capabilities can supply repeatable technical evidence, but the business meaning of success still needs to be designed.

Its validation documentation describes an event-driven workflow, triggered after a restore job completes, using an EventBridge target such as Lambda. The customer supplies the validation logic. This is the important buying and implementation detail: a successful restore status is a starting point for application checks, not a substitute for them.

For the fictional order service, validation should demonstrate that an authorised operator can sign in, retrieve an agreed pre-interruption order, submit a marked test order and see the correct status in the controlled downstream integration. The application owner should also check reconciliation totals and a duplicate-delivery case. Use reference results prepared independently of the recovered application’s own success message.

Separate backup selection, restoration, dependency repair and business acceptance in the timeline. If the restore takes 40 minutes but access recovery takes another two hours, the infrastructure team needs both facts. They identify different improvement work and different budget owners.

End with an acceptance decision and a retest

The business owner should state whether the tested service meets the agreed minimum operating state, which limitations remain and what evidence supports that decision. Security and response specialists should state their conditions for reconnecting the environment. Neither decision should be inferred from a completed checklist.

Turn each material finding into a correction with an owner and a suitable retest. A missing contact may be resolved by exercising an escalation route. An authentication failure needs a successful application journey. A reconciliation defect needs evidence that the affected transactions can be accounted for without duplicate effects.

Use the findings to turn recovery-time objectives into a testable recovery plan. The exercise has earned its cost when it changes the sequence, access arrangements or dependencies that would otherwise prevent the business from operating again.