On 14 May 2025, Japan's Ministry of Health, Labour and Welfare published a cybersecurity checklist for healthcare institutions together with a manual explaining it. It is more concrete and more practical than earlier material, and notably adds treatment of cloud environments, BCP, IoT devices, and BYOD.
For providers this is a welcome instrument. Version 6.0 of the Guidelines for the Safe Management of Medical Information Systems runs to four volumes, and deciding where to start is itself difficult. The checklist serves as the way in.
Checklists also have their own characteristic failure: completion becomes the objective. Someone ticks "implemented" at their desk, submits it, and files it. The following year the same boxes get the same ticks. Used that way, the list does not reflect the institution at all.
This article is about using it as a tool that moves your controls forward.
Disclaimer: General information. The authoritative sources for the checklist, the manual, and any submission requirements are MHLW and your local authority. Confirm the current forms and process against them.
Use It as the Way into the Guidelines
| Document | Nature | Where it helps |
|---|---|---|
| Guidelines v6.0 | The requirements themselves, in four volumes: overview, governance, planning and management, system operation | Confirming the basis; different volumes for different roles |
| Checklist | A self-assessment form | Establishing where you stand, and explaining it to executives |
| Manual | Explanation of each checklist item | Understanding what each item is actually asking |
| Q&A on v6.0 (published May 2025) | Interpretive supplement | Items where judgement is unclear |
Do not complete the checklist without reading the manual. The item wording is short, so readers diverge on what counts; the manual is where the bar for "implemented" is described. See The Three-Ministry Guidelines and Practical Steps for Guideline Compliance.
How You Complete It Changes the Result
| Approach | Result | Verdict |
|---|---|---|
| One IT person fills it in at their desk | Fast, but disconnected from practice | Unusable |
| Ask the vendor | Technical items accurate, operational items unknown | Half the picture |
| Distribute to departments and collect | Close to reality, but interpretation varies | Only with the manual |
| Walk the floor and record evidence as you go | Slow — and it becomes the improvement plan | Recommended |
The recommended discipline: for every "implemented", write one piece of evidence — a clause number, a screenshot of a setting, where the records are kept, the relevant contract term. Items where you cannot name evidence are "implemented in principle" only.
The by-product is an index of where your evidence lives, reusable for audits, reimbursement requirements, and insurance underwriting (see Cyber Insurance for Healthcare Providers).
Honestly recording "not implemented" is the value of the exercise. A page of gaps is a starting point, not a failure. A page of unbroken ticks should make you doubt the assessment.
Prioritising the Gaps
Finishing the checklist leaves ten or twenty open items, and this is where most providers stall, because they cannot do all of them.
Prioritise on three axes: the size of the consequence, how easily it can be done (cost, effort, clinical impact), and whether it is required by the regulatory framework.
That ordering usually produces:
- Regulatory requirements with large consequences — multiple-method and offline backups, a drilled cyber BCP, the appointment of a safety manager, all tied to the FY2026 add-on (see A BCP for Cyberattacks, Backup Design)
- Large consequence, small cost — removing leavers' accounts, reviewing administrator rights, keeping the call tree on paper. Not a budget question, an action question
- Large consequence, large cost — replacing perimeter devices, network segmentation, rolling out MFA. Plan these across financial years
- Small consequence — documentation and records, embedded in routine work
Clear the second layer first. Items that cost nothing and matter a lot being left undone is a problem of initiative, not priority — and clearing them lets you tell executives "here is what we did without budget", which makes the third layer easier to fund.
Take the third layer to the committee and the executive meeting as a multi-year plan, minuting where this year's line falls. See Building a Security Governance Structure.
The Newly Added Topics
| Topic | Common state | What to confirm |
|---|---|---|
| Cloud | "The vendor presumably handles it" | Responsibility boundary, where data resides, where backups live, notification duties |
| BCP | Disaster plan exists; cyber does not | A plan premised on an unknowable recovery horizon, with drill records |
| IoT devices | Absent from the asset register | Inventory of networked devices, patchability, separation |
| BYOD | Tolerated silently | Rules for handling patient data on personal devices, and the real practice |
"The vendor presumably handles it" is the most dangerous sentence in the cloud column. What you hold and what the provider holds is settled by contract; leaving it vague produces areas each side assumed the other covered. See Guideline Compliance for Cloud Use, Cloud Security for Healthcare Providers, and Demarcating Responsibility.
With BYOD, start by observing practice, not by writing a rule. A policy that bans personal devices while staff exchange patient information on them is the worst of both. See Endpoint Management.
Not Repeating the Same Result Next Year
Checklists ossify when there is no path from assessment to improvement. Build one:
- Take the results to the committee and resolve on a response. Assessment is staff work; deciding is the organisation's work
- Attach an owner, a deadline, and an estimated cost to every gap. A list alone does not move
- Start next year's assessment by reviewing last year's open items, not with a fresh pass
Show executives two colours. "Implemented items went from X% to Y%; of the remainder, Z require investment, estimated at N" drives decisions better than item-by-item detail.
And treat the completed checklist as sensitive. It is a comprehensive list of your weaknesses: limit storage and access, and decide in advance what may be shared externally.
Cross-reading the results against Learning from the Structure of Incidents makes prioritisation easier; for the training plan see Designing Security Training and Drills.
Conclusion
- The checklist is the way into the Guidelines; read it with the manual or the bar for "implemented" drifts
- Record one piece of evidence per "implemented" item — anything else is aspiration
- Honest "not implemented" entries are the value. Unbroken ticks should make you doubt the assessment
- Prioritise on consequence, feasibility, and regulatory requirement — and clear the cheap, high-impact layer first
- The newly added cloud, BCP, IoT and BYOD topics are where cover is thinnest; start from the responsibility boundary and from observed practice
- Build the path from assessment to improvement: committee resolution, owners and deadlines, and next year starting with last year's list
- Treat the completed checklist as sensitive information about your weaknesses
Running the assessment is feasible in-house; converting it into priorities and an investment plan needs more. Pottech advises from the standpoint of designing and operating 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
- Guidelines for the Safe Management of Medical Information Systems v6.0 (PDF) | MHLW
- FY2026 Medical Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
Note: the checklist and manual, and any submission requirements, may be revised. Confirm the current position with MHLW and your local authority.