Many organizations believe they are protected from ransomware simply because they have backups. On paper, that sounds reasonable. Backup jobs run, storage exists, retention is configured, and every morning someone sees the green status that everything completed successfully. That usually creates a sense of security. Until something actually happens.

The problem is that backup and recovery are not the same thing, even though many people treat them as if they are. Backup answers one question: did we save the data? It does not answer the harder one: can we bring everything back when the whole environment is under pressure? That difference becomes very clear during a serious incident. In many environments, backup is seen as a technical requirement that simply has to exist. The system shows successful backup jobs, administrators see that everything is running, and management assumes recovery is covered. But the real problems usually start when the system actually needs to be restored.

One of the common scenarios seen after ransomware incidents is that backups exist, but they can no longer be trusted. Not because the backup failed, but because the attacker reached it too. If backup infrastructure sits too close to production, uses the same access paths, or depends on the same privileged accounts, it can easily become part of the same incident. At that point, the backup technically still exists. But it no longer helps. Another issue appears when the restore works, but the system still does not. The data comes back, the application starts, but something around it no longer fits. A certificate has expired. A DNS record is missing. An integration points to an old address. The database version no longer matches. On paper, the restore was successful. In reality, the business is still down. This is the part many organizations underestimate. Recovery rarely means simply “bringing back the data”. You have to bring back everything around it too.

Time is another problem that often gets ignored until it becomes real. Restoring several terabytes of data sounds simple until you need to do it under pressure. What looks like a six-hour process on paper can easily turn into two days. And when critical systems are involved, two days are not just downtime. That means lost revenue, lost trust, and growing pressure. This is where chaos usually starts. What do you restore first? Email? Domain controllers? File servers? ERP? Most organizations do not have a clear answer until an incident forces them to decide. And that is usually where the most time gets lost.

In practice, AresISEC often sees organizations with technically healthy backup systems but no realistic understanding of what recovery would actually look like under pressure. The backup itself is usually not the problem. The real issues are access, dependencies, recovery time, and the order in which systems are brought back. That is where the real gap usually appears. A good starting point is not buying another backup solution. A good starting point is asking simple questions. How isolated is your backup from the production environment? Who has access to the backup infrastructure? How often do you test a full restore instead of only recovering single files? How long would it actually take to bring back your most critical systems? And if multiple systems fail at once, does the team know what comes first? These are not complicated questions, but they quickly show whether recovery is real or only assumed.

In many cases, small changes make the biggest difference. Separating backup access from the main environment, reducing privileges, defining recovery priorities, and testing restore processes under realistic conditions often improve resilience more than adding another tool. This also connects directly to broader security and compliance requirements. Under ISO 27001, backup and recovery are not just operational tasks. They are part of business continuity, system availability, and organizational resilience. Controls around backup protection, restoration capability, and regular testing are part of maintaining a functioning information security management system. NIS2 goes a step further. It explicitly requires measures related to backup management, disaster recovery, and crisis handling as part of operational resilience. This means recovery is no longer just a technical recommendation. For many organizations, it is becoming a regulatory expectation. In both cases, it is not enough to simply have backups. The expectation is that recovery is realistic, tested, and capable of supporting business continuity when systems fail. That is where many organizations discover the difference between what exists on paper and what actually works.

Because when things go wrong, the value of backup is not measured by whether it exists. It is measured by how quickly it gets you back to work.

Sources:

CISA – Stop Ransomware Guide

ISO – ISO/IEC 27001 Information Security Management

European Union – NIS2 Directive