Ransomware is now a board-level operational risk, with WannaCry in 2017 showing how quickly an attack could move beyond infected laptops and disrupt essential systems. Since then, ransomware operations have become more targeted, more patient, and more focused on disrupting the systems that organisations depend on to work.
To “avoid” ransomware in a practical security programme means reducing the likelihood of compromise and limiting the damage if an attacker gets in. No control can guarantee that an organisation will never face ransomware, so the better objective is measurable resilience: faster detection, faster containment, known recovery points, and tested recovery times. In operational terms, that means improving mean time to detect, mean time to respond, recovery point objective, and recovery time objective.
Small and mid-sized organisations often have a harder version of this problem than large enterprises. They may run the same email platforms, cloud services, remote access tools, and business-critical applications, but without a dedicated incident response team or a mature security operations function. That makes disciplined prioritisation more important than buying another tool. Ransomware prevention works best when it is treated as a small set of operational habits that are owned, tested, and improved.
Start with the right goal: reduce blast radius and recovery time
A ransomware programme should begin with two questions. First, how difficult is it for an attacker to reach business-critical systems after compromising one account or device? Second, how quickly can the organisation isolate affected systems and restore essential services from clean data?
Those questions change the conversation. Instead of asking whether antivirus is installed everywhere, the organisation has to ask whether attackers can reuse local administrator passwords, whether legacy authentication is still enabled, whether backup administrators use separate accounts, whether restore tests prove that critical systems can be brought back, and whether someone has authority to isolate a network segment during an incident.
Frameworks such as NIST SP 800-61 for incident handling, NIST SP 800-53 for security controls, CISA ransomware guidance, and ENISA advice all point toward the same practical conclusion: prevention, containment, and recovery need to be planned together. A patching programme is valuable, but it is weaker if every workstation can reach every file share. A backup platform is valuable, but it is weaker if the same compromised credentials can delete production data and backups.
Practice 1: close common entry points with patching, hardening, and allowlisting
Commodity ransomware frequently begins with the ordinary weaknesses that remain open for too long: unpatched internet-facing systems, exposed remote access, malicious attachments, unsafe macros, unmanaged scripts, and software that users can install without approval. Patch management matters, but it should be paired with hardening and application control because patching alone rarely keeps pace with every exposure in a busy environment.
The first priority is to know which systems are reachable from the internet and which of them support remote administration, VPN access, web applications, or file transfer. These systems should have clear owners, current patch status, monitored authentication, and an emergency update path. In practice, many ransomware incidents become severe because a forgotten server, old appliance, or lightly monitored remote access service gives attackers a stable foothold.
Application allowlisting can reduce the number of untrusted executables, scripts, and tools that run on endpoints. It is especially useful against commodity ransomware that relies on predictable script interpreters, unsigned binaries, or user-writable directories. The policy does not have to begin as a strict block-everything model. Many organisations start in audit mode, identify what actually runs, remove unnecessary software, and then apply tighter enforcement to high-risk groups such as finance, IT administration, and shared-service workstations.
Macro hardening is another practical control. Macros from the internet should be blocked unless there is a documented business requirement and a safer workflow cannot be used. Device control also deserves attention. Removable media, unmanaged synchronisation tools, and unauthorised remote administration utilities can all expand the attack path if they are allowed by default.
The common mistake is treating endpoint protection as a substitute for operating discipline. A more reliable approach is to reduce what can execute, remove what is no longer needed, patch what remains, and monitor the systems that are most exposed. That sequence makes defensive tools more effective because they have fewer risky behaviours to inspect.
Practice 2: harden identity and email because credentials are often the beachhead
Email remains a frequent starting point, but identity has become the more important battleground. Attackers do not always need malware at the beginning of an incident. A stolen password, an approved MFA prompt after fatigue attacks, a compromised session token, or an old protocol that bypasses modern controls can give them the access they need to search, move, and escalate.
Multi-factor authentication should be enabled for all users, but the method matters. Phishing-resistant options are stronger for administrators and high-risk roles, while number matching, conditional access, device compliance, and risk-based prompts can reduce the chance that a user approves a malicious sign-in. Legacy authentication protocols should be disabled where possible because they can undermine MFA policies and are often invisible to users.
Service accounts need special care. They often have long-lived credentials, broad permissions, and weak monitoring because they are treated as plumbing. Each service account should have a named owner, a documented purpose, the least privilege needed for that purpose, and a rotation process. Interactive sign-in should be blocked unless it is genuinely required, and privileged service accounts should be separated from normal user and administrator accounts.
Email controls should focus on reducing both delivery and execution risk. Attachment filtering, safe links, domain protection, impersonation controls, and external sender warnings all help, but user reporting is also important. A reported phishing email can become an early warning signal if it is triaged quickly and used to search for similar messages across the tenant.
Defenders also need to account for token theft and session abuse. Resetting a password may not be enough if active sessions, refresh tokens, or device registrations remain valid. Incident playbooks should include steps for revoking sessions, reviewing MFA changes, checking new inbox rules, and inspecting suspicious application consent grants. These actions are often the difference between removing one compromised account and leaving a usable path open.
Practice 3: segment systems and privileges before an incident forces the issue
Ransomware becomes a business crisis when it spreads from one compromised system to many. Segmentation and least privilege are what turn a potentially severe compromise into a contained event. The aim is to prevent a single workstation, account, or server from becoming a route to file shares, backup consoles, domain administration, and critical applications.
Network segmentation should begin with the systems that matter most: identity infrastructure, backup infrastructure, management servers, finance systems, operational technology where relevant, and shared file services. These assets should not be reachable from every endpoint by default. Access should be limited by role, management path, and business need, with logging enabled for administrative connections.
Administrative privilege needs a tiered model. Domain, cloud, server, endpoint, and application administration should use separate accounts where the risk justifies it. Administrators should not browse email or the web using privileged accounts, and privileged access workstations or hardened admin devices should be considered for the most sensitive tasks. Local administrator rights should be removed from standard users, and local administrator passwords should be unique and managed rather than reused across machines.
Least privilege also applies to file shares. Broad write access creates ideal conditions for mass encryption. Permissions should reflect current business needs, stale access should be removed, and sensitive shares should have monitoring for unusual file changes. Where possible, versioning, snapshots, and controlled access can reduce the impact of accidental or malicious modification.
Containment planning should be specific. During a ransomware event, time is lost when teams debate who can disconnect a site, disable a protocol, isolate a VLAN, stop synchronisation, or force password resets. Pre-approved isolation actions make response faster and less political. The decision can still be reviewed during an incident, but the authority and technical steps should not be invented under pressure.
Practice 4: build backups that attackers cannot easily destroy
Backups are often described as the last line of defence, but they should be treated as part of the primary ransomware strategy. A backup that restores slowly, restores corrupted data, or can be deleted by compromised production credentials may create a false sense of safety. The organisation needs to know what data can be recovered, how old it will be, and how long restoration will take.
The familiar 3-2-1 approach remains useful: keep multiple copies, use more than one type of storage, and keep at least one copy offsite. Ransomware planning adds further requirements. At least one backup copy should be immutable or protected by write-once-read-many controls where available, and at least one recovery path should be logically or physically isolated from the production environment. Backup administration should use separate credentials, separate MFA, and tightly limited access.
Double extortion changes the role of backups. Clean backups may restore operations, but they do not remove the risk that stolen data could be disclosed. That is why prevention and detection still matter. Encryption of sensitive data, egress monitoring, access reviews, and data minimisation all reduce the value and volume of information available to an attacker.
A practical backup programme follows an apply, validate, and iterate rhythm. Design isolation first by separating backup credentials and administrative paths from the production domain where possible. Enable immutability or WORM-style protection where the platform supports it, encrypt backup data, and then run restore drills on a planned schedule. Each drill should measure whether the organisation met its RPO and RTO, identify what failed, and feed the lessons back into recovery playbooks.
Restore testing should include more than a single file recovery. Critical systems may need directory services, databases, application servers, network dependencies, certificates, and documented order of restoration. If those dependencies are not tested, the first realistic recovery attempt may occur during a crisis. Silent corruption is another concern, so backups should be monitored for completion, integrity, and unusual changes in backup size or behaviour.
A 90-day sequence that creates momentum
Ransomware risk can feel too large to tackle, especially when the environment includes legacy systems and limited staff. A useful way to make progress is to choose one control in each pillar for the next quarter: prevent the most likely entry, contain the most likely spread, and recover the most important service. Readynez uses this kind of time-bound sequencing in training contexts because it helps teams turn broad security advice into work that can be assigned and reviewed.
- During the first month, enable or strengthen phishing-resistant MFA for administrators and high-risk users, then disable legacy authentication wherever business systems allow it.
- During the second month, remove unnecessary local administrator rights, deploy managed local administrator passwords, and separate privileged accounts from daily-use accounts.
- During the third month, confirm that critical backups are immutable or isolated offsite, then run a restore test against a defined RPO and RTO.
This sequence is deliberately narrow. It does not solve every ransomware problem, but it creates a foundation that can be reassessed each quarter. After the first cycle, the next priorities might be application allowlisting for high-risk departments, stronger file-share monitoring, privileged access workstations, or a tabletop exercise that tests isolation decisions.
Tabletop exercises are especially useful for smaller teams because they reveal practical gaps without waiting for an incident. The exercise should test who declares an incident, who contacts legal and executive stakeholders, who can isolate networks, who can revoke sessions, who communicates with users, and who owns restoration priorities. The result should be a shorter response time and fewer improvised decisions.
Ransomware prevention as an operating model
The strongest ransomware programmes are maintained as ordinary operations rather than annual projects. Patch status, privileged access, backup health, and restore test results should be reviewed regularly. Exceptions should expire, and owners should be named for systems that remain exposed because of business constraints.
Security teams should also define a small set of measures that leaders can understand. Mean time to detect and mean time to respond show whether the organisation is improving its ability to find and contain suspicious activity. RPO and RTO show whether recovery claims are realistic. Isolation time shows how quickly the organisation can cut off spread without disabling the entire business unnecessarily.
Documentation matters, but playbooks should be brief enough to use under stress. A ransomware playbook should cover initial triage, evidence preservation, account containment, network isolation, backup protection, communications, restoration order, and decision points for external support. It should also state what not to do, such as deleting evidence before investigation or reconnecting restored systems before the entry point has been addressed.
FAQ
Should an organisation pay a ransomware demand?
There is no universal answer, and this is not a legal recommendation. Authorities such as CISA generally discourage payment because it funds criminal activity and does not guarantee recovery or deletion of stolen data. Any decision should involve executive leadership, legal counsel, insurers where applicable, law enforcement guidance, and a clear assessment of safety, operational impact, sanctions risk, and available recovery options.
Are backups enough when attackers use double extortion?
Backups are essential for restoring operations, but they do not address the exposure created when data has already been stolen. That is why backup resilience must sit alongside identity hardening, segmentation, monitoring, encryption, data retention discipline, and egress detection. The recovery plan should restore systems, while the security plan should reduce the chance and impact of data theft.
Does antivirus still matter, or does every organisation need EDR?
Antivirus still has value, but signature-based protection alone is too limited for modern ransomware defence. Endpoint detection and response can improve visibility into suspicious behaviour, lateral movement, and post-compromise activity, but it also requires monitoring and response capability. Organisations should choose controls they can operate reliably, and then strengthen them with allowlisting, least privilege, patching, and tested incident playbooks.
What is the first ransomware control to prioritise?
If the environment has weak identity controls, start there. Strong MFA for administrators and high-risk users, removal of legacy authentication, and separation of privileged accounts reduce the chance that one stolen credential becomes a broad compromise. In parallel, confirm that critical backups cannot be deleted or encrypted by the same accounts used in production.
Making ransomware risk manageable
Ransomware cannot be reduced to a single product decision or a one-time hardening project. The practical work is to make entry harder, movement slower, privilege narrower, and recovery more predictable. That means combining identity controls, patching and application control, segmentation, least privilege, and backup validation into a routine that the organisation can sustain.
The most effective next step is to choose a small number of actions that can be completed and tested in the next quarter. Teams that need structured skill development around security operations, incident response, identity, and recovery planning can use Readynez training as one way to build a shared baseline, but the operating principle is the same in every environment: reduce the blast radius before an incident, and prove recovery before it is needed.
