How to document a backup recovery test

A readable backup file is only the start: verify restoration of a usable service.

Prepared by DATPOL, 4 October 2026. This guidance supports scoping, discussions and acceptance; it does not replace a design or the specific equipment manual. This British English version concerns services and properties in Poland.

Define the scenario and acceptance criteria

Choose a specific service and recovery point. Agree tolerable data loss and restoration time: RPO and RTO. Test in an isolated environment or approved work window without risking production data.

Restore dependencies

Recovery may require configurations, keys, accounts, DNS and dependent applications as well as data. Keep secrets out of public test records. Check service startup and an agreed business operation; a matching archive checksum does not prove the application works.

Record results and corrective action

Record the backup, dates, timings, scope, operator, test outcomes and limitations. Do not describe a partial exercise as a test of every system. Assign fixes and retests for failures. Protect backups from incidents affecting the production environment.

Practical checklist

Scenario, RPO and RTO.
Safe test environment.
Functional check by the service owner.
Record, limitations and corrective actions.

Next steps and references

DATPOL service scope and supporting material

CISA — StopRansomware Guide

Support requests: DATPOL24. Do not include passwords or secrets in the form.