Every time a hospital cyberattack is reported, people say it could have been them. Read as individual events, though, the lesson stops at "that looks difficult." Read structurally rather than by institution and time, and a different picture appears.
Line up the published cases and the same failure shapes recur across facilities of very different size and region. It is not that weaker defences produced bigger losses; it is that facilities sharing a certain structure get stuck in the same places. Which means you can check whether your own hospital has that structure before anything happens.
This article organises the recurring structure into seven patterns and what to do about each. No institution is named, and nothing here describes attacker technique — only the defender's view.
Disclaimer: General information. For details of specific cases, consult the reports published by the institutions involved and advisories from public bodies. This is not an analysis of any particular incident.
Pattern 1: A Known Vulnerability in a Perimeter Device
The most frequently recurring structure. A VPN appliance, a remote maintenance device, an internet-facing server — with a published fix that had not been applied, or running past end of support.
There are reasons it persists. Taking perimeter devices down affects clinical care, so maintenance windows are hard to find. The maintenance vendor handles it and nobody internally knows the state. The device is old and absent from the asset register. It is a management problem, not a technical one.
| Countermeasure | Specifics |
|---|---|
| Put perimeter devices in the asset register | Model, firmware version, contract, support end date, owner |
| Fix maintenance windows in advance | In the annual plan, with a separate emergency patching procedure |
| Track support end dates | Start replacement planning a year out |
| Inventory what is reachable from outside | Verify from outside, not just from the diagram |
See Managing VPN Device Vulnerabilities and Network Segmentation and Asset Management.
Pattern 2: Backups Encrypted Alongside Production
The common factor in the longest outages: the backups sat on the same network and were encrypted at the same time. Backups existed. They were simply unusable.
Variants: the backup server ran under the same administrator account; the NAS was permanently connected; without generation management, clean data was overwritten by compromised data. "We take backups" and "we can recover" are different claims.
The FY2026 tier-1 requirement for backups by multiple methods, with some held offline, addresses exactly this structure.
| Methods stated to satisfy the tier-1 requirement | Key point |
|---|---|
| Removable media | Held on separate media (e.g. RDX), with generation management |
| Automated transfer | To NAS or similar, kept disconnected from the network at all times |
| Within a cloud service | To a logically separated area, where prompt recovery is possible |
For daily backups, retaining at least three generations is indicated. See Backup Design: the 3-2-1 Rule.
Pattern 3: No Documented Recovery Procedure
Even with intact backups, the procedure for restoring can exist in nobody's head. Backup is automated; restoration has never been attempted; the person who knew has left or cannot be reached today.
This is invisible in peacetime because "is the backup running?" is monitored and "can we restore?" is not.
- Schedule a restoration test annually, restore for real, and measure how long it takes
- Document the procedure down to the screens, and verify someone else can follow it
- Fix the order — core systems, departmental systems, authentication
- Write down dependencies — nothing else restores until authentication does
The measured restoration time is the evidence behind the RTO in A BCP for Cyberattacks.
Pattern 4: Contact Lists Trapped Inside the Affected System
A recurring cause of slow first response. The staff call tree is on the intranet; vendor contacts are in a spreadsheet on the shared drive; the maintenance contract is on the file server. All lost together.
And even on paper, contacts may not reach: the number in the contract goes unanswered at night, and nobody has a mobile number.
| How to hold it | Contents |
|---|---|
| A paper call tree, locked, in several locations | Staff, key vendors, public health centre, police, partner hospitals, insurer |
| Reachability confirmation | Out-of-hours intake, contractual response times — call once in peacetime |
| Channels independent of the hospital network | Mobiles, a separate messaging route, tested periodically |
| Copies of key contracts | Maintenance terms, SLAs, policy summary, on paper |
See Incident Response Planning.
Pattern 5: A Flat Network with No Disconnection Options
When the EHR, departmental systems, diagnostic devices, and office PCs all share one segment, containment is impossible; the only option is to stop everything.
Hospitals also run equipment that cannot be updated — diagnostic devices on old operating systems, machines locked down by the manufacturer's warranty. If it cannot be patched, it must be separated and protected.
- Segment by role: core, departmental, administrative, devices, guests
- Put unpatchable devices in a dedicated segment with minimal permitted traffic
- Draw the disconnection units and their consequences
- Separate guest and clinical wireless
See Network Segmentation and Asset Management, Securing Networked Medical Devices, and Wireless LAN Security.
Pattern 6: Broad Privileges and Leavers' Accounts
Whether an intrusion spreads is decided by privilege design: too many administrator accounts, maintenance accounts permanently enabled, accounts of leavers and transfers still active, shared IDs and passwords.
Shared IDs arise from operational necessity — a shared terminal across a night shift, the need to log in instantly in an emergency. The fault lies not with individuals but with a design that offers no alternative.
| Countermeasure | Specifics |
|---|---|
| Inventory privileged IDs | Who holds administrator rights — reviewed quarterly |
| Control maintenance accounts | Not permanently enabled; enabled on use, with logging |
| Removal on leaving or transfer | Tied to the HR process, with records of removal |
| Multi-factor authentication | External access and administrator accounts first |
| Eliminate the need to share | Provide a fast-login mechanism instead |
See Access Control and Privileged IDs, Introducing Multi-Factor Authentication, and Securing Remote Maintenance.
Pattern 7: Nobody Owns the Decision
The last pattern is organisational. Nobody has been designated to say "stop". IT staff believe they lack the authority, the administrator cannot make a technical call, the director cannot see the situation. Damage spreads in the gap.
Related structures recur: a safety manager appointed in name without real authority; a vague responsibility boundary with suppliers producing areas each assumed the other covered; no definition of "incident", so staff cannot judge what to escalate; executives treating security as an IT department matter, so investment decisions never come.
None of this can be fixed on the day. These are problems with no solution other than deciding in advance. See Building a Security Governance Structure, The Medical Information Safety Manager Role, and Demarcating Responsibility.
Checking Your Own Structure
Turn the seven patterns into questions. Anything you cannot answer is your structural weakness.
| # | Question |
|---|---|
| 1 | Can you list every internet-facing device, and when each was last updated? |
| 2 | Which of your backups is disconnected from the network? |
| 3 | When did you last test restoration, and how many hours did it take? |
| 4 | Can you find your vendors' out-of-hours numbers without using a system? |
| 5 | Can you disconnect the EHR alone? If not, what stops with it? |
| 6 | How many accounts hold administrator rights? Are any leavers' accounts still active? |
| 7 | Tonight, who decides to stop the systems — and who if they are unreachable? |
These overlap with the checklist MHLW published on 14 May 2025 — see How to Use the MHLW Security Checklist.
Conclusion
- Most entry points are known vulnerabilities in perimeter devices — an asset management and maintenance-window problem
- The main driver of long outages is backups encrypted with production, which is why tier 1 requires multiple methods with some offline
- Taking backups and being able to restore are different. Measured restoration time is your RTO evidence
- Keep contacts outside the affected systems, and verify at night that they answer
- A flat network removes every option but stopping everything. Separate what cannot be patched
- Spread is determined by privilege design; tie account removal to the HR process
- Ultimately, somebody must own the decision — and that can only be settled in advance
An outside view helps with this kind of structural review. Pottech advises on architecture and governance from the standpoint of building and running medical information systems — contact us. To assess a supplier's management system, see What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- FY2026 Medical Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: this article generalises structures common to published cases; it is not an analysis of any particular incident. Consult the institutions' own publications for specific cases.