A ransomware attack can bring business operations to a complete standstill in a short space of time. Files are encrypted, applications stop working and employees can no longer access the data they need for their work. In such a situation, the solution may seem obvious: rebuild the affected systems and restore the data from a backup.
But recovery from ransomware is more complicated than recovery from an ordinary technical failure. An attacker may have had access to the IT environment for a considerable time before the attack became visible. During that period, accounts may have been misused, security settings changed and systems equipped with tools that allow the attacker to regain access later. Backups, too, may contain data or system settings that can no longer be trusted.
The most important question is therefore not just how quickly the organisation can resume work, but also which point in time it can safely recover to, and under what conditions.
Why ransomware recovery differs from routine recovery
With a failed server or a damaged database, the cause of the disruption can usually be traced to a specific technical issue. Once the underlying infrastructure is functioning again and a usable backup is available, recovery can be carried out and checked.
Ransomware is different. The visible encryption is often only the final stage of a longer incident. Attackers may already have gained access through a vulnerability, stolen credentials or an inadequately secured external connection. They may then have moved through the network, gained additional privileges and made preparations to increase the impact of the attack.
This means that a backup taken before the encryption does not necessarily predate the compromise. A recovery point may be technically fully intact, while the operating system, configuration or data it contains has already been affected.
Restoring systems without sufficient investigation risks reintroducing the same vulnerabilities or unauthorised access. An organisation may then fall victim again after a successful restore, despite believing that the incident had been resolved.
Four steps towards responsible recovery
Recovery after ransomware requires a coordinated approach that connects incident containment, investigation and recovery. The following four steps clarify the considerations needed before business-critical systems are brought back into use.
Contain the incident
Limit further spread, protect the recovery provisions that remain available and prevent affected systems from causing further damage.Investigate the compromise
Establish how the attacker gained access, which systems and accounts have been affected and how long the environment may have been compromised.Establish a recovery point
Determine which backups and system versions are sufficiently trustworthy to serve as the basis for recovery.Recover in a controlled manner
Build the necessary environment securely, restore data and applications and check whether business operations can responsibly resume.
These steps are not strictly sequential activities. Incident containment and investigation often take place at the same time, while preparations may already be under way to recover less critical components. New findings may also prompt a reassessment of a recovery point selected earlier.
The guiding principle remains that the speed of recovery must not come at the expense of the trustworthiness of the environment in which the organisation needs to continue working.
First establish what has actually been affected
When ransomware is discovered, attention understandably turns to the systems that are no longer functioning. Yet it is at least as important to investigate which parts of the environment may have been compromised without showing visible signs of disruption.
Consider administrator accounts, central identity services, remote access, network equipment and systems used to distribute or manage software. If an attacker has gained control of one of these components, recovering individual servers may be insufficient. The access that made the attack possible may still exist.
The backup environment also deserves particular attention. Attackers regularly try to disrupt recovery capabilities by deleting backups, encrypting storage or taking over access to management systems. It is therefore necessary to establish whether the available recovery data has remained independent and sufficiently protected.
The investigation does not always have to be fully completed before recovery preparations begin. However, for the systems being brought back into use, there must be sufficient clarity about the risks that remain and the measures needed to prevent reinfection.
How do you determine which recovery point can be trusted?
Routine recovery often uses the most recent usable backup. This keeps data loss to a minimum. After ransomware, that choice may be unwise.
Suppose the encryption is discovered on Friday, but the investigation finds indications that an attacker has had access to the environment since the preceding Monday. Thursday's backup may be perfectly recoverable, but it may also contain unwanted changes. An older backup may provide a safer starting point, although that means losing more recent data.
There is no simple rule for determining in advance which backup is safe. The choice depends on the investigation findings, the nature of the attack, the backup arrangements and the options for checking data and systems separately.
Four points to consider in the assessment
The time of compromise
The suspected start of unauthorised access, rather than the date of the visible attack, determines how recovery points should be assessed.The integrity of data and systems
Check that recovery data is available, readable and consistent, and that the systems to be restored contain no suspicious changes.The presence of unauthorised access
Investigate whether accounts, configurations, software or other components could allow the attacker to regain access.The security of the recovery environment
A trustworthy backup has little value if it is restored into an environment where the same vulnerabilities and access problems remain.
These criteria must be assessed together. A backup that appears trustworthy in one respect is not automatically suitable for fully restoring business operations.
The trade-off between data loss and safe recovery
Selecting an older recovery point has a direct consequence: transactions, documents and other changes made after that point may no longer be available. For organisations that depend on up-to-date data, this can have significant operational and financial consequences.
Consider, for example, an ERP system restored to a point several days earlier. In the meantime, orders may have been processed, goods received, production orders carried out and invoices created. If that data is missing, a gap arises between the restored records and actual business operations.
Restoring a single complete system is therefore not always sufficient. Sometimes data can be reconstructed from other sources that are demonstrably trustworthy. These might include transaction records, data from external systems, documents available elsewhere or work recorded manually. Whether this is responsible and technically feasible must be assessed in each situation.
This creates an important tension between the desired recovery speed, the maximum acceptable data loss and the assurance that the organisation will not be affected again. The RPO and RTO objectives established earlier remain relevant, but during a ransomware incident they cannot be considered separately from the necessary security checks.
A rapid return to an untrustworthy environment is not a successful recovery.
Recovering in an environment that can be trusted again
Once a suitable recovery point has been established, the actual recovery begins. This involves more than restoring files and servers. The underlying infrastructure, identities, network connections and security measures must also be trustworthy.
Depending on the nature and extent of the compromise, it may be necessary to rebuild systems completely rather than restore existing installations. Accounts and access rights must be checked, misused credentials must be invalidated and vulnerabilities that contributed to the incident must be remedied.
The recovery sequence also matters. A business application can only function responsibly once the database, identity services, network connections and other dependencies it needs are available and trustworthy. Recovered systems must be prevented from reconnecting too early to parts of the network that have not yet been investigated.
Recovery can therefore take place in a separate, controlled environment. Systems and data can be examined and tested there before becoming part of normal business operations again. This creates room for technical checks without immediately increasing the risk of further spread.
When can the organisation get back to work?
A system that starts up again is not automatically safe or usable for business purposes. After technical recovery, it must be established whether applications function correctly, the necessary data is available and employees can actually resume their work.
Ransomware requires an additional assessment: have the causes of the incident been sufficiently addressed, and is there sufficient confidence that the recovered environment will not be compromised again? This requires checks on security settings, access rights, logging and monitoring, among other things.
The decision to make systems available again is therefore not solely technical. The implications for business operations must also be taken into account. Sometimes a limited number of processes can resume earlier, while other systems still require further investigation or additional measures.
Clear responsibilities are essential here. The IT administrator, security specialists, application suppliers and the organisation itself must know who carries out the recovery, who assesses the results and who decides that a business process can responsibly restart.
Why preparation makes the difference
Pressure is high during a ransomware incident. Employees cannot work, customers are waiting for services and the financial consequences increase the longer the disruption lasts. At precisely that moment, making careful judgements is difficult if the necessary information and recovery provisions are not already available.
A good recovery plan therefore describes more than the technical steps needed to restore a backup. It clarifies which systems are business-critical, how they depend on one another, which recovery provisions are available and which parties need to be involved in recovery.
For ransomware, it is also important that backups are sufficiently protected and independently accessible, that recovery can take place without immediately relying on potentially compromised systems, and that procedures exist to assess the trustworthiness of recovery points.
Regular recovery tests help establish whether these provisions work in practice. Not every test needs to simulate a complete ransomware incident. Targeted tests of isolated recovery, access management, backup integrity and application dependencies can already reveal significant shortcomings.
Recovery capability requires more than a backup
Ransomware makes clear why backup, security and IT management cannot be organised independently of one another. The quality of recovery is partly determined by decisions made long before an incident: the configuration of access rights, the protection of backups, network segmentation, the availability of logging and the way systems are managed.
An organisation that only checks whether its backups complete successfully still knows too little about its actual recovery capability. It must also be clear whether a trustworthy recovery point can be established, whether systems can be rebuilt securely and whether business operations can then responsibly resume.
Malenco therefore approaches recovery as part of coordinated, security-focused IT management. The focus is not only on data availability, but also on the trustworthiness of the environment, interdependencies and the practical feasibility of recovery.
The aim is not simply to get back online after ransomware, but to enable the organisation to continue working in a controlled and reliable way.
