A backup restore drill is evidence — if you record it like one

Backups are a claim; restores are a fact

Every organisation has backups. Far fewer can name the last time a specific system was restored from one, how long it took, and what was missing afterwards. The frameworks know this, which is why none of them is satisfied with “we back up nightly”:

• DORA Article 12 — backup policies and restoration and recovery procedures, with restoration tested and a segregated recovery environment; Article 11 — continuity plans tested at least yearly for critical or important functions.
• NIS2 Article 21(2)(c) — business continuity, such as backup management and disaster recovery, and crisis management.
• ISO/IEC 27001 Annex A 8.13 — backup copies maintained and regularly tested in line with the agreed policy; A.5.30 — ICT readiness for business continuity.

The word that recurs is tested. A restore drill is the test. Most organisations run one and lose it: a chat message, a ticket closed as “done”, a slide. That is not evidence; it is a memory.

A drill nobody can find twelve months later did not happen, as far as an auditor is concerned.

What turns a drill into evidence

Evidence is a record with five properties. A restore drill has all five available at the moment it is run — the trick is to capture them then, not reconstruct them before the audit.

1. A date of collection. When the restore was performed — not when the report was written or uploaded. Recency is measured from this.
2. A scope. Which asset or service was restored (the database, the cluster, the SaaS tenant export), from which backup (age, location), into which environment (production, segregated recovery site).
3. The control it proves. “Backups are restorable” as a named control mapped to DORA Art. 12 / NIS2 21(2)(c) / A.8.13 — so the drill counts as coverage for all three at once, not as a stray file.
4. An outcome that is allowed to be bad. Restore time against the target; completeness; what did not come back. A drill that finds nothing wrong every year is a drill nobody looks at.
5. The gap as a finding. Every “did not come back” or “took twice the target” becomes a tracked item with an owner and a due date. The drill’s value is the findings it produces.

Missing any one of these turns the drill back into a memory: undated, unscoped, unlinked, unread, or unfollowed.

Where organisations actually lose it

• The date is the upload date. A drill run in February, documented in June, is June evidence in most tools. Record the collection date separately.
• One drill “covers” every system. Restoring the wiki does not prove the payment database restores. Scope per system, or at least per system class, and let each control link carry its own newest evidence.
• The good news is filed, the gap is e-mailed. The report says “successful”; the “except the last 6 hours of transactions” lives in a thread. Put the gap in the record, as a finding.
• Recovery environment not stated. DORA asks for segregation; a restore into production proves less than a restore into the recovery site. Say which.

A drill record, in one paragraph

On 2026-05-14 the payments database (pg-primary, production) was restored from the 2026-05-13 02:00 backup into the segregated recovery environment; restore completed in 47 minutes against a 60-minute target; row counts matched except the audit-log partition for the previous 4 hours, which was recovered from the WAL archive by 09:20. Finding: WAL archive retention set to 24 h, target 72 h — owner platform team, due 2026-06-30. Evidence linked to control “Backups restorable” (DORA Art. 12; NIS2 21(2)(c); A.8.13) and to asset pg-primary. — That paragraph is worth more than a year of green dashboards.

In Secantra

An evidence item carries a collection date and up to ten attachments, and links to the control, the requirement, the asset, the assessment or the finding it supports; a control’s newest evidence date is what recency is measured against, and a control whose evidence has aged past its review period is flagged as stale — a control with no dated evidence is reported as uncovered, never as “fine”. Gaps found in the drill are findings with severity, owner and status, linked to the asset or control; the actions that close them carry due dates. Nothing in the product runs the restore for you; it makes sure the restore you ran still counts next year.

Checklist

• Every restore drill recorded with its collection date, scope (asset, backup, target environment) and outcome
• The drill linked to the “backups restorable” control and, through it, to DORA Art. 12 / NIS2 21(2)(c) / A.8.13
• Every gap in the drill logged as a finding with an owner and a due date
• Drills scoped per system or system class — one restore does not cover the estate
• Recency measured from the drill date against the control’s review period, not from upload