Use this at least once per review cycle the company has set, rotating across critical services, and after any major change to the backup setup. You get two documents in a new folder, ./backup-restore-test-evidence/: a test plan written before anyone touches a backup, with the service, the scenario and the pass criteria (test-plan.md), and after the test a record with the measured times, the results, the findings and a sign-off line for the system owner (test-record.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The reader's team runs the restore; the agent plans and records.
Inputs to gather
Read the business impact analysis or wherever recovery objectives are written (recovery time objective, how long the service may be down; recovery point objective, how much data may be lost), the backup policy, the architecture overview, and, read-only, the backup configuration and job history. Read earlier restore test records. Ask the reader, in one message: which service matters most if lost, who can run a restore, which isolated environment is available, and who signs off the result.
Step 1: choose what to restore
Pick the service with the tightest objectives or the most important data, and rotate to the next one in the following cycle so every critical service is tested over time. Restore what the business actually needs to run: the database, the file storage, the configuration and the secrets the application needs to start. Restoring one file proves the backup tool works; it does not prove recovery. Once a year, plan a restore into a clean environment that does not rely on anything in production, which is the situation after ransomware. List what the restored stack depends on (DNS, certificates, secret store, identity provider, email or payment endpoints) and which of those the test actually exercises.
Step 2: write the plan before the test
The test plan (test-plan.md) holds: the service and its objectives; the backup set to use and its age; the declared time of the simulated failure, so data loss is measured against a fixed scenario rather than the last convenient backup; the target environment, isolated from production, with its access controls stated; the people and their roles; open findings from the last test, to check; the success criteria, set now and not after the result is known (row counts within a stated tolerance, checksums, the application starts, a user can sign in, one business transaction completes); stop conditions; and how the restored copy is deleted or secured afterwards, because it contains production data. Get the system owner's approval of the plan before anything runs.
Step 3: record the run with timestamps
During the test, record times for: start, backup located, data retrieved, restore complete, application running, verification complete. Measured recovery time is start to verified. Measured data loss is the gap between the backup point used and the moment the simulated failure happened. Note every manual step, every missing piece of documentation, and every credential that only one person had.
Step 4: compare and write findings
Compare measured recovery time and data loss with the objectives. Mark each success criterion pass or fail with the evidence. Write findings as facts with an owner role and a proposed action: "Restore took 9 hours against a 4 hour objective; 5 hours spent waiting for access to the backup vault, held by one engineer." A failed test written up honestly with actions is good evidence; a test that "passed" without timings is weak evidence. A measured time beyond the objective also gets a proposed risk register entry for the risk owner to add; if the gap persists, the business owner either funds the fix or accepts the risk in writing, because the objectives are what customers were told.
Step 5: assemble the record and sign-off
The test record (test-record.md) holds the plan reference, timings, criteria results, findings, actions, confirmation that the restored copy was deleted or secured (a listing showing it is gone, not a screenshot of the delete), each earlier finding marked closed or still open, and a sign-off line for the system owner. Attach log extracts and screenshots that show times, with any personal data in them masked. Where a framework or regulation sets expectations on testing frequency or scope, run a framework lookup instead of assuming one.
If the output folder exists, ask before overwriting and offer a new subfolder instead.
What good looks like
- The record proves a time, not just a success: measured recovery time and data loss sit next to the objectives.
- Success criteria were written before the test; criteria written afterwards tend to match whatever happened.
- The common mistake is offering backup job success logs as restore evidence. The tells: no timings anywhere, the same small file restored every year, and a restore that depends on the production account the backup is meant to survive.
- Backups are checked for separation: stored in a different account or with deletion protection, so the people or malware that can damage production cannot also delete the backups.
- Findings carry owners, and the next test checks they were fixed.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-backup-restore-test-evidence
Rules
- MUST write the success criteria and get the owner's approval before the test runs.
- MUST record measured recovery time and data loss against the stated objectives.
- MUST include the deletion or securing of the restored copy in the plan and the record.
- MUST write outputs only inside
./backup-restore-test-evidence/ and ask before overwriting.
- NEVER start a restore, delete a backup or write to production; the reader's team runs the test.
- NEVER record a criterion as passed without the evidence behind it.