- Define acceptable downtime and data loss before choosing a restore test.
- Restore to an isolated destination and ask the business owner to validate the result.
- Keep the recovery record, including failures and untested dependencies.
A successful backup job says data was copied. It does not establish that an employee can recover the right version, decrypt it, and use it in the application that needs it.
Choose a restore test around a business task. Recovering an accounting database, for example, should end with the finance owner checking the expected records in a safe test environment. Seeing the backup file in a storage console is only an intermediate step.
Agree on what recovery must achieve
Ask the service owner how much interruption and missing work the business can tolerate. Recovery time objective describes the target time to restore service; recovery point objective describes the tolerable loss of recent data. Treat these as business requirements to test, not values inferred from a backup schedule.
For a hypothetical accounting service, an owner might require recovery before the next payroll run and enough recent records to reconcile the period. Write down the actual requirement for your company. Include dependencies such as identity, database versions, encryption keys, licenses, and integrations.
CISA's business backup guidance describes the 3-2-1 approach: three copies, two media types, and one copy off-site. Check administrative independence too. Copies that can all be deleted by the same compromised account share a failure path despite being in different locations.
Prepare a safe destination
Obtain the owner's approval and use a separate restore location. Prevent the test application from sending real invoices, emailing customers, or overwriting production data. If the restored content contains sensitive records, restrict access and plan cleanup before starting.
Identify who can retrieve the backup and keys without relying on the primary administrator. Verify access without placing credentials in the test worksheet. Note whether an outage of normal SSO or the document platform would prevent the team from reaching its instructions.
Measure the whole attempt
Start the clock when the recovery request begins, including approval, credential retrieval, downloading, and troubleshooting. Record when the application is usable, not only when data transfer finishes.
Ask the owner to check record completeness and a representative business operation. For a file restore, that may mean opening the correct historical version and confirming permissions. For an application, it may require reconciliation and a controlled transaction. Do not assume that a file-level test proves full-system recovery.
Use this worksheet:
| Field | What to record |
|---|---|
| Scope | Service, dataset, and explicitly excluded dependencies |
| Recovery point | Copy used and latest business data confirmed present |
| Time | Request, access obtained, restore complete, owner acceptance |
| Validation | Checks performed and results, including discrepancies |
| Follow-up | Failed step, corrective owner, due date, and retest method |
Close the test without losing the lesson
Remove test copies according to the approved cleanup plan and confirm no temporary access remains. Store the worksheet and safe evidence where recovery staff can retrieve them during an outage.
If the test missed the business target, explain why: slow archive retrieval, missing keys, application incompatibility, or incomplete data. Assign a correction and retest the failed step. A failed exercise is useful evidence; marking it successful because a file eventually appeared hides the dependency you needed to find.
Schedule broader tests after significant changes. For compromise scenarios involving untrusted administrators or deleted copies, use the separate ransomware recovery exercise.
Turn this response guidance into clearer roles, containment decisions, evidence paths, and executive briefing rhythm.