- Modern ransomware exfiltrates data before encrypting it, so backups alone do not eliminate extortion risk
- Immutable, air-gapped backups tested quarterly are the single most effective recovery control
- Isolate affected systems within minutes of detection, but preserve forensic evidence before wiping
- GDPR Article 33 requires regulatory notification within 72 hours of discovering a personal data breach
- Paying ransom without professional negotiation and legal advice creates financial, legal, and reputational risk
- Most successful attacks exploit unpatched software, weak RDP credentials, or phishing, all preventable
What ransomware does
Ransomware is malicious software that encrypts files on infected systems and demands payment, typically in cryptocurrency, for the decryption key. That single sentence understates how destructive a modern attack is. The timeline from initial access to full encryption across an enterprise network can be under four hours. By the time the ransom note appears on screen, the attacker has often been inside the environment for days or weeks.
Most professional ransomware groups now operate a double extortion model. Before encrypting anything, the attacker exfiltrates a copy of sensitive files: customer records, financial data, employee personal information, intellectual property, patient records in the case of healthcare providers. The ransom demand then covers both decryption and a promise not to publish the stolen data on the group's public leak site. This means that restoring from backup resolves the operational crisis but does not eliminate the threat. The data is already in hostile hands.
The attack typically begins long before encryption. Threat actors gain initial access through phishing emails, exploitation of unpatched remote access software (Remote Desktop Protocol exposed to the internet is a perennially common entry point), compromised VPN credentials purchased from initial access brokers, or drive-by exploitation of a vulnerable browser or plugin. Once inside, the attacker spends time in the reconnaissance and privilege escalation phase: mapping the network, identifying backup systems, discovering domain administrator credentials, and ensuring they can reach as much of the environment as possible before triggering the encryption payload. Backup systems are a primary target during this phase. Attackers who delete or corrupt backups before encrypting files dramatically increase their leverage.
Three sectors face disproportionate targeting: healthcare, financial services, and hospitality. Healthcare organisations hold high-value personal data under strict regulatory obligations and face enormous operational pressure to restore systems quickly, which makes them likely to pay. Financial institutions hold funds and sensitive client data. Hospitality businesses process large volumes of card payment data and often run legacy point-of-sale systems with poor patch management. All three sectors also tend to operate across multiple sites with distributed networks, giving attackers more surface area to move through once inside.
Before an attack: the defences that matter
Prevention is not about eliminating all risk. No technical control does that. Prevention is about making your organisation a harder target than the next one, and ensuring that when an attacker does get in, the damage is contained rather than catastrophic.
Immutable, tested backups
The single most important ransomware control is a backup that an attacker cannot delete or encrypt. Immutable backups use write-once storage, either through object storage services that enforce object lock policies (AWS S3 Object Lock, Azure Immutable Blob Storage) or through dedicated appliances with immutable storage firmware. The backup must also be air-gapped, meaning it cannot be reached from your production network. A backup stored on a network share that your domain administrators can access is a backup the attacker can reach.
Testing is non-negotiable. An untested backup is a hypothesis. Run restoration exercises at minimum quarterly for critical systems and at least annually for the full environment. Document the recovery time for each critical system and compare it against your actual business tolerance for downtime. Most businesses find that the gap between assumed recovery time and tested recovery time is measured in days, not hours.
Patch management on a defined schedule
The majority of ransomware attacks exploit known vulnerabilities with published patches. The attacker does not need a zero-day. They need a CVE from six months ago that your patch cycle has not yet addressed. Establish a patch cycle with defined timelines by severity: critical patches applied within 48 hours of release, high severity within 7 days, medium within 30 days. Remote access services (VPN gateways, RDP, Citrix, Exchange) warrant the shortest timelines because they are directly internet-exposed and actively scanned by ransomware operators within hours of a vulnerability disclosure.
Multi-factor authentication on every external-facing service
Compromised credentials are the second-most common ransomware entry point after phishing. Enforce MFA on every service reachable from the internet without exception: VPN, Remote Desktop Gateway, Microsoft 365, Google Workspace, cloud console access, and any web application that authenticates users. Use phishing-resistant MFA where possible, specifically FIDO2/WebAuthn hardware keys or passkeys, rather than SMS-based one-time passwords, which can be intercepted through SIM-swapping or real-time phishing proxies. For an in-depth guide to MFA implementation, see our MFA guide.
Network segmentation
A flat network, where every system can communicate with every other system, means that a single compromised workstation can reach your backup servers, domain controllers, and financial systems without restriction. Segment your network so that production systems, backup infrastructure, guest Wi-Fi, and operational technology exist in separate zones with firewall rules governing what can communicate with what. At minimum, place backup systems in a network segment that no standard user workstation can reach, and restrict domain controller access to named management hosts.
Endpoint detection and response
Antivirus signatures catch known malware. Endpoint Detection and Response (EDR) platforms, including CrowdStrike Falcon, Microsoft Defender for Endpoint, and SentinelOne, detect behavioural patterns associated with ransomware execution: mass file encryption, shadow copy deletion via vssadmin, lateral movement using PsExec, and credential dumping via LSASS access. EDR gives your security team visibility and, in some configurations, automated containment of compromised hosts before encryption spreads. The platform is only as effective as the team monitoring it.
A written, tested incident response plan
When an attack begins, your team will have minutes to make decisions. A plan that exists only in someone's head is not a plan. Document isolation procedures for each system type, decision criteria for escalating to leadership, contact numbers for your incident response retainer and cyber insurer, and communication templates for customers and regulators. Store a copy offline, because ransomware frequently encrypts network shares and cloud-synced documents.
Paying without professional guidance. Businesses that pay ransom without engaging specialist negotiators and legal counsel often pay the full demanded amount, receive a broken or partial decryption key, and face regulatory scrutiny for potentially making a sanctioned payment. Some ransomware groups are subject to sanctions, meaning payment by a UK or EU company can itself be a legal violation.
Discovering backups were compromised. The most common failure in ransomware response is discovering that backups were also encrypted or deleted because they sat on a network share reachable from infected systems. Test your backups before you need them.
No documented response plan. Organisations without a written incident response plan take an average of 15 days longer to contain a ransomware incident than those with one. The plan does not need to be long. It needs to be specific and accessible.
During an attack: the first 24 to 48 hours
Speed matters. Every minute of network connectivity after discovery gives the attacker more time to spread, exfiltrate further data, and encrypt more systems. The goal in the first hour is to reduce the blast radius, not to investigate.
Isolate affected systems immediately
Disconnect infected systems from the network by disabling their network interfaces. Do not power them off. Powered-off systems may have encryption keys resident in memory that forensic tools can recover, and powering down destroys evidence. Disable network interfaces through the operating system or, if the system is unresponsive, physically disconnect the ethernet cable or disable the network switch port. For wireless-connected devices, disable the wireless adapter or remove the device from the wireless access point's connected client list.
If you identify the initial access point, such as a compromised VPN account or an exposed RDP service, disable it immediately. Change credentials for any account that may have been compromised, starting with domain administrator accounts, service accounts with broad permissions, and accounts associated with known phishing targets.
Do not pay immediately
The ransom note creates urgency by design. Attackers set countdown timers and threaten to publish data or increase the demand. Engaging a specialist ransomware negotiator before any payment decision buys time and reduces the amount paid in cases where payment does become necessary. Before any payment, consult legal counsel on sanctions compliance, check whether your cyber insurance policy requires insurer approval before payment, and verify that the decryption key provided after payment for similar attacks by this group has produced reliable results.
Preserve forensic evidence
Before wiping and rebuilding systems, capture forensic images of affected hosts. Collect Windows Event Logs, PowerShell history, browser history, and any suspicious files identified during initial investigation. Preserve firewall logs and network flow data from the period covering the suspected dwell time. This evidence is required for the regulatory investigation that will follow any personal data breach, for insurance claims, and for the post-incident forensic analysis that identifies how the attacker got in and whether they maintain any persistence.
Notify relevant parties
Notify your cyber insurer within the timeframe specified in your policy. Many policies require notification within 24 to 72 hours of discovery; failure to notify within the required window can void coverage. Contact your incident response retainer if you have one; if you do not, engage a specialist immediately rather than attempting to manage a large-scale incident with internal resources alone.
If personal data is involved, start the 72-hour regulatory notification clock. Under GDPR Article 33, you must notify your supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in risk to individuals. A ransomware attack that encrypts or exfiltrates personal data almost always meets the notification threshold. In the Netherlands, notify the Autoriteit Persoonsgegevens. In the UK, notify the ICO. You do not need complete information to make the initial notification; the regulation accepts an initial report with further details to follow.
Communicate internally with care
Limit information about the incident to those who need it. Premature or inaccurate communication to staff can lead to further evidence destruction (employees powering off systems), legal exposure, and media leaks. Prepare a brief factual statement for staff covering what they should and should not do. Ensure IT staff do not discuss details on platforms that may be monitored or compromised.
After an attack: recovery, forensics, and lessons
Containment ends the immediate crisis. Recovery and post-incident work determine whether the attack recurs.
Full forensic investigation before rebuilding
Rebuilding systems before completing forensics risks reinfection. Attackers frequently establish persistence through mechanisms that survive standard reimaging: scheduled tasks calling out to command-and-control infrastructure, compromised credentials reused on rebuilt systems, or supply-chain implants in software updates. The forensic investigation must identify the initial access vector, the full scope of systems accessed, the extent of data exfiltration, any persistence mechanisms left behind, and the accounts compromised during lateral movement. All compromised credentials must be reset, not just the ones visibly used during the attack.
Phased recovery from clean backups
Restore systems in priority order based on business criticality, not speed of recovery. Confirm each restored system is clean before reconnecting it to the production network. Run your EDR platform and review its telemetry on each restored host before bringing it online. If backups were also compromised, you face a longer rebuild process from scratch. Document the rebuild procedures for each critical system in advance as part of your business continuity planning, so that the rebuild process under pressure does not depend on institutional memory held by a single team member.
Regulatory notification obligations
GDPR Article 33 notification to the supervisory authority within 72 hours covers the initial report. The subsequent obligations depend on what data was accessed. Article 34 requires direct notification to affected individuals when the breach is likely to result in high risk to them, for example if health records, financial account details, or government identification numbers were exfiltrated. Sector-specific obligations layer on top of GDPR: healthcare organisations in the Netherlands face additional NEN 7510 requirements, financial institutions regulated by De Nederlandsche Bank or the FCA face their own incident reporting timelines, and PCI DSS-covered entities must notify their acquiring bank and payment brand within specified timeframes after a confirmed cardholder data compromise.
Post-incident review
Run a structured post-incident review within two weeks of containment, while the details are still clear. The review should identify the initial access vector and the control failure that allowed it, the dwell time and why detection did not occur earlier, whether the incident response plan performed as expected and where it failed, and what specific changes will prevent recurrence. Assign each remediation action to a named owner with a deadline. Do not frame findings as individual failures: ransomware incidents almost always reflect a combination of technical, process, and resource factors. The review produces a prioritised remediation list, not a blame attribution.
Every ransomware post-mortem uncovers absent controls and gaps in coverage. The work after recovery is identifying those gaps and closing them before the next attempt.
Cyber insurance review
Review your cyber insurance policy following the incident. Policies differ significantly on what they cover: some cover ransom payments, some cover forensic investigation costs, some cover regulatory fines, and most exclude coverage for incidents that result from failure to maintain basic controls (unpatched systems, absent MFA). Understand what your policy actually covers and what obligations you must fulfil to remain eligible for claims. Use the post-incident period to verify that your coverage limits reflect the actual cost of a full recovery, not the cost you estimated before you had experienced one.
What most businesses get wrong
Certain failures appear consistently across ransomware incidents at SMEs and regulated businesses. Understanding them before an attack makes the difference between a contained incident and a catastrophic one.
Backups stored on network shares. A backup stored on a shared drive accessible to domain users is a backup the ransomware will encrypt. The backup must be immutable, with write protection enforced at the storage layer, not just by access controls that a compromised domain administrator account can bypass.
Backups never tested. Backup jobs completing without errors does not mean data is recoverable. Corrupted backups, incomplete jobs, and changed system configurations regularly cause restoration failures at exactly the moment they are most needed. Test restoration of individual files monthly, test restoration of a complete server quarterly.
RDP left open to the internet. Remote Desktop Protocol on TCP port 3389 exposed directly to the internet is scanned and attacked continuously. If staff need remote access, require them to connect through a VPN with MFA before reaching the RDP session. There is no operational justification for exposing RDP directly.
No segmentation between IT and OT. Manufacturing, healthcare, and hospitality businesses with operational technology, including building management systems, medical devices, and point-of-sale systems, frequently connect these to the main IT network without segmentation. Ransomware reaching OT systems can disable physical operations rather than just data systems, and OT recovery is measured in weeks rather than days.
Paying without a decryption guarantee. Decryption keys provided after payment frequently produce corrupted or incomplete recovery, particularly for large file sets. Some groups disappear after payment without providing any key. Engage a specialist negotiator who can verify the group's reputation for honouring payments before authorising any transaction.
No documented escalation path. When the attack begins at 2am on a Saturday, which is not uncommon given that attackers time encryption for low-coverage periods, the IT manager on call needs to know who to wake up, who has authority to take critical systems offline, and where the insurance policy number is. That information needs to exist in a printed document in a physical location, not only in a file on the network that is currently encrypted.
For businesses in regulated sectors, the Autoriteit Persoonsgegevens publishes guidance on breach notification obligations. The NCSC Netherlands maintains a ransomware threat assessment and a public register of known decryption tools for certain ransomware variants through the No More Ransom project.