Summary
- Backups provide copied data, but not proof that infrastructure, applications, access, and communications can be restored.
- Ransomware recovery costs grow during downtime as orders, finance operations, reporting obligations, and staff access are disrupted.
- Businesses need realistic restoration testing to understand recovery sequences, dependencies, and tolerable outage windows.
The backup has become one of the most misunderstood safeguards in modern cyber security.
Ask any organisation how it would respond to a ransomware attack and you can be certain that the answer will involve backups. The backup is seen as an implicitly ‘good thing’; the ultimate safety net, and proof that, even if the worst should happen, a business will always have a way back.
The pervasiveness of this belief is understandable. Backups have become an essential part of every recovery strategy, and every organisation should have them. But, somewhere along the way, the backup has been adopted as the equivalent of a get-out-of-jail-free card, when, in fact, it proves only that your critical data has been copied and not that your business can recover.
That is a critical distinction that can go unrecognised until the exact moment that recovery plans need to be implemented, since the process of restoring from backup may not be as quick, straightforward, or reliable as businesses often believe.
Do we have backups?
Do we have backups? An answer in the affirmative can do much to settle nerves, and reassure investors and customers. But it’s the wrong question to ask. A far better one would be: If our systems were to suddenly become unavailable tomorrow, how quickly could we restore those parts of the business critical to operations?
While backups constitute one part of the recovery toolkit, recovery itself is a real operational challenge. It involves restoring infrastructure, applications, user access, communications, and countless other interdependent systems that allow a business to function. Simply ensuring you have copies of your data tells you very little about how that recovery process will unfold, particularly when the pressure is on.
Ransomware can cause huge damage at the point of infection, but its costs continue to accumulate in the aftermath, as customers are left waiting for existing orders, new orders can’t be processed, financial operations stall, and staff lose access to critical systems. For businesses working in regulated sectors, reporting obligations remain, regardless of the fact that systems are offline.
As time passes, against a backdrop of increasing stress and pressure, these difficulties are increased and the value of any recovery strategy is proven, or not.
Testing in real life
On paper, most backup strategies look sensible and comprehensive. Backups are scheduled automatically. Reports confirm they have completed successfully. Copies exist in multiple locations. Policies are documented, accessible, and regularly reviewed.
But backups can be incomplete and they can fail without anyone noticing. Restoration timescales are often far longer than forecast, particularly where large volumes of data or multiple business-critical systems are involved.
Even when the backup process is successful, most businesses will find that their applications have dependencies; that there are functional issues around network infrastructure, or that system restoration is contingent on a necessary sequence that must be followed, lest restoring the wrong things in the wrong order create further delays.
These are the practical realities of recovery that organisations only encounter for the first time during a live incident. They have real consequences, and some very major international organisations have fallen foul of them.
That is precisely the problem. If the first time you discover whether your recovery strategy works is after a ransomware attack, you’ve effectively left resilience to chance.
Prevention is better than the cure
For SMEs, this challenge is amplified by their limited access to resources.
Large organisations have dedicated disaster recovery specialists, documented recovery playbooks, and teams responsible for testing restoration procedures. Smaller businesses typically lack that internal capability. Instead, decisions are made under pressure, often by people balancing recovery alongside their everyday responsibilities.
It’s easy to see why preparation tends to focus on prevention instead. Cyber security functionality tends primarily toward firewalls, endpoint protection, and threat detection. These are essential investments, but ones which encourage businesses to think about stopping attacks, rather than surviving them.
The truth is that no security provision will eliminate risk entirely. A good recovery strategy has to assume that, sooner or later, an attack will happen, and that attack will succeed.
This requires a different mindset. Organisations need to look beyond the backup and ask harder questions about what recovery would actually involve. Which systems need to return first? How long could the business operate without them? Who makes those decisions? Has the restoration process ever been tested under realistic conditions?
False confidence is a risk
Perhaps the greatest risk isn’t the absence of backups, but the confidence they create.
The presence of backup infrastructure can encourage organisations to believe they are prepared long before that preparedness has been proven. Successful backup may reassure, but it narrows focus from the wider threat landscape and it decreases vigilance toward new threats and new potential solutions.
Resilience is demonstrated by an ability to resume operations within a timeframe that a business can realistically tolerate, and the only way to measure that capability is to test it.
Recovery from a ransomware attack is impossible in the absence of backups, but they’re just the first step.
