A backup is not a recovery. Can your company truly restore operations after an attack?

A ransomware incident is often associated with data encryption and a subsequent ransom demand. From a company's perspective, however, the practical consequence is even more important. Employees cannot log in, applications do not work, production or logistics lack the systems they need, and the time required to return to normal operations begins to cause financial and operational damage.

This is precisely when the difference becomes clear between a company that has backups and one that has mastered the recovery process. The first has copies of its data. The second knows which copies can be trusted, what to recover from them, in what order, and how to verify that the restored environment is secure.

Backup and recovery are not the same thing

Backup means creating an additional copy of data or a system state that can be used if the original data is lost, damaged, or compromised. Recovery is the entire process by which a company returns to an operational state after an incident. It therefore involves much more than clicking a “restore” button.

The difference can be simplified as follows:

Backup	Recovery
Creates a copy of the data	Returns the process to operation
Answers “what do we have stored?”	Answers “what can we restart?”
A technical capability	A technical and organizational process
Can run automatically	Requires decisions and priorities
Does not itself confirm usability	Must be tested in practice

 

A backup is a prerequisite for recovery, not proof of it. Even a correctly created backup may be unusable, too old, damaged, or insufficient to restore the entire application environment. When protecting against ransomware, it is therefore not enough to assess only the frequency of backups. It is equally important to know how long recovery takes, which systems depend on one another, and whether a sufficiently secure copy exists from before the compromise.

The most dangerous statement after an incident: “But we have a backup”

A sense of security often arises as soon as IT confirms that backups are being performed regularly. The problem is that the answer to “do we have a backup?” does not indicate whether the company is prepared to recover from a large-scale attack. A backup may exist, yet the company may still remain out of operation for days.

The assumption “we have backups, so we are safe” ignores questions such as:

• Is the backup still available after administrator accounts have been compromised?
• Can it be restored without the original infrastructure?
• Does it contain all the data required for the application to operate?
• Is it known which version is still safe?
• How long does it take to restore terabytes of data?
• Who decides what is restored first?
• Are the servers, identities, and network services required to launch the applications ready?

This is why ransomware must be considered within a broader resilience model. Prevention and detection remain essential, but the protection of corporate infrastructure must also account for the possibility that an attack may get past preventive measures.

Ransomware may encrypt more than production data

An advanced attack may not stop at workstations or a shared drive. If an attacker obtains sufficient privileges, they may also try to disable the mechanisms the company would use to return to operation. The backup infrastructure therefore becomes an attractive target in its own right.

Situations may be particularly risky when:

• backups use the same administrator accounts as the production environment,
• the backup storage remains connected to the same infrastructure,
• one compromised account can delete both production data and backups,
• all copies can be modified or deleted,
• the organization has no separate or immutable copy.

If an attacker can delete or encrypt the backups as well, what was originally a strong safety net loses its value. Protection against ransomware must therefore account not only for production system failures, but also for an active attack on the recovery process itself.

A ransomware incident should therefore be viewed as a combination of prevention, detection, attack containment, and recovery. Merely stopping a malicious process does not mean that normal operations have resumed, just as the mere existence of a backup does not guarantee successful recovery.

An immutable or isolated copy changes the situation

One principle of backup protection is to ensure that at least some copies cannot easily be modified or deleted using the same privileges as production data. In practice, this may involve immutable storage, a logically or physically separated copy, or another model that limits an attacker's ability to interfere with the backup environment.

The specific name of the technology is not important; the security principle is: compromising the production environment should not automatically compromise every recovery option. If a single account or administrative layer provides access to everything, the organization creates a common point of failure.

The design of a backup solution should therefore also assess:

• separation of administrator privileges,
• the authentication method,
• protection of backup consoles,
• options for deleting copies,
• retention periods,
• monitoring of changes in the backup environment.

This is naturally related to the principle of limiting trust and privileges. Zero Trust security is based on the idea that the mere presence of an account or device in a corporate environment should not automatically imply unlimited trust. This is especially important for administrator and backup accounts.

