Ask an organization whether it has backups and the answer is almost always yes, delivered with justified confidence. Something runs nightly. It reports success. Somebody would notice if it stopped.
Ask when a file was last restored from one of those backups, opened, and checked by a person who knows what it should contain, and the answer is usually a pause.
That pause is the single most consequential gap in most small-organization technology arrangements, and it is also among the cheapest to close.
A backup is a job. A restore is a file.
A backup job reports on itself. It says it ran, it says it succeeded, and both statements can be true while the thing it produced is unusable.
The ways this happens are unremarkable and common. A folder was excluded during a migration and never added back. The job captures the application's files but not the database it needs. Retention was shortened to control cost and the copy you need is older than the window. The backup runs to a location the same administrator account can delete. The restore works but takes four days, which is fine for a document and not fine for the system your on-call staff use tonight.
None of these announce themselves. Every one of them is invisible until the day you need the data, which is the worst possible day to discover it — and the only day on which the discovery cannot be undone.
The test, and what makes it real
The test is not complicated. It is a person, choosing a file, from a date they did not plan for, and opening it.
Four things make it a real test rather than a ritual:
Somebody else picks the date. A restore from last night proves less than a restore from six weeks ago, because the failures that matter are the ones that have been quietly running for a while.
A person who knows the content checks it. Not that the file opened — that it contains what it should. A case record that restores as an empty template has restored successfully and is worthless.
The elapsed time is recorded. How long it took from decision to usable data. That number is the difference between a plan and a hope, and it is the one your continuity plan needs.
The result is written down. What was restored, from what date, by whom, how long it took, and what went wrong. Including the tests where nothing went wrong, because a log with no failures in it is evidence of a working control, not of nobody checking.
Two questions to ask alongside it
Could one compromised account destroy both? If the administrator account that runs your systems can also delete the backups, then the backups protect you against hardware failure and accident, and not against the scenario most likely to put you out of business. Whether that separation exists is a question for whoever administers your systems, and the answer should be demonstrable rather than assumed from a product description.
What has the vendor actually committed to? Most organizations' most important records sit in systems somebody else operates. What that vendor guarantees about backup, retention and restoration is in a contract, not on a marketing page, and it is frequently narrower than assumed. This is worth reading before you need it.
The number nobody sets
Two figures should exist for every system holding records you cannot operate without.
How long could you be without it? Not the ideal answer — the honest one, given what the service actually requires. An agency with a duty of care that runs overnight has a very different answer from an office that could work on paper for a day.
How much recent work could you afford to lose? A backup taken nightly means that on a bad morning you lose everything since last night. Sometimes that is acceptable. Sometimes it is a day of case notes that legally should exist, and nobody has ever said so out loud.
Both numbers belong to the people who run the service, not to whoever configured the backup. That is the most common inversion in this whole area: a technical decision quietly setting a service-level answer that nobody in the service was asked about.
What to do this month
Restore one file. Have somebody else pick the date, at least a month back. Open it and check the contents. Write down what it was, when it came from, who checked it, how long it took, and anything that went wrong.
If it works, you have your first entry in a log that will be worth a great deal to you at some point. If it does not, you have found out on a Tuesday, at no cost, rather than on the morning it mattered.
The cybersecurity and data protection self-assessment — fifty items across ten domains, scored on evidence rather than intention, with a workbook that ranks what to fix by what is lost when it fails — is free on the Open Shelf. It is a self-assessment, not an audit, and it certifies nothing. No registration, no email address.