Ransomware and Your Web Application: A Practical Recovery Plan

Ask a business owner what ransomware is and they describe a scary movie scene: a screen full of red text and a countdown. In reality it usually starts quietly. An employee's password leaks, an old server misses a patch, an attacker spends days moving around unseen, and then, at 2 am on a Saturday, your files and databases are encrypted.

At that point you have three choices. Pay and hope, rebuild from backups, or lose the business data. Only one of those is a plan. This article is about making sure you have it.

Step 1: Make backups that survive an attack

Attackers know about backups, and good ones hunt for them first. A backup that sits on the same network, with the same passwords, will be encrypted along with everything else.

• Follow the 3-2-1 idea. Three copies of your data, on two different kinds of storage, with one copy kept away from your main environment.
• Make one copy immutable. Many cloud storage services let you lock backups so nobody, including an administrator account, can delete or change them for a set period.
• Use separate credentials. The account that writes backups should not be able to delete them, and it should not be a login your team uses daily.
• Back up more than the database. Include uploaded files, configuration, secrets stored safely and the scripts needed to rebuild the servers.

Step 2: Prove you can restore

This is where most plans fail. People discover during a crisis that the backup file is empty, the restore takes three days or nobody knows the steps. Once a quarter, restore your latest backup into a clean environment, time it and write down exactly what you did. That document is your recovery manual, and the time it takes is your real recovery time.

Step 3: Shrink the ways in

Ransomware needs a door. Close the common ones:

• Require multi factor authentication on email, cloud consoles, code repositories and any remote access.
• Keep servers, frameworks and packages patched. Old vulnerabilities are the favourite entry point. Our guide on what to do after a PHP vulnerability is disclosed covers the patching routine.
• Give people the access they need and nothing more. A support agent should never be able to touch the production database.
• Remove accounts when people leave, on the same day.
• Do not expose database ports or admin panels to the whole internet.

Step 4: Notice early

The longer an attacker lingers, the worse the damage. Turn on logging for sign ins, permission changes and large data exports, and send alerts to a person who will actually read them. Odd hours, new locations, sudden bulk downloads and disabled security tools are all warning signs worth investigating the same day.

Step 5: Write the response plan before you need it

In a crisis nobody thinks clearly. A one page plan helps:

1. Contain. Disconnect affected systems from the network and block the compromised accounts. Do not switch servers off if you can avoid it, because memory can hold useful evidence.
2. Call the right people. Your technical lead, a security specialist, your lawyer and your insurer if you have cyber cover. Keep their phone numbers somewhere that does not depend on your own systems.
3. Assess. Decide what was touched, which data may have been copied and which backups are clean.
4. Rebuild. Restore into clean servers rather than cleaning the infected ones, and change every password and key.
5. Communicate. Tell customers, partners and regulators as required, quickly and honestly. Many data protection laws set deadlines for notification.
6. Learn. Find how they got in and close that door before you reopen.

Should you pay the ransom?

Authorities generally advise against it. Payment does not guarantee you get working data back, it marks you as a willing payer, and it may carry legal problems. The most honest answer is that businesses with tested backups rarely face the question in the first place.

If you want help building resilient backups, hardening an existing application or planning a rebuild strategy, our team can review your setup as part of ongoing software development and support.

Frequently Asked Questions

How do I protect my web application from ransomware?

Combine tested, isolated backups, multi factor authentication, fast patching, minimal access rights and monitoring. No single tool replaces these basics.

What is the 3-2-1 backup rule?

Keep three copies of your data, on two different types of storage, with one copy stored separately from your main environment. Adding an immutable copy makes it much harder for attackers to destroy.

How long does it take to recover from ransomware?

With tested backups and a written plan, hours to a couple of days. Without them, weeks, and sometimes the business never fully recovers.

Does cyber insurance cover ransomware?

Many policies do, but they often require specific controls such as multi factor authentication and tested backups. Read the conditions carefully before you need them.