A team says "backups run nightly and are retained for 30 days". You have one hour to assess whether they could actually recover. What do you check?

The checks, in the order that finds problems fastest

1. When was a restore last performed, and how long did it take? The single most informative question. If the answer is "never", nothing else matters much — an untested backup is a hypothesis. If there is a timing, compare it against the stated RTO; the two are frequently different by an order of magnitude.

2. What exactly is included? Databases usually are. Frequently not: object storage, secrets and keys, IAM policies, infrastructure definitions, queue contents, and third-party SaaS holding critical data. A restore that recovers the database into an environment that no longer exists is not a recovery.

3. Can the same credentials that manage production delete the backups? The ransomware question, and usually the most serious finding. Backups need a separate account or subscription, a distinct identity path, and ideally object lock in compliance mode — governance mode can be overridden, which defeats the control against the exact threat it exists for.

4. Is retention longer than realistic detection time? Ransomware frequently dwells for weeks. A 30-day window may be adequate; a 7-day window may contain only already-encrypted backups.

5. Where is the encryption key? If it is in the system being restored, the backup is unrecoverable. This is a real and recurring finding.

6. Is backup success alerted, or only failure? A job that stopped running produces no failures at all. Alert on success within an expected window.

7. What is the actual RPO? "Nightly" means up to 24 hours of loss. Is that the agreed RPO, or just the schedule someone set? If the business needs an hour, the mechanism must be point-in-time recovery with continuous log archiving, not nightly snapshots.

What I would recommend at the end of the hour

A scheduled restore drill — quarterly, into a clean environment, timed, verified by data integrity checks rather than by process completion, and performed by someone other than the runbook's author. That single practice fixes what a dashboard cannot, and it keeps the runbook current as a side effect.

What a strong answer adds

Separating backup from recovery capability. Having backups is a storage property; recovering is a function of tooling, sequencing, dependency order and human logistics — none of which appear on a backup dashboard. The organisations that recover quickly have rehearsed the order: identity, then DNS and networking, then core platforms, then applications.