Lesson 1.1: Weekly Deep Dive

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Weekly Deep Dive! Over the next 45 minutes, we will explore the anatomy of a ransomware attack, the critical role of offline backups, and how a single incident can ripple through an organisation, affecting patient care, regulatory standing, and financial stability.

But first, let me tell you about Dr. Anya Sharma.

It's 3:17 AM on a Tuesday in October. Dr. Anya Sharma, a senior radiologist at University Medical and Midland Centre (UMMC) in the UK, is reviewing a CT scan for a suspected stroke patient. The glow of three monitors illuminates her tired face. The only sounds are the hum of the server rack and the distant beep of a monitor from the ICU. She clicks to pull up a previous scan for comparison.

The screen freezes. A spinning wheel appears. Then, all three monitors go black. A moment later, a single red window pops up, centred on each screen. The text is simple, stark, and final: 'ALL YOUR FILES ARE ENCRYPTED. TO DECRYPT, PAY 50 BITCOIN. YOU HAVE 72 HOURS.' Her heart sinks. She tries to access the patient's electronic health record. Access denied. The PACS imaging system is offline. The internal paging system is silent.

Anya picks up the phone to call IT. The line is dead. She runs to the nursing station. Every computer shows the same red message. A junior doctor holds up a tablet, its screen also hijacked. In that moment, Anya realises the hospital's digital nervous system has been severed. Her decision is immediate and instinctive: she grabs a pen and paper to write down the patient's vital signs before she forgets them, the first step in a sudden, desperate return to analogue medicine.

This is the story of Ransomware. By the end of this lesson, you'll understand exactly why Anya and UMMC never stood a chance against this particular attack, and more importantly, what could have saved them.

Content Section 1: The Anatomy of a Healthcare Ransomware Attack

A ransomware attack on a hospital isn't just a data breach; it's a direct assault on patient care. Think of it not as a theft, but as a digital siege. The attackers don't just lock the doors; they pour concrete into the locks, cut the phone lines, and shut off the power, all while demanding a ransom for the keys they claim to hold.

Beyond Data Encryption: Operational Paralysis

The immediate goal of ransomware is encryption, but the real impact is systemic failure. At UMMC, the attack encrypted patient records, diagnostic imaging systems, lab results, and appointment schedules. Clinical staff lost access to the information needed for diagnosis and treatment.

This operational paralysis creates a direct patient safety risk. Without access to digital records, doctors cannot check for drug allergies. Radiologists cannot compare new and old scans. Surgeons cannot review pre-operative notes. The hospital is forced into a chaotic, paper-based mode of operation that is slow and prone to error.

The financial pressure is immense. For every day systems are down, the hospital loses revenue from cancelled procedures and appointments. There are also immediate costs for incident response, forensic investigation, and potential regulatory fines. The ransom demand itself is often just one part of a much larger financial blow.

The Paper Backup Lifeline

In the wake of the attack, UMMC's most important tool wasn't a piece of software, but paper. Staff reverted to handwritten notes, paper drug charts, and printed patient lists. This 'paper backup' process is a recognised, if archaic, disaster recovery step.

However, paper backups have severe limitations. They cannot scale to the volume of modern healthcare data. A single patient's full digital record is impossible to replicate on paper in a useful way. Paper is slow to search, easy to misfile, and introduces new risks of transcription error. Relying on paper backups is an admission that the primary digital systems have completely failed.

DORA Article 5-17 DORA's ICT risk management framework requires financial entities (and by analogy, critical service providers like hospitals) to have backup policies and restoration procedures that ensure operational continuity. The UMMC incident shows a failure in the restoration element, forcing a fallback to inadequate paper processes.

ISO A.5.1 ISO 27001 A.5.1 requires management to establish and review information security objectives. A core objective must be the availability of critical systems. The ransomware attack demonstrated that UMMC's objectives for system availability were not met, leading to a management failure that impacted patient safety.

Content Section 2: How the Attack Unfolds: From Phish to Paralysis

Understanding the ransomware attack chain reveals why it's so effective. Let me show you exactly how an organisation like UMMC was compromised, step by step.

The Initial Foothold

The attack almost certainly did not begin with a sophisticated zero-day exploit. Industry data indicates the most common entry point is much simpler: a phishing email. A single employee in the billing department, or a doctor checking email on a hospital workstation, clicks a link or opens an attachment.

That click downloads a dropper—a small, seemingly innocent program. Its job is to call home to the attacker's command-and-control server and download the real payload: the ransomware binary and often, a separate tool for moving laterally through the network.

Once inside, the attackers don't immediately trigger the encryption. They lie low, often for days or weeks. They use stolen credentials or exploit vulnerabilities in internal systems to move from the initial workstation to servers. Their goal is domain controllers, file servers, and backup systems.

The Encryption Trigger and The Demand

With access to critical systems and backups compromised, the attackers deploy the ransomware encryptor across the network simultaneously. Modern ransomware is fast; it can encrypt terabytes of data in hours. The UMMC staff likely saw their screens freeze as the encryptor worked through files.

The ransom note is then displayed. The demand of '50 Bitcoin' is not arbitrary. It's calculated to be high enough to be worth the criminals' time, but just low enough that an organisation might consider paying it as a 'cost of recovery' compared to a prolonged outage. The 72-hour deadline creates urgency and panic, pressuring decision-makers.

Why Common Defences Were Bypassed

Notice what all of these methods have in common. They exploit the gap between a technical control and human behaviour, or they use the organisation's own trusted systems and credentials against it. The attack doesn't break down the walls; it walks through the front door with a stolen key.

UMMC likely had security tools in place. Here’s how a determined ransomware group bypasses them:

