Backup is the highest-return area of hospital security spending. Intrusion cannot be prevented absolutely, but with a reliable path back there is no need to negotiate with an attacker. With Japan's FY2026 fee revision, this area is now also tied directly to reimbursement.
In practice, however, "we take backups" means very different things from one hospital to the next. One generation, on a NAS in the same server room, on the same network as production, reachable with the same credentials — from a ransomware perspective that is very close to having no backup at all. Most disclosed incidents where recovery failed share exactly this structure.
This article covers what the addition actually requires, which methods are accepted as meeting it, how many generations to keep, and finally the most important point: restore testing.
Disclaimer: This is general information. Reimbursement requirements and official Q&A are governed by MHLW notifications and regional health bureau notices. Base decisions on those.
"Multiple Methods, Part Offline" Is Now a Tier 1 Requirement
The Electronic Clinical Information Coordination Structure Development Addition, created in the FY2026 revision, abolishes and consolidates the medical information acquisition addition and the medical DX promotion structure addition and incorporates an assessment of cybersecurity measures. The cybersecurity requirements formerly attached to level 1 of the clinical records management structure addition have been migrated into it.
| Tier | Points | Requirements |
|---|---|---|
| Tier 1 | 160 | Common requirements plus multi-method backup (part held offline) plus a cyber-attack BCP with exercises |
| Tier 2 | 80 | Common requirements (guideline compliance plus a dedicated medical information system safety management officer) |
Backup design is therefore one of the things separating tier 1 from tier 2. The question of what it takes to move from 80 points to 160 is, in substance, whether you can run multiple backup methods with part of them offline.
Note the wording: the requirement is not "take backups" but explicitly multiple methods and part offline. Daily backups by a single method do not satisfy it. See the FY2026 revision overview and Ransomware Defence for Hospitals.
Mapping to the 3-2-1 Rule
The classic guidance is 3-2-1: three copies, on two different media or methods, with one held offsite. It was formulated against disaster and hardware failure. Ransomware adds a condition: at least one copy must be unreachable from production. Offsite but permanently connected, writable with the same credentials, still carries encryption risk.
| 3-2-1 element | Relation to the requirement | Implementation note |
|---|---|---|
| Three copies | Not directly required, but effectively needed for generations | Production plus two streams is the minimum |
| Two methods | Maps to "multiple methods" | Two configurations of the same product is a weak claim |
| One offsite | Needed for disaster recovery | Geographic distance alone is not ransomware defence |
| (Added) one offline | Maps to "part held offline" | The critical one: unreachable from production |
Offsite and offline are different concepts. A remote data centre on a permanent link is not offline. A medium detached after the job and locked in a safe in the same building is. The requirement asks for the latter property.
The Three Accepted Methods
Based on the official Q&A, each of the following is treated as meeting the requirement. Choose by scale and staffing.
Method 1: external media
Back up to external media such as RDX and store it elsewhere, with generation management. Because the medium is physically removed after the job, this satisfies the offline condition most directly.
- Strengths: offline status is unambiguous and easy to explain at audit
- Weaknesses: manual media rotation; rotations get missed; media degradation and storage control
- Fits: small and mid-sized hospitals with staff able to run a daily routine
Method 2: automated transfer (NAS and similar)
Transfer backups automatically to a NAS held permanently detached from the network, connected only for the transfer itself.
- Strengths: no manual rotation; fewer missed jobs
- Weaknesses: the design hinges on how "permanently detached" is technically assured; configured loosely it becomes an ordinary NAS on the same network
- Fits: hospitals unable to staff a daily routine — with care over design and evidence
Method 3: within a cloud service
Back up to a logically separated area within a cloud service, in a state permitting prompt recovery.
- Strengths: no media handling; remote storage satisfied at the same time
- Weaknesses: logical separation depends on provider capability; the responsibility split must be settled
- Fits: hospitals already running cloud-based systems
Choosing: since tier 1 requires multiple methods, combining two or more is the baseline. A common shape is daily automated transfer plus weekly or monthly external media — automation prevents missed jobs while a physically detached copy is still held.
For cloud methods, confirm in writing where the provider's responsibility ends. See Cloud Security for Medical Institutions, the shared responsibility model, and — for reading a supplier's own posture — ISO/IEC 27001 (ISMS).
Deciding Generations
"The latest backup is enough" does not hold against ransomware. Time often passes between intrusion and encryption, so the latest copy may already be contaminated. You need generations to fall back to.
| Frequency | Guide | Note |
|---|---|---|
| Daily | At least three generations | Confirmed guide |
| Weekly / monthly | No single figure given | Said to vary with hospital scale and method |
Three daily generations is a floor. Being able to go back three days presupposes detecting an intrusion within three days. Given that detection can take longer, holding longer weekly or monthly generations in one of the methods is the safer posture.
Three decisions settle most design arguments:
- RPO — how much data loss is acceptable. Daily backups mean up to a day of records
- RTO — how long until services resume. This drives method selection
- Look-back window — how far you can reach for an uncontaminated generation
In hospitals, RPO and RTO differ by department and function: care may continue if the EMR can be read, while billing being down stops claims entirely. A prioritised restoration order, rather than a single figure for all systems, is what makes the plan work — design it together with a BCP for cyber attacks.
An Untested Backup Does Not Count
This is the central point.
Backup discussions gravitate to how data is captured. What matters in an incident is whether it comes back — a different question. Plenty of structures capture successfully yet cannot restore:
- Jobs succeeded, but a database had fallen out of scope
- The media are readable, but the licence information needed to rebuild lived only on the production server
- The procedure existed only in a vendor engineer's head, and that engineer could not be reached
- The administrator password needed for recovery was stored in an encrypted file that was itself encrypted by the attacker
- Restoration worked, but took five times the assumed duration, with no interim fallback defined
None of these are technical failures. They are failures of verification — and a single restore test would have surfaced every one.
| Item | Decide | Record |
|---|---|---|
| Scope | Which systems | What was excluded and why |
| Frequency | How many times a year | Date and participants |
| Environment | Production or test | Differences from production |
| Procedure | Who does what, in what order | Deviations from the written procedure |
| Duration | Target time | Measured time — the most important figure |
| Criteria | What counts as success | Result and corrective actions |
Measured duration is the premise of the BCP itself. If paper fallback was prepared on the assumption of one day and restoration actually takes a week, the volume of paper forms and the decision to call for outside help both change.
Tier 1 also requires a BCP and exercises. Restore testing sits at the centre of those exercises. Treating backup design and drills as one activity — proving that you can come back — is more efficient in both effort and evidence than running them separately.
A Checklist for Operations
| # | Check | How |
|---|---|---|
| 1 | Nothing missing from scope | Verify beyond the EMR: billing, departmental systems, file servers, configuration |
| 2 | Genuinely multiple methods | Not two configurations of one product |
| 3 | Part of it offline | Unreachable from the production network — can you show it on a diagram? |
| 4 | Credentials separated | Can a production admin account delete the backup area? |
| 5 | Enough generations | At least three for daily; can you state the look-back window? |
| 6 | Job outcomes monitored | Who is notified on failure, and does anyone read it? |
| 7 | Restore tested | Last date, measured duration, corrective actions |
| 8 | Procedure documented | Executable without one specific person |
| 9 | Recovery information held outside production | Licences, passwords, contacts, configuration |
| 10 | Supplier role defined | What the vendor covers, per contract and SLA |
Items 4 and 9 are the ones most often missed. A configuration where production administrator rights can also delete backups loses the backups the moment those rights are taken. See Access Control and Privileged IDs and Segmentation and Asset Management.
Conclusion
- The new addition makes multi-method backup with part held offline, plus a BCP and exercises, a tier 1 (160 point) requirement
- Accepted methods are external media, automated transfer to a permanently detached NAS, and a logically separated area within a cloud service — combined, since multiple methods are required
- Offsite is not offline. A permanently connected remote copy is not ransomware defence
- Keep at least three generations for daily backups; no single figure is given for weekly or monthly
- Decide RPO, RTO and look-back window, and prepare a prioritised restoration order per system
- A backup you have never restored from does not count. Measured restore duration is the premise of the BCP, and testing is best folded into the exercise requirement
If you are unsure whether your configuration meets the requirement, or whether a vendor's proposal qualifies as "multiple methods, part offline," contact us. We can read the architecture with you and identify what is missing.
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)
Note: requirements, generation guidance and the interpretation of methods are governed by MHLW notifications, notices and official Q&A, and may change with future revisions.