Almost every company today has a backup that reports "success". The green ticks in the dashboard are reassuring: jobs run overnight, finish without error, someone glances at them now and then and nods. The problem is that a backup job finishing "green" and a backup you can actually recover from are two different things — and the gap between them is measured precisely on the day of the incident, when it is too late to find out.
A backup audit starts from that uncomfortable question: not "do you have a backup?", but "can you prove you recover from it, fully and in time?". The difference is not semantic. It is the difference between surviving a ransomware attack and closing the company.
What the 2025-2026 data shows
Recent statistics are unpleasantly consistent. 2025 reports show that only about 61% of restore attempts reach the desired outcome — in other words, nearly 4 in 10 restores fail when you actually need the data. And the main reason is not that the technology is bad, but that nobody verified it beforehand: over 60% of organisations do not run regular restore exercises, and only half test their recovery plan even once a year.
When the moment of truth arrives, the gap becomes brutal. A Veeam study of 1,300 organisations found that only 10% recovered more than 90% of their data after an incident, while 57% recovered less than half. Even more telling: over 60% of companies believe they can recover within hours, but only about 35% actually do. The rest discover, under pressure, that "we have backup" was not a plan — it was a hope.
An unverified backup is not a backup. It is an assumption you test for the very first time on the exact day you cannot afford to be wrong.
Why a "green job" lies to you
A backup job reports that it copied the data — not that you can use it again. Between the two hides a whole list of silent failures that a green dashboard never catches:
- Corrupt or incomplete files: the job finishes "successfully", but the archive is corrupt, a database is inconsistent, or exactly the critical files are missing.
- Untested restore: nobody ever tried to bring the data back, so nobody knows how long it takes or whether it works.
- Undefined RPO/RTO: you do not know how much data you can afford to lose, nor how fast you must be operational — so you cannot know whether the current backup is enough.
- Backup reachable by the attacker: if the backup sits on the same network with the same credentials, ransomware encrypts it along with production. Studies show roughly 96% of ransomware attacks directly target backup copies.
- Coverage gaps: employee laptops, Microsoft 365 / Google Workspace mailboxes, SaaS apps or new servers are not in the backup at all — because nobody updated the scope.
- Configuration drift: the backup was set up correctly two years ago, but servers, licences and priorities have changed since, and nobody re-checked.
None of these problems shows up as an error. They all live quietly behind the green tick, until the day they matter.
What a backup audit checks
A backup audit does not look at the dashboard and take your word for it. It inventories your real strategy and puts it to the test. Concretely, a serious audit covers seven areas:
1. A real restore test, not on paper
The centrepiece. Data is actually restored — files, a database, a virtual machine — and verified to be intact and usable. Without a restore test, everything else is theory. This is where most surprises surface.
2. RPO and RTO validation against real need
RPO (how much data you can afford to lose) and RTO (how fast you must return) are not technical settings but business decisions. The audit measures how long a recovery actually takes and compares it with what the company can afford — not with what it hopes.
3. Complete data coverage
It checks what goes in and, more importantly, what does NOT: servers, databases, endpoints, but also cloud data. Many companies wrongly assume that Microsoft 365 or Google Workspace "back themselves up" — responsibility for your data stays yours.
4. Immutability and isolation (anti-ransomware)
At least one copy must be immutable or air-gapped — impossible to delete or encrypt by an attacker, even one who gains admin rights. It is the line of defence that turns ransomware from a catastrophe into an inconvenience; immutable copies significantly cut recovery time (studies indicate a reduction of around 42%).
5. Retention and versions
How long you keep copies and how many versions you have matters enormously. Many attacks lurk for weeks; if retention is too short, your only copies are already infected. The audit checks whether you can return to a clean point, from before the compromise.
6. Encryption and data location
The backup must be encrypted (in transit and at rest), and the data location must be known and compliant — increasingly important under NIS2 and GDPR, which expect data to be kept in the EU and evidence that it cannot be tampered with.
7. Documentation, runbook and an owner
Who restores, from where, in what order, with which credentials? If the answer lives only in the head of someone who is on holiday on the day of the incident, you do not have a plan. The audit checks for a written runbook and a clear owner.
How often should backups be tested
The classic 3-2-1 rule (3 copies, 2 different media, 1 off-site) evolved in 2025 towards 3-2-1-1-0: one more immutable/offline copy and — crucially — "0 errors", meaning automated verification that confirms the backup can actually be restored. An unverified backup does not count.
A practical testing cadence, adapted to system criticality:
- 1Monthly — restore verification of files and everyday data.
- 2Quarterly — application-level recovery test for critical (Tier-1) systems.
- 3Annually — a full failover exercise of the entire environment, as a rehearsal for a real disaster.
Backup, restore and compliance (NIS2)
For a growing number of companies, testing the backup is no longer just good practice but an obligation. The NIS2 Directive requires, through Article 21, explicit business continuity policies including backup management and disaster recovery. In practice, auditors expect evidence: a documented backup policy with RPO/RTO, restore tests with measured times, at least one immutable copy and data kept in the EU. Penalties for essential entities reach up to €10 million or 2% of global turnover — one more reason for "we have backup" to be a statement you can prove, not just utter.
From audit to a backup you trust
The good news is that a backup audit is fast and cheap compared with what it prevents. In a few days you learn exactly where you are exposed, with a prioritised vulnerability report and a remediation plan with deadlines. That is exactly what we deliver in the backup & restore audit package: a complete inventory of your current strategy, a real restore test (not on paper) and a concrete plan. If the result shows something must be rebuilt, we do it within a data protection project, with a 3-2-1-1-0 strategy, immutable copies and tested runbooks.
The best time to find out whether your backup works is not during an attack. If you have never tested a full restore, let us talk for 30 minutes — I will tell you concretely what to check first.
Conclusion
The green tick in the dashboard tells you the data was copied. It does not tell you that you can bring it back. The 2025-2026 data shows that this difference catches most companies unprepared precisely when the stakes are highest. A backup audit turns "I hope it works" into "I know it works, because I tested it" — and it is the cheapest insurance you can buy against the most expensive day in your company's life.