The time between "the EMR won't open" and a hospital losing all of its functions is very short. Every time a ransomware incident is disclosed, the same words appear: outpatient services reduced, new admissions suspended, emergency intake restricted. Recoveries measured in months have been reported. The damage goes well beyond a data breach — it manifests as the suspension of care itself.
The situation on the ground is equally consistent. Staffing is thin, systems have grown complex over years of accretion, and nobody holds a complete picture of what is connected to what. Everyone knows something must be done; what is missing is a view of which measures actually reduce the probability of harm, and in what order.
This article is about that ordering. It starts with why hospitals are structurally attractive targets, sets out the intrusion patterns common to disclosed incidents, and then addresses how to assemble defence in depth. Individual technical topics are split into their own articles.
Disclaimer: This is general information. The authoritative sources for reimbursement requirements and guideline interpretation are the publications of Japan's Ministry of Health, Labour and Welfare and the notices of the regional health bureaus. This article deliberately avoids attack methodology and is written from the defender's perspective only.
Why Hospitals Are Targeted
"We hold nothing worth stealing" is a common response. But attackers are not only weighing the value of data. They are weighing the likelihood of payment — and on that measure hospitals meet the conditions structurally.
1. You cannot simply stop
A factory can price a few days of downtime as a loss. For a hospital, a system outage touches patient lives directly. Urgent availability means being forced into a position where recovery cannot wait — which is a negotiating advantage for the attacker.
2. The data is highly sensitive
Clinical records cannot be revoked by the person they describe. Alongside encryption-driven disruption, there is structural room for a second lever: the threat of publishing exfiltrated data.
3. The estate is complex and poorly mapped
EMR, billing, departmental systems (laboratory, imaging, pharmacy), networked medical devices, remote maintenance links. After years of extension, hospitals that can explain the whole picture on a single diagram are the exception. Paths you have not mapped cannot be defended.
4. Round-the-clock operation leaves no maintenance window
Patching and reboots are hard to schedule. "If it works, don't touch it," repeated over years, leaves known vulnerabilities in place.
Hospital incidents, in other words, arise less from weak awareness than from constraints inherent to how hospitals operate. That is precisely why the response has to be structural rather than exhortatory.
Security Is Now a Reimbursement Requirement
Japan's FY2026 fee revision created the Electronic Clinical Information Coordination Structure Development Addition. It abolishes and consolidates the former medical information acquisition addition and the medical DX promotion structure addition, and folds an assessment of cybersecurity measures into the result. The cybersecurity requirements previously attached to level 1 of the clinical records management structure addition have also been migrated into it.
| Tier | Points | Requirements |
|---|---|---|
| Tier 1 | 160 | Common requirements plus tier-1-only requirements |
| Tier 2 | 80 | Common requirements |
Common requirements
- Compliance with the Guidelines for the Safe Management of Medical Information Systems
- A dedicated medical information system safety management officer
Tier-1-only requirements
- Backups by multiple methods, with part of them held offline
- A BCP for cyber attacks, plus exercises
The implication is plain: security has moved from "advisable" to a condition of what you can claim. A domain that was hard to justify as investment is now connected to revenue, and the internal case for budget should be rebuilt from that starting point. For the wider revision see the FY2026 fee revision overview; for the officer role see Appointing a Medical Information Safety Management Officer.
Recurring Intrusion Patterns
Disclosed hospital incidents show repeating structures. Without naming any institution, here are the patterns a defender should check.
Pattern 1: known vulnerabilities in internet-facing devices
VPN appliances and remote access devices at the perimeter, where a fix existed but had not been applied — or where an out-of-support device remained in service. See Managing VPN Device Vulnerabilities.
Pattern 2: spread via maintenance and supplier paths
Vendor maintenance accounts and remote links. Staff accounts are often managed while the accounts handed to suppliers have never been reviewed.
Pattern 3: reused credentials and excessive privilege
Lateral movement after the initial foothold. Shared IDs, unchanged default passwords, and over-granted administrator rights shorten the distance from the first machine to the whole estate dramatically.
Pattern 4: backups encrypted along with production
The most fatal pattern. Backups sat on the same network, reachable with the same credentials, and were encrypted together with production. Cases where "we had backups" yet recovery failed almost always take this shape.
Pattern 5: no documented recovery procedure
Even with data intact, without a defined order of restoration and a defined switch to paper operation, resumption takes far longer. Only exercises close this gap — see A BCP for Cyber Attacks.
Assembling Defence in Depth
Controls aimed solely at "not being breached" eventually fail. The realistic design goal is operations that do not stop, or that can be restored quickly if they do. Ordered by return on investment:
| Priority | Layer | Purpose | Main measures | Article |
|---|---|---|---|---|
| 1 | Recovery | Be able to restore without paying | Multiple backup methods, offline copies, generations, restore tests | Backup design |
| 2 | Perimeter | Close the most-used entrance | Asset inventory, patch operations, replacing end-of-life devices | VPN vulnerabilities |
| 3 | Segmentation | Limit the blast radius | Segment design, isolating medical devices, controlling internet links | Segmentation and assets |
| 4 | Authentication | Make credentials alone insufficient | MFA on remote access and privileged IDs | Multi-factor authentication |
| 5 | Privilege | Lengthen the path of lateral movement | Least privilege, privileged ID separation, supplier accounts | Access control and privileged IDs |
| 6 | Detection | Notice it, and reconstruct it later | Log collection, retention, review | Logging and audit trails |
| 7 | Endpoints | Cut off mobile and personal devices | Asset registers, encryption, loss procedures | Endpoint management |
The order is deliberate. Layers 1 and 2 act directly on both probability and severity. Layers 3 onward limit spread after the fact — valuable, but inefficient while 1 and 2 are empty. Debates about whether to buy EDR tend to run ahead of the question of whether backups still hang off the production network.
Note also that several specific numeric requirements discussed in secondary commentary — whether EDR is mandated, how often vulnerability assessments or staff training must occur — cannot be confirmed from primary sources. When presenting requirements internally, verify them against MHLW publications and regional health bureau notices (primary confirmation required).
Using the Public Frameworks
Deciding what to do first, and explaining that decision externally, is easier on top of a public framework.
Guidelines for the Safe Management of Medical Information Systems (6.0)
The current edition is 6.0 (revised May 2023), in four parts: overview, governance, planning and management, and system operation. The readership is split by design — administrators and directors read the governance part, IT managers the planning part, operators the operations part. MHLW published a Q&A on edition 6.0 in May 2025. See The Three Ministries' Two Guidelines Explained and Implementation Steps.
The MHLW cybersecurity checklist
Published on 14 May 2025 together with an explanatory manual, it is more concrete and practical than earlier material and adds coverage of cloud environments, BCP, IoT and BYOD. It is a workable starting point for taking stock. See How to Use the MHLW Checklist.
Where cloud services are in use, the split between your responsibilities and the provider's must be drawn separately — see Cloud Security for Medical Institutions and the shared responsibility model. Understanding ISO/IEC 27001 (ISMS), the certification your suppliers hold, also makes it easier to judge their posture.
The First 90 Days
"Defence in depth" is a sound concept but not yet a plan. With limited staff, this sequence is realistic.
Days 1–30: mapping
- List every internet-facing device (VPN, remote maintenance, public servers, multifunction printers)
- Confirm the support status and end-of-life date of each
- Draw where, over which path, and when backups are taken
- Produce a list of privileged accounts and supplier accounts
Days 31–60: stopping the bleeding
- Deal with unsupported or unpatched perimeter devices — replace them or take them off the line
- Put at least one backup stream into a permanently network-detached state
- Add multi-factor authentication to remote access
Days 61–90: verification
- Actually restore from backup. Measure how long it takes
- Write down the switch to paper operation assuming the EMR is unavailable
- Run one exercise, tabletop is fine, with the people who would be involved
What you gain in 90 days is not only the controls themselves but the ability to state what is and is not in place — the precondition for both meeting the addition's requirements and negotiating with vendors.
Conclusion
- Hospitals are targeted because of structural traits — urgency, sensitivity, complexity, no maintenance window — not because of poor awareness
- The FY2026 revision ties guideline compliance and a dedicated safety management officer to the common requirements, and multi-method backup plus a cyber BCP with exercises to tier 1
- Intrusion patterns reduce to perimeter vulnerabilities, maintenance paths, credentials and over-privilege, backups encrypted with production, and missing recovery procedures
- The design goal is not "never breached" but "never stopped, or quickly restored." Order: recovery → perimeter → segmentation → authentication → privilege → logging → endpoints
- Specific numeric requirements should be confirmed against MHLW publications and regional bureau notices, not secondary commentary
- Spend the first 90 days on mapping, stopping the bleeding, and verification — a backup that has never been restored from does not count as a backup
If drawing the whole picture in-house is difficult, or you cannot judge whether a vendor's proposed configuration meets the requirements, contact us. We can help order the priorities from the perspective of people who design and operate medical information systems.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Edition 6.0 | MHLW
- On the FY2026 Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: reimbursement requirements and transitional arrangements are governed by MHLW notifications, notices and official Q&A. Guideline interpretation also changes with revisions. Please verify against current primary sources.