Ransomware targeting a business web application is fundamentally different from an attack on a desktop environment. When a CRM system, customer portal or internal tool is encrypted or otherwise compromised, the recovery path depends on what was affected, where the backups are held and whether the attacker gained persistent access rather than simply encrypting files.

Decision summary: Prioritise containment, trustworthy recovery, protected backups, evidence and business-service restoration rather than immediate mass rebuilding.

The first distinction to understand is between encryption and exfiltration. Some ransomware operators encrypt data and demand payment for the decryption key. Others copy data first and threaten to publish it. In many cases, both occur. Recovery planning therefore needs to address not just restoring files, but understanding what the attacker may have accessed or copied before the encryption took place.

For a web application, the assets at risk typically include the application code, the database, file storage (documents, uploads, exports) and the infrastructure configuration. Each of these may be recoverable from a different source and on a different timeline. A backup taken last night might restore the database to a usable state, but if the application code was modified weeks ago, the restored version could still contain the vulnerability the attacker exploited.

A proportionate security baseline

For “How to Recover from a Ransomware Attack”, security controls should be selected from a documented risk assessment and tested in the complete service. No single product, certificate or test removes the need for secure design, access control, monitoring, patching, incident response and recoverable backups.

The role of your development supplier

If a third-party agency or developer built and maintains the application, their involvement in recovery is critical but needs to be managed carefully. They will understand the deployment pipeline, where backups are stored and how to redeploy. However, they may also need to investigate whether the attack entered through a flaw in code they wrote, which creates a conflict of interest if they are the only party assessing the cause. Many businesses engage a separate security specialist to review the incident independently while the original supplier handles the technical restoration.

Deciding whether to restore or rebuild

The central recovery decision is whether to restore from backups or to rebuild the affected components from scratch. Restoration is faster when clean backups exist and the attack vector is understood. Rebuilding becomes necessary when backups are unavailable, when they are suspected to be compromised, or when the application's architecture made it too easy for the attacker to move laterally. In practice, most recoveries involve a combination: restoring the database from a known-good backup while rebuilding or hardening the application layer.

Isolating the affected system

Before any recovery work begins, the application must be isolated from the network to prevent the ransomware from spreading to connected systems. For a web application, this means taking the service offline, revoking credentials that may have been compromised and severing connections to third-party integrations. If the application shares database servers or API keys with other systems, those connections need to be identified and cut immediately. This isolation step often causes more immediate business disruption than the ransomware itself, so the decision to take the system offline should be made by someone with the authority to accept that impact.

Assessing what you actually have in backup

Recovery speed depends entirely on what backups exist and whether they were stored in a location the attacker could reach. A backup stored on the same server or the same cloud account as the live application is often encrypted alongside it. Off-site or air-gapped backups, by contrast, remain untouched. Before committing to a restoration path, verify that the backup files are intact, that they cover all affected components and that you can actually access them. Discovering at the point of recovery that a backup is corrupted or incomplete is a common and costly failure.

Verifying the backup predates the attack

Even an intact backup is only useful if it was taken before the attacker gained access. Ransomware operators often dwell in a system for days or weeks before encrypting anything. If the backup was taken during that dwell period, restoring it may reintroduce the attacker's access. Check backup timestamps against the earliest evidence of compromise, and consider whether any backup taken after that point can be trusted.

Restoring a customer portal

For a portal where external users log in, recovery involves more than getting the application running again. User accounts may have been created or modified by the attacker, session tokens may be compromised and user-uploaded documents may be encrypted. After restoring the database, force a password reset for all users, invalidate every active session and audit any accounts created or altered during the compromise window. Communicate clearly with users about what happened and what they should do, without speculating about details that have not been confirmed.

Restoring an internal CRM or admin tool

Internal systems carry a different set of concerns. The data is often more commercially sensitive, and the users are employees who may have clicked a phishing link or reused a compromised password. Recovery here should include checking whether the attacker accessed customer records, financial data or personal information that falls under UK data protection law. The internal incident response should run in parallel with the technical restoration, and legal or compliance advice should be sought early rather than after the system is back online.

Changing credentials and keys after recovery

Restoring from backup does not automatically revoke access. API keys, database passwords, SSH keys, integration tokens and administrator accounts may all have been exposed. Every credential associated with the application should be rotated as part of the recovery process, not as an afterthought. If the application connects to payment processors, email services or other third-party platforms, those connections need new keys issued on both sides.

Paying the ransom without understanding the trade-offs

Law enforcement agencies in the UK generally advise against paying ransoms, but the decision is ultimately yours. The practical limitation is that payment does not guarantee recovery. Decryption tools may be slow, incomplete or non-existent. Even if the attacker provides a working key, the restored data may be corrupted, and you will have no way of knowing whether the attacker retained a copy or left backdoors in the system. If payment is being considered, it should be a deliberate business decision made with legal advice, not a panic response.

Restoring without identifying the entry point

One of the most damaging mistakes is to restore the system to its pre-encryption state without understanding how the attacker got in. If the vulnerability remains, the same attack can recur within days. The entry point might be a known software vulnerability, a weak administrator password, an exposed API endpoint or a compromised integration. Until the root cause is identified and closed, the restored system is not safe to reconnect.

Assuming the backup is clean because it was not encrypted

A backup that was not encrypted by the ransomware is not necessarily clean. The attacker may have modified data, inserted backdoor accounts or planted scripts that activate later. Treat every backup taken during the compromise window as suspect. Where possible, compare backups from before and after the suspected breach date to identify changes that should not be there.

Neglecting to test the restored system before going live

Rushing a restored system back into production without testing creates two risks. The restoration may have introduced errors, broken integrations or misconfigured permissions. More seriously, if the attacker's access was not fully eliminated, reconnecting the system gives them a fresh opportunity. Before going live, run through the application's core processes end to end, check that integrations are functioning and confirm that monitoring and alerting are active.

Key checks before declaring recovery complete

  • The entry point has been identified and closed, not just guessed at.
  • All backups used in the restoration predate the earliest evidence of compromise.
  • Every credential, API key and access token has been rotated.
  • Third-party integrations have been checked for unauthorised access or configuration changes.
  • User sessions have been invalidated and passwords reset where appropriate.
  • Monitoring and alerting are operational and configured to detect the same pattern of access.
  • A post-incident review has been scheduled to capture lessons and update the recovery plan.
  • Legal and compliance obligations, including any requirement to report the breach, have been assessed with current specialist advice.

Limitations of this guidance

Ransomware recovery is a technical and legal matter that changes as attack methods evolve. This article covers general principles for business web applications but does not constitute security or legal advice. Specific incidents should be handled with input from qualified security consultants and, where personal data is involved, legal advisers familiar with current UK data protection requirements. Your cyber insurance policy, if you have one, may also impose specific obligations on how you respond and what third parties you must involve.

Security evidence to require

  • Define the protected asset, likely abuse case and evidence that the control still works in production.
  • Treat a penetration test, WAF or security certificate as evidence for a defined scope, not proof that the whole service is secure.
  • Define the assets, threats, trust boundaries and business impact before selecting controls.
  • Give named owners responsibility for patching, access reviews, logging, incident response and recovery testing.

Primary guidance checked for this edition

Sources for “How to Recover from a Ransomware Attack” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.