How often the district actually exercises a restore — not how often backups run. A backup that's never been restored is operational fiction; the test is the only thing that proves the backup posture works.
Hard finding · Restores never tested
Backups exist but have never been test-restored. Until a restore is exercised end-to-end (even on a single Tier 1 system), the entire backup posture is unverified. Companion to DR Planning F5 — testing the DR plan and testing the restores are different exercises.
Date of the most recent successful restore test. Staleness threshold = F1 cadence + 90 days; if F1 is Never, this stays empty.
Named role that owns scheduling, running, and reporting on restore tests. MSP-led counts if it's contractually scheduled and reported.
What level of restore was actually performed. Single-file restore proves the backup readable; full-system or end-to-end DR proves the recovery posture works under realistic conditions. Bigger scope = stronger evidence.
Which criticality tiers (from Recovery Objectives F4) have been included in restore tests. Multi-select.
Where the restore was performed. Isolated sandbox is the gold standard (no production blast radius); production is risky but real; dev/QA is a useful middle ground.
How the restored data was checked. Hash check proves bit-for-bit equivalence; spot check is human-visual; none means the restore succeeded but no one confirmed the data is good.
Whether the restored system was actually exercised. User-acceptance test (someone logs in, runs typical operations) is the gold standard; admin check confirms the system starts but not that it's usable.
Whether the actual time-to-restore was recorded and compared to F2 RTO in Recovery Objectives. Even "exceeded RTO" is more useful than "not measured" — it's the input to RTO refinement.