Key takeaways
- Test whether employees can complete a defined business task after restoration.
- Include account access, suppliers, manual approvals and reconciliation in the exercise.
- Record delays and assign specific repairs, then test those repairs.
A recovery exercise should finish with employees completing an ordinary business task: accepting an order, issuing an invoice or finding a customer record. Restoring a database is one step toward that outcome. Staff may still need working accounts, connected applications and permission to resume service.
Managers can use a scheduled exercise to find those dependencies before an outage. Choose one service, agree what staff must be able to do and ask a technical lead to design a safe test. Record which parts will be restored in a test environment and which will be discussed rather than executed.
Choose a service and map its dependencies
For an order-processing exercise, for example, the proposed test could follow an order from receipt through stock confirmation to an invoice. List every application and outside provider involved. Ask the employees who perform each step to identify any spreadsheets, shared folders or manual approvals missing from that list.
NIST’s Guide for Cybersecurity Event Recovery, published in 2016, recommends planning around business priorities, system dependencies and recovery roles. It also calls for exercises and improvements based on their findings. Its guidance is for preparing recovery plans, rather than directing an active incident.
Assign a business owner to decide when the selected service is usable. An engineer might confirm that an application runs; an accounts clerk can check whether invoices reconcile and reach the right customer. Put both checks in the exercise plan.
Check access to backups and recovery tools
The federal StopRansomware guide, published in May 2023, recommends offline, encrypted backups and regular tests of their availability and integrity. It also recommends keeping incident response and communications plans available offline. Copies reachable through compromised accounts may be vulnerable during an attack.
Ask the technical lead to demonstrate how an authorized responder would obtain recovery instructions, credentials and encryption keys if normal email and sign-in services were unavailable. Keep secrets out of the exercise report. Record whether access worked, who is responsible for maintaining it and which steps depended on a particular employee.
For the restore itself, use an isolated test environment under the technical lead’s supervision. Include checks for missing records, permissions and software dependencies. Decisions about reconnecting systems after an actual compromise belong in the incident response plan, with the security team investigating how the attacker gained access.
Measure delays as well as restoration time
Before starting, agree when timing begins and what counts as completion. Record time spent locating instructions, contacting vendors, waiting for approval, restoring systems and checking transactions. Keep those entries separate so a slow response from a supplier is not mistaken for slow backup software.
A recovery exercise record
| Record | What to include |
|---|---|
| Service tested | The business task employees attempted, and any functions excluded from the test. |
| Conditions | Available staff, advance preparation and systems assumed to be working. |
| Observed time | Elapsed time for each activity, including waits and failed attempts. |
| Remaining limits | Unreconciled records, unavailable functions and any work completed manually. |
| Repairs | A named owner, a due date and a repeat test for each problem. |
Suggested worksheet
A recovery-time objective is a target for restoring service; a recovery-point objective sets an acceptable amount of data loss measured in time. Compare both with the exercise findings. A test carried out with full staffing and advance preparation gives information about those conditions, so preserve that context alongside any reported recovery time.
Schedule a repeat test for each repair. If vendor access failed, retest that access with the vendor. If staff could restore records but could not reconcile them, have the business owner specify which checks are needed before transactions resume.
