Every October, the security industry throws itself a party. Cybersecurity Awareness Month arrives, the posters go up in the break room, the annual training module gets assigned, someone fires off a simulated phishing email, and by November we all go back to whatever we were doing. I have been on both sides of that ritual, and I want to spend this year’s October talking about the least glamorous question in my entire field.

When was the last time you watched someone restore something?

Not verify a backup job. Not review a green checkmark in a console. Not read a report that says the nightly run completed successfully. I mean: when did a human being in your organization take a real system, wipe it, and bring it back from backup while a clock was running and other people were waiting? If you cannot remember, you are in the majority, and that majority is the reason so many incidents turn into catastrophes.

Confidence Is Not a Control

There is a number I have not been able to stop thinking about all year. In Veeam’s Data Trust and Resilience Report 2026, ninety percent of security leaders said they were confident they could recover quickly from an attack. Only twenty-eight percent of organizations actually hit by ransomware fully restored their data, and the typical victim got back about seventy-two percent of what was lost.

Sit with that gap for a second. Nine out of ten leaders believe. Fewer than three in ten deliver. That is not a technology failure. Backup software in 2026 is extraordinary, and I say that as someone who spends real money on it. That is a verification failure. We have built an industry-wide habit of treating the existence of a backup as equivalent to the ability to recover, and those two things have almost nothing to do with each other.

The attackers figured this out well before we did. Veeam’s research has found backup repositories targeted in the overwhelming majority of ransomware incidents, with an average of about a third of repositories modified or deleted when the threat actor got to them. Modern ransomware is not really a data-encryption business. It is a recovery-destruction business. Encrypting your production environment is the easy half. Making sure you cannot come back without paying is the real product, and it’s built on the assumption that your backups are less defended, less monitored, and far less tested than the systems they protect.

Where Ransomware Recovery Plans Fall Apart

I have sat in enough post-incident conversations to tell you that recoveries rarely fail for exotic reasons. They fail for boring ones, and the boring ones are always discovered at the worst possible moment.

The backup service credentials turn out to be a standing domain administrator account, which means the same compromise that took production also owned the recovery path. The immutability setting everyone assumed was enabled was enabled on one repository, not the other. The restore runs, but nobody has ever measured how long a full restore actually takes over the link you have, and the honest answer turns out to be days rather than the hours in the plan. The database comes back clean, and the application in front of it does not, because nobody documented the order of operations. The last person who knew how any of this worked left the company in March.

And underneath it all sits the most expensive problem of the bunch: the recovery objectives written in the plan were never reconciled with what the business actually needs. Veeam found that 90% of leaders were confident they could meet their defined recovery time objectives, while only 69% said those objectives were fully aligned with business continuity goals. Hitting a target that was never the right target is a very elaborate way to still be down.

The cost of getting this wrong is not abstract. Average downtime following a ransomware attack runs in the neighborhood of three weeks, and organizations that regularly test their backups cut that timeline dramatically. Three weeks is not an IT problem. Three weeks is a revenue problem, a client-retention problem, and for some organizations an existential one.

The Exercise I Would Run This Month

Here is what I would ask of any executive reading this, and it costs you an afternoon rather than a capital request.

Pick the one system your business genuinely cannot operate without. Not the one that is easiest to test. The one that would empty your building if it disappeared on a Tuesday morning. Then ask your team to restore it from backup to a clean, isolated environment, with a stopwatch running, and with the assumption that the production domain and the administrator account you normally use are both compromised and unavailable.

Then be in the room while they do it.

That last part matters more than anything technical I could tell you. A restore test with leadership watching stops being a checkbox and becomes a conversation about the business. You will learn your real recovery time, not your aspirational one. You will learn whether your recovery path depends on the very identity infrastructure an attacker would target first. You will discover which documentation is fiction. You will see, in real time, the difference between the plan and the practice, and you will see it on a day when nothing is actually on fire, and nobody is losing money by the hour.

Write down what you learn. Write down what broke. Then put a date on the calendar to do it again in ninety days, and hold that date the way you would hold a client deadline.

Cybersecurity Awareness Month: Don’t Make It Easy for Them

The National Cybersecurity Alliance built this year’s Cybersecurity Awareness Month around a theme I have grown fond of: “Don’t make it easy for them.” Most of the conversation around that theme lands on passwords, multifactor authentication, patching, and phishing, and it should. Those four habits still stop most attacks.

But there is a fifth habit that belongs in that company, and it is the one nobody puts on a poster. A tested, isolated, immutable recovery capability is the single control that takes away an attacker’s leverage entirely. It is what turns the worst week of your year into a bad week instead of a negotiation. And unlike almost everything else in security, you cannot buy it. You can only prove it.

So this October, before you assign the training module, go restore something. Watch it happen. Find out what you actually have.

Because the backup you have never restored is not a backup; it is a hope with a license agreement.

— Chris Hippensteel | Director of IT

We invite you to connect with Chris via email or LinkedIn.