October 2026. Almost every company takes backups. The question an auditor or regulator asks is different: when did you last do a restore, and how long did it take? ISO 27001 (control 8.13) and NIS2 expect recovery to be tested. See also our page on backup and recovery.
Why a successful backup job is not enough
A green status says the job ran, not that the data is usable. Corrupt backups, missing keys and forgotten systems only surface during a restore. Protected, immutable copies help against ransomware, as described in immutable backups, but those too must be restorable.
What you test
Choose a recovery scenario per critical system and test at least annually, critical systems more often. Record: which system, which backup (date), who performed it, how long it took and whether the data was complete and usable. Compare the measured time with the agreed recovery time (RTO) and the measured data loss with the RPO.
Three types of test
File restore: a sample of individual files or mailboxes, simple and feasible monthly. System restore: restoring a full server or database into a test environment. Scenario exercise: recovering several systems in order, for example after ransomware; combine this with a tabletop.
The evidence
Keep a short report per test with date, scope, result and deviations, plus a screenshot or log file. A deviation, such as a recovery time longer than the RTO, is not a failure but input: record the improvement action. That is exactly what clause 10 of ISO 27001 asks for.
What auditors often find
Backups that were never restored, SaaS data without its own backup, and recovery targets (RTO/RPO) never discussed with the business. Fix these before the audit; the readiness scan helps you gauge where you stand.