“We have backups.” It’s one of the most common reassurances I hear when speaking to businesses about cyber security and resilience. Usually said confidently. Sometimes with a sense of relief, as though the difficult part has already been solved.
And to a degree, that confidence is understandable. If you’re like most businesses, you’ve invested in some kind of backup solution. You have a copy of your data sitting somewhere else. Reports are coming through. Files can be restored if someone accidentally deletes them. On the surface, everything seems to be covered.
But this is where one of the biggest misconceptions in cyber security starts to emerge: backup and recovery are not the same thing.
Over the years, I’ve worked with organisations of all sizes on backup, business continuity and operational resilience. And one thing I’ve seen repeatedly is that many businesses discover the gap between backup and recovery the hard way: during a live incident, when systems are unavailable, customers are affected, leadership teams are under pressure, and calm decision-making has gone out of the window.
That’s the moment businesses move from asking: “Do we have backups?” to: “How quickly can we actually function again?” Because a backup is simply a copy of your data. Recovery is your ability to restore business operations when something goes wrong.
In this article, I’ll unpack why that misunderstanding exists, how it creates a dangerous false sense of security, and what you should be thinking about if you want to recover calmly, quickly and effectively when the worst happens.
The dangerous assumption behind “we have backups”
Backup is storage. Recovery is operational continuity
Why Recovery Time Objectives matter more than most businesses think
The first full recovery test should never happen during an incident
Why attackers increasingly target backups first
Resilience is about reducing operational dependency
Thinking that having backups in place automatically means that your company data is secure and can be retrieved at any time is just human nature. You may buy a backup solution and assume it will do exactly what it says on the tin. Which sounds perfectly reasonable, until you start unpacking what “recovery” means operationally.
When I ask businesses whether they can recover their crown jewels, what I’m really asking is:
That’s where confidence in the backup solution starts to falter.
Many organisations have tested recovery accidentally rather than deliberately. For example, someone deletes a file or loses an email, the IT team restores it successfully, and everyone assumes the recovery process works.
But recovering a single folder is a far cry from recovering an entire business after a major outage or ransomware attack. This is where the distinction between backup and recovery becomes critically important.
I’ll admit that the cyber security industry often treats backup and recovery as though they’re part of the same conversation, which only adds to the confusion. Technically, they are quite similar, but they have different functions.
Backup is about storing a secondary copy of information somewhere safe so that it still exists if the primary copy becomes unavailable. Recovery is about how quickly, calmly and effectively you can restore operations using that backup.
But here’s where things tend to get more complicated than many businesses expect. Recovering a single file from a local backup might take minutes. However, recovering multiple servers, customer systems, operational databases, communication platforms, cloud applications, or entire mailboxes? That could take significantly longer depending on where the data is stored, how much data needs to be restored, and what infrastructure sits underneath it.
This is something many organisations don’t fully appreciate until they experience it firsthand. If backups are stored in cloud repositories or off-site environments, recovery depends heavily on connectivity. You’re now moving potentially huge amounts of data across internet connections that are also being used by the wider business. In these cases, bandwidth, recovery sequencing, application dependencies, and most importantly, business prioritisation matter.
In a real incident, not everything needs to be restored at once. The question then becomes: “What does the business need first to remain operational?” That answer is different for every organisation.
For some businesses, email and communication systems are critical. For others, it might be finance platforms, manufacturing systems, operational databases or customer contact environments. A transactional business, for example, may struggle to function at all if its core systems become unavailable. If an e-commerce platform or booking system goes offline, revenue stops immediately. Other organisations may be able to operate manually for a short period while systems recover in phases.
That’s why recovery isn’t purely a technical discussion but requires a conversation about business continuity.
With that said, Recovery Time Objectives (RTOs) become incredibly important. Now, most businesses won’t necessarily use that terminology themselves. But they absolutely understand the underlying business question: “How long can we realistically afford to be down?”
That’s what an RTO really measures. Because downtime is so much bigger than an “IT issue”, it creates operational and commercial consequences very quickly.
If systems remain unavailable for 24 to 72 hours, businesses can experience:
And again, this varies massively depending on the nature of the organisation. What matters is understanding which systems matter most, how quickly they need to return, and what “acceptable downtime” looks like commercially.
Without those conversations happening well in advance, businesses are often forced into reactive decision-making during the incident itself.
Something I often say to customers is this: You don’t want the first real test of your recovery process to happen during ransomware recovery.
Incidents create pressure very quickly: people panic, communication breaks down, decision-making becomes highly emotional, and weaknesses that could have been identified calmly beforehand suddenly become urgent, make-or-break problems.
That’s why restore testing is critical, because putting your backup to the test moves recovery from assumption to proof.
Restore testing allows organisations to understand:
Think about a fire drill. Businesses don’t wait for a real fire before teaching staff where the exits are. Recovery planning should work the same way. The businesses that recover best are rarely the ones improvising under pressure. They’re usually the ones that already know:
That preparation creates structure, structure creates calm, and calm minds prevail.
Cyber criminals understand something many organisations still underestimate: Backups are often the organisation’s failsafe. This is exactly why attackers increasingly target them first. If a ransomware group can compromise the primary environment, encrypt operational systems, and remove access to backup repositories, the pressure on the victim increases dramatically.
At that point, the situation stops feeling technical and starts becoming psychological warfare. It may sound dramatic, but in these instances, leaders now have to deal with operational paralysis, mounting downtime, customer pressure, financial impact and urgent recovery decisions. All of which ultimately puts them up against the wall and increases the chances of them giving in.
Resilience today cannot just focus on prevention. Businesses also need confidence that recovery remains possible even if prevention fails.
And this is where another dangerous assumption often creeps in. I still regularly speak to businesses that believe their Microsoft 365 data is automatically and comprehensively protected simply because it sits in the cloud. But Microsoft itself recommends maintaining separate backup protection outside of its primary environment.
Check out this article to learn more about why you need backup even if you have Microsoft 365.
Cloud availability is not the same thing as backup resilience. Which brings us back to the same core issue: A copy existing somewhere does not automatically mean the business can recover quickly or effectively.
When I speak to businesses about resilience, the primary goal is simple: reduce the number of things that can bring the business to a standstill. Because in many organisations, operational risk quietly builds over time. Through a series of sensible decisions that gradually create dependency on one: internet connection, application stack, communications platform, backup location, or even one person who understands how everything works.
The issue is that many of those dependencies only become visible during an incident.
For example, a backup strategy might look perfectly fine on paper… until the business realises recovery depends on downloading large volumes of data from an offsite repository across an already stretched internet connection. Or until a critical cloud platform becomes unavailable and nobody has properly mapped what operational processes rely on it.
So resilience has to be viewed as something broader than backup alone. It’s about understanding:
For some businesses, losing email access for a few hours may be manageable. For others, especially transactional organisations or customer contact environments, even short periods of downtime can bring the business to its knees.
That’s why resilience planning should always start with a simple business question: “What has to stay operational for us to continue functioning?”
Once organisations understand that clearly, they can start prioritising recovery properly instead of treating every system as equally important. And that’s usually where resilience starts becoming much more structured, practical and commercially realistic.
Most businesses already have pieces of resilience in place. They have backups, cyber security tooling, IT providers and operational processes. The good news is that recovery resilience rarely starts from scratch. However, many still don’t fully know whether those pieces would hold together under real pressure.
That’s the problem organisations need to solve. When a serious outage or ransomware incident happens, the question is no longer: “Do we have backups?” It becomes: “How quickly can we recover, who leads the response, and how do we keep the business operating without descending into chaos?”
This introduces the real distinction between backup and recovery. Backup is about having another copy of the data. Recovery is about restoring the business in the most structured and seamless way.
I’ve worked with many organisations that assumed recovery would simply happen because the backup existed. Take it from me, the businesses that recover best are usually the ones that have already tested their assumptions, identified their gaps and understood what operational resilience looks like for their environment.
If you’re not fully confident that your business could recover quickly, calmly and effectively after a major outage or ransomware incident, the first practical step is understanding where your recovery gaps and operational dependencies lie.
Our Cyber Security Snapshot helps businesses like yours to:
Remember, the biggest recovery risks are often the ones your business assumes are already covered (that is, right up until the moment you need to recover under pressure).