How much do you trust your backups? This is a crucial question that many businesses overlook until it's too late. There's a common misconception in operational technology (OT) environments that a completed backup guarantees a recoverable system.
A green flag on a dashboard may suggest a successful backup, but without continuous testing and validation against current OT conditions, the recovery aspect—the most vital part of a backup and recovery strategy—remains uncertain. The more complex the environment, the slimmer the chances of a successful recovery.
This is especially true in critical infrastructure such as factories, hospitals, labs, and transport networks, where the underlying architecture is often more fragile and diverse than standard enterprise IT. Many systems that support production or safety rely on legacy technologies that are difficult to virtualize or replace.
A backup from these environments may seem intact, but without validation, there's no way to know if the data is corrupted, if drivers are missing, or if images are incomplete.
These issues typically surface only when an incident occurs, turning what should be a “backup and recovery” process into a “disaster recovery” scenario.
Many organizations mistakenly treat a completed backup as definitive proof of resilience. They see the green light, assume the process has worked, and trust that everything will function as expected if something goes wrong.
This is a significant amount of trust to place in a basic backup process, especially as the threat landscape expands faster than legacy-heavy OT environments can adapt. Last year, nearly one-third of global ransomware attacks exploited unpatched vulnerabilities.
Cybercriminals are also four times more likely to target end-of-life systems, which now includes Windows 10 as of October 2025. For organizations lacking a continuously validated backup and recovery process, the risks are escalating.
OT environments face challenges that traditional IT rarely encounters. Any disruption can have immediate financial or safety implications, making them prime targets for ransomware groups that know manufacturers, hospitals, and logistics providers cannot afford extended downtime.
The convergence of OT and IT only broadens this attack surface, creating a scenario where even minor configuration drift or unnoticed corruption can have significant consequences. In this context, treating a green tick as proof of resilience simply doesn’t hold up.
Why OT Recovery Is Never as Simple as It Seems
The reality is that a company’s technology stack is rarely as modern as it appears. Critical processes often depend on unsupported operating systems like Windows XP or Windows 7, bespoke embedded editions, or equipment controlled by aging Programmable Logic Controllers (PLCs).
Support for Windows XP ended in 2014, yet many organizations still operate XP-dependent devices. These systems often rely on fragile chains of custom drivers and proprietary interfaces that may not have been manufactured for years.
Documentation is frequently lacking, and the engineers who originally configured these systems have long since moved on. What remains are inconsistent system states that cannot easily be transferred to new or even slightly different hardware during a crisis.
Some OT environments limit change by necessity. Hospitals must avoid patching certain devices to maintain certification; manufacturing lines depend on chipsets that cannot be virtualized; air-gapped or remote sites rely on images that may not reflect current conditions.
In these instances, a backup that “succeeds” is often merely one that didn’t encounter an obvious error—not one that can actually be restored.
Production lines, clinical systems, logistics hubs, and industrial control networks aren’t designed with pause buttons. Even brief outages can lead to missed quotas, stalled deliveries, spoiled batches, safety risks, or overtime recovery costs.
This is why ransomware campaigns increasingly target OT systems: they understand the business impact is so severe that many organizations will pay simply to resume operations.
The Jaguar Land Rover incident, referred to by some as “the most costly cyberattack in UK history,” exemplifies this point. When production was disrupted due to unprepared OT processes, delays cascaded across supply chains and dealer networks for weeks.
This incident highlighted a truth the OT sector knows all too well—once operations halt, the financial and operational damage continues long after systems are back online.
Without proof that systems can be reliably restored, organizations are effectively gambling their production schedules, reputation, and revenue on the hope that the restore will function when needed most.
How to Validate Your Backups
So how do you actually validate? It's not a single test—it's a systematic process that progresses from quick checks to full-scale recovery drills. Here's how:
Start with Integrity Checks Run hash verification or checksum comparisons to ensure that backup data matches the source and hasn't been corrupted. This catches silent data degradation—file corruption, partial overwrites, and unexpected changes that may go undetected for months.
Move to Virtual Test Restores Boot a backup in an isolated virtual environment to confirm that operating systems, drivers, and applications load as expected. This reveals missing dependencies, configuration issues, and service initialization failures that integrity checks can't detect.
Test on Actual Hardware Restore to the same type of production hardware you'd use in a real recovery. This exposes physical dependencies that virtualization masks: driver compatibility issues, firmware mismatches, and hardware-specific configurations. A backup that boots in a VM might fail entirely on real hardware.
Run Full Recovery Drills Restoring one system is different from restoring 20 or 200. Test scenario-based drills that mirror real incidents—ransomware, site failures, supply chain disruptions—and document how long recovery actually takes versus your RTO targets.
Build It into Incident Response Train teams on which backups to use in different scenarios, how to isolate compromised systems, and how to restore in the correct order. Make recovery a reflex, not something to figure out in a crisis.
Document and Refine After every test, record what worked and what didn't. Update your runbooks, incorporate lessons into your backup schedule and storage choices, and create a cycle of continuous improvement. The 3-2-1-1-0 model captures this in its final digit: zero errors.
When organizations rehearse these restores systematically and refine their processes based on results, they transform backup and recovery from a box-ticking exercise into a resilient operational function. Validation provides certainty, not hope, that recovery will work when it truly matters.
The Green Light Means Nothing
As a backup and recovery expert, I emphasize that you shouldn't just trust me—or anyone who claims your backups will work when needed.
In terms of operational resilience, organizations should operate with zero trust until they can prove to themselves, and demonstrate to others, that they can recover exactly as needed. Trust is what you place in a green light on a dashboard. Proof is what you earn through testing and validation.
In OT environments where downtime is detrimental, where legacy systems cannot be easily rebuilt, and where attackers target the most vulnerable points—proof isn't optional. A completed backup offers reassurance. A validated backup offers certainty. And in critical infrastructure, only certainty keeps operations running.
We've featured the best cloud storage.
This article was produced as part of our publication's Expert Insights channel, where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of our publication. If you are interested in contributing, find out more here.