Start with a backup the attacker cannot reach

The first thing modern ransomware looks for is the backups. It deletes Windows shadow copies, encrypts mapped shares, and targets the backup server when it sits on the same domain under the same administrative accounts. A copy that is always online and always reachable is not a backup; it is one more target.

The 3-2-1 rule is a sensible minimum: 3 copies of the data, on 2 different types of media, with 1 copy off-site. Add two conditions that actually change the outcome. At least one copy should be immutable or genuinely disconnected, and restores should be tested on a schedule so you know the copy works.

Use immutable storage (Object Lock or WORM), or media that is physically disconnected after every job, such as tape or a rotated external disk.
Keep the backup server off the production domain and off the same administrative accounts. One compromised account should not open both the data and the backups.
Require multi-factor authentication on the backup console itself, not only on user logins.
Run a full test restore at a fixed interval. An untested backup is an assumption, not a guarantee.
Set retention long enough for late discovery. Some intrusions stay quiet for weeks before encryption begins.

Exposed RDP is the first door

A large share of intrusions that end in encryption begin with a Remote Desktop session published straight to the internet, protected by a weak or stolen password. Moving the service off port 3389 does not fix this. Automated scanners find the new port within hours.

The practical rule is that RDP does not face the internet. It sits behind a VPN or an access gateway, with multi-factor authentication, account lockout after repeated failures, and an explicit list of who may connect at all.

Close 3389 at the firewall, and verify it from outside the network rather than from inside.
Enforce multi-factor authentication on VPN, access gateways, email and every admin console.
Enable Network Level Authentication and lock accounts after a set number of failed attempts.
Review who still holds remote access, and remove dormant accounts, former staff and expired vendor logins.

Patch what is exposed first, then cut the privileges

Patching everything at once is unrealistic in production, so order it by exposure. Internet-facing systems come first: VPN gateways, firewalls, mail servers and hypervisor management interfaces. This is the category where public exploit tooling appears within days of disclosure.

Privilege comes next. An attacker does not need a fresh vulnerability if a domain admin account is used for daily work. Separate administrative accounts from everyday accounts, and give each account the least privilege its job requires.

Never browse, read email or do daily work from a domain admin account.
Remove local administrator rights from user machines where possible, and stop reusing the same local admin password across the estate.
Disable SMBv1 and other legacy protocols nothing still needs.
Delete unused accounts and services. Every account that exists is a possible path.

Segment the network and watch for the early signals

Ransomware turns into a disaster when it can move freely. On a flat network, one infected workstation can reach the servers, the storage and the backup system. Segmentation does not prevent infection, but it decides how much of the business the infection can touch.

Monitoring completes it. Most attacks leave traces hours or days before encryption: a login at an unusual time, an unapproved remote-access tool, or an attempt to delete shadow copies. Make those events alert a person, rather than land in a log someone reads later.

Separate the server network from the user network, and isolate the backup and management networks.
Block direct SMB and RDP between user workstations.
Alert on shadow copy deletion, mass file renames, and sudden backup job failures.
Ship logs off the server that generates them. Attackers clear local logs.

Staff are the layer you cannot patch

A convincing email is still one of the most common ways in: an attached invoice, a document that asks you to enable macros, or a link to a login page that matches the real one. No training removes every mistake, but repeated and specific training lowers the click rate and shortens the time to discovery.

What matters more than the training itself is an easy way to report. Someone who clicks a link and says so within minutes gives your team a real chance. Someone who is afraid of being blamed stays quiet, and that silence is what gives the attacker time.

Block macros by default in files that came from the internet.
Make reporting a suspicious message a single step, with no penalty attached.
Train on the dangerous scenario: a trusted-looking request for a transfer or for credentials.

The first hour after you find the encryption

The goal in the first hour is not repair. It is to stop the spread and preserve both the evidence and your options. The common mistake is speed in the wrong direction: rebooting servers, deleting encrypted files, or reimaging a machine before a full image is taken. Each of those can close a door that was still open.

On payment, these are the facts worth knowing before the decision. Paying does not guarantee a working key, and the decryptors attackers supply are often slow or incomplete. If a copy of the data was taken out of the network, there is no way to verify that a promise to delete it was kept. Payment may also carry legal and regulatory obligations that differ by sector. The decision is a management and legal one, and it follows a technical assessment of what can actually be restored.

Tell management and whoever owns security in your organisation, and document the time and the affected systems from the first moment. Depending on your sector, reporting to the relevant regulator may be mandatory.

Isolate at the network level: pull the cable or disable the switch port. Do not power the machine off and do not reboot it.
Disconnect backups and storage media from the network before the encryption process reaches them.
Keep the ransom note, the encrypted file extension, and a sample of one encrypted file with a clean original if you have one.
Do not delete encrypted files, do not format, and do not rebuild the server before a full image is taken.
Do not run decryptors from untrusted sources. Some corrupt the files, and some are additional malware.

How to Protect a Server From Ransomware