System recovery is not the same as data recovery

Even if the database is restored, the application may still not work. Today's corporate systems often consist of several interdependent components that must be available in the correct configuration. Without them, the data backup itself may be practically unusable. A typical enterprise application may depend on:

• a database,
• application servers,
• identity and authentication,
• DNS,
• certificates,
• network configuration,
• integration services,
• file storage,
• other internal or cloud systems.

If only the database is restored while identity or the integration layer remains unavailable, the business process still does not work. The purpose of recovery is therefore not to retrieve individual files, but to restore a service or process to a usable state.

Dependencies between systems determine the actual recovery order

After a serious incident, not all systems can be restored at the same time. Team capacity, infrastructure, and data transfers are limited, so an order must be established. However, this order should not be based solely on which system appears to be the most important.

ERP may be critical to the business, but it may not work without the identity system, database, or network services. An e-shop may be a commercial priority, but without the warehouse or payment system it cannot complete an order. Recovery must therefore respect both technical and process dependencies. A simplified example might look like this:

Order	Layer	Why
1	Core infrastructure	Network, DNS, virtualization
2	Identity and access	Login and permissions
3	Databases	Application foundation
4	Critical applications	ERP, production, logistics
5	Integrations	System interconnection
6	Less critical services	Secondary processes

 

The specific order will differ in every organization. What matters is that it is known before an incident, rather than being devised when half of the infrastructure is already unavailable.

The most critical system may not be restored first

This fact is often overlooked when planning recovery. A system's criticality and its position in the recovery order are not necessarily the same thing. The most important application may technically depend on several less visible services. A dependency map should therefore be created to answer questions such as:

• Which services does the critical application depend on?
• Which databases does it require?
• Which identity system does it use?
• Which integrations must be available?
• Does it require access to the internet or partner networks?
• Which certificates and keys are required?
• What happens if one component is not restored?

Such an analysis often also reveals dependencies that normal operation conceals. A system may work without problems for years, meaning that the organization never has to start it completely from scratch. An incident may then reveal that the documentation or knowledge of the original startup order is no longer current.

A backup can be technically successful yet still unusable

A backup system may report successful completion every day. However, this status typically confirms that the backup process ran as expected, not that the copy can successfully restore an entire business process. The difference becomes clear only in a real test. A problem may arise, for example, because:

• the backup is damaged,
• some application data is missing,
• required configuration files are not backed up,
• the recovery procedure is unknown,
• the new system cannot work with the old configuration,
• recovery takes significantly longer than expected.

A recovery test is therefore just as important as the backup itself. The company needs more than confirmation that a backup was created; it needs proof that a specific service can be restored from it within an acceptable time.

A recovery test should not be limited to checking a single file

Restoring a test document confirms that the backup contains a specific file. It does not confirm that the organization can restore ERP, domain services, or a production system after ransomware. Testing must therefore correspond to what the company wants to restore in a real incident. The scope of the test can gradually increase:

• restoring an individual file,
• restoring a database,
• restoring a virtual server,
• restoring an entire application,
• restoring several dependent systems,
• simulating a broader outage.

The more critical the process, the more valuable it is to test a realistic scenario. The worst time to discover that the recovery procedure does not work is on the day of an actual ransomware attack.

Regular preparedness reviews are also connected to the broader problem of relying on isolated security measures. The most common IT security mistakes often arise when an organization deploys a technology but does not verify how it works in a real incident scenario.

Recovery must also answer the question: from what point in time?

With ransomware, the newest backup is not automatically the best. If the attacker remained in the environment for some time before the incident was detected, the latest copy may already contain malicious changes or a compromised configuration. Restoring from it could bring part of the problem back.

The company must therefore be able to determine approximately when the compromise began. This may require analysis of logs, identity events, endpoints, and other security data. The better the organization can reconstruct the incident, the better it can select a trusted recovery point.

