Run a Timed Recovery Drill for a Key Service

Start a recovery exercise with a business question: how would we take tomorrow's orders if this application became unavailable today? That gives the drill a useful finish line. A running virtual machine or a restored folder may be a necessary step, but the business needs a working process.

Choose one service for the first exercise. An order system, shared project archive or specialist scheduling application is enough to expose missing credentials, undocumented dependencies and slow approval routes. Keep production running and perform the recovery in an isolated environment.

The NCSC's incident management guidance connects incident response with disaster recovery, business continuity and crisis management. The exercise below applies that relationship to a manageable technical task. It is a proposed method, not a claim that your current recovery capability has been tested.

Agree what success means before starting

Ask the service owner to define the minimum useful service. For an example order application, that could mean a named user can find an existing customer, inspect an order and enter a new test order without sending anything to a live fulfilment system.

Set a recovery time objective: the target elapsed time until that agreed service is available. Separately set the recovery point objective: the maximum acceptable age of the recovered data. Write both in plain language and explain who accepts them. A target that nobody can afford to implement should be discussed before an incident.

Record exclusions explicitly. Perhaps payment processing and historical attachments are outside the first drill. That is reasonable if the final report names the missing capabilities. Do not call the entire business recovered when the exercise covered only a database.

NIST's contingency planning guide provides a wider framework for connecting system recovery to business impact. Use that framework to expand the programme after the first useful test.

Prepare the exercise without solving it for the operator

Nominate an operator, a business reviewer and someone to record events. In a small team, people can combine roles, but ask a colleague who did not build the service to follow the written instructions where possible.

Prepare an isolated recovery destination with outbound email, payment, automation and customer integrations disabled. Confirm that the exercise cannot change production DNS or overwrite live data. Keep the permitted actions and stop conditions clear.

Give the operator the recovery runbook, not a fully prepared desktop with every session already open. If the scenario assumes the primary identity service is unavailable, identify which independent access route will be used. Do not disable production authentication to simulate the problem.

NIST's guide to tests, training and exercises treats preparation, execution and evaluation as parts of the same programme. A useful drill produces corrections and evidence, not merely attendance.

Start the clock at the request for recovery

Record when the simulated failure is declared and when the operator begins. Continue timing while they locate credentials, obtain approvals, find installation media, retrieve the backup and resolve missing instructions. These delays are part of recovery.

Use a simple event log:

If the operator needs undocumented help, allow it and record it. The purpose is to discover the real capability. Pause only when continuing could affect production, expose data or exceed the agreed exercise boundaries.

Let the service owner judge the result

Check both old and recent records, permissions, a representative attachment and a normal business operation. Compare the recovered data's age with the recovery point target. Record the time when these checks pass, rather than the earlier time when the restore tool finishes.

If full restoration will take too long, discuss a temporary working method. Decide what records staff must keep during that period and how they will reconcile them later. A manual workaround that creates duplicate orders or loses authorisation records needs its own controls.

Our Microsoft 365 incident response starter plan covers the surrounding response decisions when an incident also affects accounts and collaboration. Keep those decisions connected to the recovery runbook.

Finish with a short repair list: each delay, its owner, the required change and a date for rechecking it. Preserve the measured result with its scope and assumptions. Repeat the failed part after fixing it, then choose the next service based on business impact.

References

• NCSC, Incident management. Accessed 17 October 2026.
• NIST, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems. Accessed 17 October 2026.
• NIST, SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. Accessed 17 October 2026.