NIST PR.IP-9 NIST CSF PR.IP-9 requires response and recovery plans to be in place. The UMMC incident tests this control. A plan that only relies on digital backups that can be encrypted is incomplete. The plan must include immutable or offline backups, which this lesson demonstrates are non-negotiable.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures. For a hospital, a core risk is system availability. The ransomware attack shows that UMMC's risk management failed to adequately address the risk of total encryption and the specific need for isolated, recoverable backups.

Content Section 3: Seeing the Signs: Detection Before Encryption

Anya's computer knew something was wrong. The system likely showed subtle signs for days before the encryption started. It just couldn't tell her. Effective detection looks for these precursor activities, not just the encryption event itself.

Network-Level Indicators

Long before the encryption, the infected machine called out to the command-and-control server. This communication might be disguised as normal web traffic, but security tools can spot anomalies: connections to newly registered domains, communication with IP addresses in high-risk countries, or unusual data volumes leaving the network.

Later, during the lateral movement phase, there will be a spike in internal network traffic. A single workstation making SMB or RDP connections to dozens of servers in a short period is a major red flag. This is the attacker 'spreading' their access.

The final warning sign is often mass file access. The ransomware encryptor will read thousands of files in rapid succession. Monitoring for a single system account accessing an abnormal number of files across multiple shares is a clear signal of an active encryption process.

Endpoint-Level Indicators

On the compromised workstation, you might see the execution of unusual tools. Attackers use built-in system administration tools like PowerShell or Windows Management Instrumentation (WMI) to move laterally. A surge in PowerShell scripts, especially with obfuscated commands, is a key indicator.

Another sign is the disabling of security software. The ransomware payload will often try to stop antivirus processes or delete volume shadow copies (a Windows feature that can be used for file recovery) before it begins encrypting. Alerts for these actions are critical.

Identity and Access Signals

The most telling signals often come from your identity provider. Look for a single user account logging in from multiple locations at impossible times, or a successful login from a geographic location the user has never been.

Privilege escalation is another major signal. An alert for a standard user account being added to the local administrators group, or a service account being used to interactively logon to a server, indicates an attacker is strengthening their hold on the environment.

SOC2 CC7.1 SOC 2 CC7.1 requires monitoring procedures to identify changes that introduce vulnerabilities. The ransomware attack chain involves multiple detectable changes: new malicious processes, disabled security controls, and anomalous user behaviour. This lesson provides the specific indicators that fulfil this monitoring requirement.

GDPR Article 32 GDPR Article 32 requires a level of security appropriate to the risk, including the 'ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems.' The failure to detect the ransomware precursor activities compromised the availability and integrity of patient data processing systems at UMMC, representing a potential breach of this article.

Content Section 4: Building Your Compliance Evidence

Compliance frameworks are often seen as a checklist, but in the context of ransomware, they are a blueprint for survival. The UMMC story shows what happens when the principles behind the controls are not fully implemented. Your work in this lesson turns those principles into demonstrable evidence.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate an understanding of ICT incident management by analysing the UMMC case study. You can document that you have assessed your backup restoration procedures against a scenario of total system encryption, a key part of operational resilience.

For ISO A.5.1 auditors... For ISO 27001 assessors, you can evidence management review of information security objectives related to availability. The lesson's analysis of UMMC's failure provides a concrete example against which to review and test your own organisation's objectives and controls.

For NIST PR.IP-9 auditors... For NIST CSF reviewers, you can show you have evaluated your response and recovery plans against a specific, high-impact threat (ransomware). The activity on Backup Resilience Assessment directly contributes to improving the 'Recovery' function of your framework.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified

Conclusion

Let me tell you how Anya's story ended.

UMMC did not pay the ransom. The restoration took over two weeks. During that time, elective surgeries were cancelled, outpatient appointments were postponed, and staff worked under immense stress using paper systems. While no patient deaths were directly attributed to the attack, the hospital later acknowledged that care was delayed and the risk of error was significantly increased. Anya spent the following month auditing every paper record she had created, translating them back into the digital system, a tedious and demoralising task.

The organisation eventually invested in a new, isolated backup appliance with immutable storage, meaning backups cannot be altered or deleted once written. They implemented stricter email filtering and mandated multi-factor authentication for all administrative accounts. The incident response plan was rewritten to include a clear 'declare disaster' threshold that triggers the shift to offline backups.

But it doesn't have to be your story. That's why we're here.

You should now understand that ransomware is an availability crisis, not just a confidentiality one. You understand the attack chain from phishing to encryption and why traditional defences are often bypassed. You know the key detection indicators that happen before the encryption event. And you understand why offline or immutable backups are the single most important control for recovery.

Next, we'll explore Next, we'll explore Lesson 1.2: The Regulatory Fallout. We'll look at how incidents like UMMC's trigger investigations from bodies like the FDA and the ICO, and how to manage the compliance aftermath.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators (network, endpoint, identity) and immediate isolation/response steps for a suspected ransomware incident on a single page.
• Compliance Mapping Worksheet - Map your organisation's ransomware-specific controls, like immutable backups and incident response plans, to the DORA, ISO 27001, and NIST CSF requirements discussed in this lesson.
• Risk Assessment Template - Assess your organisation's exposure to ransomware based on the attack vectors covered (phishing, lateral movement, backup targeting) and identify gaps in detection and recovery capabilities.
• Further reading - Links to the NCSC guidance on mitigating malware and ransomware, and the NIST SP 800-83 guide on malware incident prevention and handling.

Weekly Update: UMMC on paper backups after ransomware attack | 2 injuries spur FDA recall Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026