This is where recovery connects with monitoring. If security events are not continuously evaluated, it may be very difficult to determine whether the safe recovery point is two hours, two days, or two weeks before the incident was detected. The SOC's ability to analyze events and build an attack timeline therefore helps not only with detection, but also with decisions about safe recovery.

Recovery requires a clean environment

One of the greatest mistakes would be to restore data into an environment that is still compromised. If the attacker has retained access, the malicious mechanism has not been removed, or compromised accounts remain active, the restored systems may be attacked again. Rapid recovery without eliminating the cause may therefore create another incident. Before returning critical systems to operation, it is particularly important to verify:

• whether the threat has been isolated,
• which identities were compromised,
• which devices must be cleaned or rebuilt,
• whether security updates have been applied,
• whether dangerous sessions and access have been revoked,
• whether the original entry point has been removed.

This principle is also important when an identity is compromised. If the attacker still has a valid administrator account, restoring the servers alone will not solve the problem. Recovery must therefore follow incident response rather than operate as an isolated technical process.

RTO: How long can the process remain unavailable?

Recovery planning uses the term RTO (Recovery Time Objective). It expresses the target maximum length of time for which a particular service or process may remain unavailable after an incident. Not every system requires the same level of availability. An example might look like this:

System	Acceptable recovery target
Production system	Hours
E-shop	Hours
ERP	Hours to one day
Internal archive	Days

 

This is only an illustrative example, because the actual values must be based on the specific business impact. The purpose of RTO is to connect the technical recovery options with how long the company can afford for a particular process to remain out of operation.

Without a defined RTO, it is impossible to say objectively whether recovery is fast enough. Ten hours may be an excellent recovery time for one system and unacceptable for another.

RPO: How much data can the company lose?

The second important term is RPO (Recovery Point Objective). It expresses the maximum data loss over time that the organization is prepared to accept. For example, if a backup is created once a day, an incident may theoretically require the company to work with the loss of almost an entire day's changes.

RPO affects the frequency of backups or replication. A system in which critical transactions occur every minute may require a completely different strategy from a document archive that changes only a few times a week. Here too, there is no single universal value for the entire company. Together, RTO and RPO help answer two different questions:

• How quickly must the system be back?
• How much of the most recent data can be lost?

The statement “we back up every day” does not answer either question.

The recovery order must be based on business impact

IT naturally understands the technical architecture. Management and process owners, in turn, know which services have the greatest impact on customers, production, or finances. The recovery plan therefore cannot be created solely as a technical document by one department. When setting priorities, factors to assess include:

• the impact of the outage on revenue,
• the shutdown of production or logistics,
• the impact on customers,
• regulatory obligations,
• dependencies of other systems,
• the availability of a manual fallback process.

A less visible internal service may have a higher priority than an application used by hundreds of employees if the rest of the environment depends on it for startup. The recovery order must therefore be based on a combination of business criticality and technical dependencies.

What a company should know about its backups before an incident

A sound recovery plan does not have to begin with complex technical documentation. Many weaknesses can be identified through a few practical questions. If there is no clear answer to them, the mere existence of a backup provides only limited assurance. At a minimum, the company should know:

• which systems are actually backed up,
• how often copies are created,
• where they are stored,
• who can modify or delete them,
• how long they are retained,
• when recovery was last tested successfully,
• how long recovery took,
• who can perform it,
• what must be restored first,
• which other systems recovery depends on.

These questions also reveal the difference between technological configuration and operational preparedness. The backup system may be configured correctly, but if only one person knows the procedure or the dependencies are unknown, the organizational risk remains high.

The recovery plan must also account for normal tools being unavailable

During a serious incident, email, corporate chat, documentation, or the identity system may be unavailable. A recovery plan stored only on the same server that is currently encrypted is unusable at the critical moment. A contact list available only through unavailable corporate infrastructure is similarly problematic. Practical questions must therefore also be considered:

