Ask any company if it has backup, and almost every one says yes. It's the easiest answer to give and the least verified of all — the automated report shows up green every morning, and nobody ever tries to open the file it claims to have saved.
Veeam's 2025 Ransomware Trends report surveyed 1,300 organizations worldwide, 900 of which had been hit by ransomware — data hijacking, where a program scrambles a company's files and demands payment to unlock them — in the previous year. Among those 900, only 10% recovered more than 90% of the affected data, and 57% recovered less than half. The backup existed. The recovery didn't.
For whoever approves the budget, that number changes the question. It's no longer "does the company have backup?" — almost everyone already answers yes to that. It's "has anyone actually tried to bring the data back, before the day it becomes mandatory?" As long as the answer is no, what exists is a well-kept assumption, not a guarantee.
A green report proves nothing
CERT.br, Brazil's security incident response group, recommends the 3-2-1 rule as a baseline: three copies of the data, kept on two different media types, with at least one off-site or disconnected. It's a good starting point — but that rule describes where to store the copy, not whether anyone has tried to bring it back. The two questions are not the same.
A backup job can finish with no errors and still be useless at restore time: a corrupted file, the wrong version, a piece of the system left out. The process that runs overnight proves the data was copied. It doesn't prove anyone can bring it back.
A global 2025 survey by Unitrends, with more than 3,000 IT professionals worldwide, measured exactly that gap between believing and knowing. More than 60% believed the company could get back up within hours after downtime. In practice, only 35% managed to do so within that window.
The same survey found the most obvious reason for that gap: 25% of the companies surveyed test disaster recovery once a year or less. The rest of the time, confidence in the backup comes only from the automated report — never from an actual attempt to bring the data back.
Veeam's report showed the same problem from another angle. Of the attacked companies, 98% had a written ransomware response plan, but less than half of that plan covered the elements considered essential: only 44% included a backup verification step before declaring recovery complete. Having the plan on paper and testing what it describes are two different things.
The US standards body's own security framework (NIST) treats this test as a requirement, not an optional best practice: it calls for a sample of backup data to be used to restore parts of the system as part of contingency planning, with the result checked before any real emergency. It doesn't need to happen all at once. It needs to happen for real.
What most companies do today
The common approach, in practice, is this: the backup runs overnight, the report shows up in the morning, and nobody touches it again until the day the files disappear. Whoever handles IT — sometimes an employee from another department, sometimes a provider who only shows up when called, sometimes the person on the team who "knows more about computers" — treats "the backup is running" as if it meant "the company is protected." Nobody asks whether that same person has ever tried a restore, or what would happen if they were on vacation the day it goes down.
The US government's own ransomware response guide is blunt about why that confidence is risky: many ransomware variants search for and delete or scramble any backup copy they can reach on the network. If the backup stays connected and visible at all times, it's a target for the same attack that wiped out the original files.
The result is a quiet trap. The company feels covered because the email arrives green, and only finds out it isn't at the one moment that truly matters: in the middle of downtime, with people waiting, a customer on the phone, and no one knowing how much longer the system will be down.
What has to be in place
A backup that survives a bad day is defined by verifiable mechanisms, not the color of a report.
A full restore, simulated separately. It's not enough to copy one file to check it opens; the whole system needs to be rebuilt in an environment separate from production, to see if it comes up and works like the original.
Verification that what came back actually works, not just that the process finished. Someone checks that the spreadsheet opens, that the database comes up, that the system recognizes the data. "Finished with no errors" and "actually works" are different things, and only the second one counts.
Restore time measured with a stopwatch, not estimated. Track how long the process really took during that test, and compare it against how long the plan promises before the company is back up. Without that measurement, the plan is an opinion about the future, not a tested number.
A scenario where the most recent copy is compromised. The test also needs to plan for the attack reaching the newest backup, with the restore starting from an earlier copy kept out of reach of whoever broke in.
A record of every test, with the date and what didn't work. Without it, every attempt starts from zero, and the memory of "we tested this once" is worth less with every month that passes.
This is how Skills IT works: with periodic recovery simulations, run separately from the production environment, and a record of every test and whatever needed adjusting afterward.
What the company gains from this
The most direct gain shows up at the worst possible moment to be missing it: when the system actually goes down, the team already knows the steps and already has a real sense of how long the return usually takes, instead of finding all of that out under pressure, with a customer on the phone.
There's a financial gain that comes with it. A company that has already tested its restore process can estimate, with some accuracy, how much each hour of downtime costs — and use that information to decide whether it's worth investing in faster recovery for a specific system, or whether the current timeframe is acceptable. Whoever has never tested decides in the dark, usually buying another product after the scare. Multiply that by downtime hours, unbilled orders, and staff standing around waiting for the system to come back, and the math is clear: testing costs something predictable and small; not testing only shows its cost at the worst possible hour, with no warning.
There's also an effect on decision-makers. An owner or director who receives a documented restore test — what worked, what didn't, how long it took — has something concrete to discuss with finance and with customers who ask about business continuity. Whoever only has the green backup report has a talking point, not an answer.
A roadmap to get started
Before the next continuity meeting, these four questions put the topic where it belongs:
- Ask to see a restore happen, not just the report. Set up a real demonstration: bring back a non-critical file or system, from scratch, in front of whoever approves the budget.
- Ask when someone last tested it. If the answer is "never" or "I don't remember," that's already the answer the company needs to hear.
- Find out whether the test covers an attack scenario, not just a hardware failure. A burned-out drive is different from an intruder who deleted the most recent copy before leaving.
- Put the next simulation on the calendar, with a fixed date. A test with no date becomes a promise; a date on the calendar becomes a routine.
