Somewhere around tab nine of the questionnaire, you’ll meet it: “How is customer data backed up?” It looks like a freebie. Your cloud provider snapshots the database daily, retention is configured, the checkbox practically ticks itself.
Then comes the follow-up: “When did you last restore one, and how long did it take?”
This is where the answers stop being copy-paste. Everyone has backups: object storage made them nearly free and entirely automatic. Far fewer teams have ever pulled one back, timed it, and written down what happened. The reviewer knows this, which is exactly why the second question exists.
Why banks ask about restores, not backups
A bank buying your product is taking on your operational risk, and its supervisor holds it accountable for that. DORA makes this explicit: financial entities must ensure their ICT providers can actually recover: backup policies and restoration and recovery procedures, tested, with results. ISO 27001 says the same thing in its own dialect: the control isn’t “backups exist,” it’s “backups are tested regularly and restoration is verified.”
An untested backup is a hypothesis. The reviewer isn’t being difficult by asking for the test; they’re asking for the only piece of evidence that separates a working recovery capability from a line item in your cloud bill.
The control that passes: a quarterly restore test
The good news is that this is one of the cheapest real controls in the entire questionnaire. Not a disaster-recovery programme, not a second region on standby. A scheduled, recorded restore test:
- Pick the system that matters. The production database holding customer data, the one the bank cares about, not your marketing analytics.
- Restore it somewhere isolated. A scratch environment or a temporary instance. You’re proving the backup opens, not rehearsing a failover.
- Time it. From “we need the data back” to “the data is usable.” That number is your honest recovery time, and you’ll want it later for continuity questions too.
- Spot-check the contents. Row counts, a handful of recent records, one integrity check. Enough to show the backup isn’t silently empty or truncated.
- Write it down and book the next one. A calendar recurrence every quarter. The record is the control.
The record doesn’t need a template committee. One page covers it:
Restore test record · Q3 2026
- System
- Production PostgreSQL (customer data)
- Backup restored
- Nightly snapshot, 14 July 2026
- Restored to
- Isolated staging instance
- Time to usable data
- 41 minutes
- Verification
- Row counts matched; 20 recent records spot-checked
- Run by
- CTO · next test booked 14 October
When the questionnaire asks about backups, you attach this. When the reviewer asks the follow-up on a call, you have a date, a duration, and a name. The conversation moves on, which is the entire point.
What this buys you beyond one row
The restore test is a small control, but it does outsized work in a review:
- It converts three or four separate questionnaire items (backup policy, backup testing, recovery time, continuity evidence) into one artefact you already have.
- It signals the thing reviewers are actually probing for: that your security posture exists in practice, not just in prose. Teams that test restores tend to be teams whose other answers hold up too.
- It gives you a real number for the recovery-time questions, instead of an optimistic guess that a technical interview can take apart.
This is what “minimum viable compliance” means in miniature: not the biggest control you can describe, but the smallest one that is true: implemented, evidenced, and sized to what the review actually checks. An afternoon per quarter, and one of the most common stall points in a bank review becomes one of your fastest answers.