Ask whether critical systems are backed up and the answer is almost always yes. There is a backup tool, a schedule, and a report showing green ticks every morning. Audit evidence for this control is easy to collect and easy to accept.
Yet when ransomware strikes, many organisations discover that the backups are encrypted along with everything else, that a restore takes weeks rather than hours, or that nobody has the passwords and runbooks needed to rebuild. The backup existed. Recovery did not.
That gap is the difference between having copies and being resilient. Auditors who only look at backup success reports are testing the copy. What the business needs is the restore.
Why green ticks mislead
A successful backup job means data was copied somewhere. It does not mean the copy is complete, readable or recent enough to be useful. It does not mean the copy survived the attacker, who increasingly targets backup systems first precisely because they are the victim's way out. And it says nothing about how long a full recovery would take, or in what order systems must come back.
Recovery also depends on things that are rarely backed up with the same care: directory services, encryption keys, configuration, licence files, network settings and the people who know how to put it all together.
What auditors should test
1. Coverage against what matters
Start from the list of critical business services, not the backup tool's job list. Trace each service to the systems, databases and cloud platforms it depends on, and confirm each is backed up. Software as a service platforms are a frequent blind spot, because many teams assume the provider protects their data for them.
2. Protection from the attacker
Check whether at least one copy is immutable or kept offline, so it cannot be changed or deleted even by an administrator. Look at who can access the backup platform, whether it uses separate credentials from the main environment, and whether multifactor authentication protects it. If the same compromised administrator account can reach production and backups, both will fall together.
3. Real restore tests
Ask for evidence of restores, not backups. A good test restores a complete system, not a single file, and proves the application actually works afterwards. Look at when each critical system was last restored, how long it took and what went wrong.
4. Recovery objectives that are honest
Business continuity plans state recovery time and recovery point objectives, often agreed years ago. Compare them with restore test results. If the plan says four hours and the last test took three days, the plan is a wish, not a capability.
5. The rebuild, not just the data
Recovering from a major attack often means rebuilding the environment from scratch. Check that runbooks exist, that they are stored where they can be reached when systems are down, and that critical credentials and keys are recoverable. Confirm that more than one person can perform each step.
Four questions for leadership
- When did we last restore our most critical system in full, and how long did it take?
- Could an attacker who controls our network also delete or encrypt our backups?
- Do our stated recovery times match what our tests actually show?
- If every system went down tomorrow, which would we restore first, and who decides?
Backups remain one of the most important controls an organisation has. But their value is only realised on the day they are needed, and that is the wrong day to find out they do not work. Audit the restore, protect the copies from the attacker, and make recovery times honest. That is what turns a nightly green tick into genuine resilience.