• Where is the recovery plan stored?
• How will the team access it during an outage?
• Are alternative communication channels available?
• Are the necessary passwords or emergency accounts accessible?
• Who has the authority to decide priorities?
• Who communicates with management, customers, or partners?

Cyber resilience is not merely a property of technology. It is an organization's ability to continue making coordinated decisions even when its normal working tools are unavailable.

A manual fallback process can be as important as technical recovery

Not every system can be restored within a few minutes. For critical business processes, continuity may therefore include a temporary manual or limited mode. This can maintain basic operations until the information system is safely restored. Such a plan may define, for example:

• a temporary method for accepting orders,
• manual recording of critical operations,
• an alternative method of communication,
• limited production operations,
• priority service for key customers.

It is important that the fallback process is not created for the first time during an incident. In a stressful situation, it is easier to use a procedure that has been prepared and tested in advance than to improvise how an entire department will operate.

Seven signs that backups are creating a false sense of security

The mere existence of a backup can be misleading, particularly when the company has not mastered the other parts of recovery. The following situations are good reasons to review preparedness:

1. Full application recovery has never been tested.
2. It is not known how long recovery would take.
3. Production and backups use the same privileged accounts.
4. No one has an up-to-date map of system dependencies.
5. The recovery order has not been defined in advance.
6. Only one or two employees know the recovery procedure.
7. The company does not know which point it could safely recover from after ransomware.

Any one of these problems does not automatically mean that the organization lacks functional backups. Their combination, however, significantly reduces confidence that a backup will translate into fast and secure recovery during a real incident.

Backups are the last safety net, not the only defence

Recovery is an extremely important part of ransomware protection, but it should not be the first or only line of defence. If an attack reaches production systems and the company must restore extensive infrastructure, the incident has already generated operational costs regardless of backup quality. A better outcome is to detect and contain the attack before the destructive phase. Backups are therefore complemented by:

• identity protection,
• segmentation,
• endpoint protection,
• vulnerability management,
• monitoring,
• detection of unusual behaviour,
• incident response.

It is the combination of multiple layers that reduces the likelihood of a single failure escalating into a company-wide outage. The same principle underpins multi-layered protection of corporate infrastructure, where no individual measure can be considered absolute protection.

The most important test is not “Do we have a backup?”

A far more useful question is: Could we restore critical operations tomorrow morning if part of the infrastructure were encrypted and the production environment could not be trusted?

Such a question immediately changes the perspective. It is no longer enough to show a green icon for the latest backup, because the company must address a safe recovery point, a new or cleaned environment, identities, dependencies, recovery capacity, and the people who will carry out the entire process.

This is also why ransomware protection should assess not only prevention of the attack itself, but also preparedness for a situation in which the incident cannot be prevented entirely. Ransomware prevention and the response after its detection are two parts of the same problem. Recovery capability determines how quickly a security incident stops becoming an operational crisis.

From backup to cyber resilience

The difference between backup and true preparedness is simple. A backup protects a data copy, recovery restores systems, and business continuity keeps the company operating during and after an incident. Together, these areas create true cyber resilience.

Before assessing recovery technologies, organizations must understand critical processes, their dependencies, and maximum acceptable downtime. This determines the appropriate backup architecture, copy protection, testing frequency, and recovery order. The recovery plan should reflect what the company must restart, not only what it can back up.

A backup has value only when operations can be restored from it

Ransomware can affect data, identities, servers, and backup infrastructure. Knowing that a backup exists is not enough. The company must know whether it is trustworthy, sufficiently separated, tested, and usable in the actual recovery order. A first step is to review five areas:

• critical systems and processes,
• available and protected backups,
• RTO and RPO requirements,
• technical dependencies,
• regular recovery testing.

ANASOFT covers cybersecurity, including incident recovery and business continuity, as part of a broader security strategy. The objective is not merely to retain a copy of the data, but to develop the capability to restore critical systems securely and within a timeframe that does not jeopardize the company's operations.

Frequently Asked Questions