Every proposal for a cloud EMR or departmental system says "compliant with the three-ministry guidelines." What that line means varies enormously between vendors. Sometimes it means everything the guidelines require of a provider has been implemented. Sometimes it means the provider has counted items the hospital is supposed to perform and written "we can support this."
The difficulty with cloud is that the range a hospital can verify for itself narrows sharply. With an on-premises server you can walk to the rack, open the configuration screen, pull the logs yourself. In the cloud, nearly all of that moves into territory where you depend on what the provider tells you. Which makes what you require them to explain the heart of selection.
This article sets out seven things to check when choosing the cloud provider that will hold your medical information. For the broader question of cloud use and internal arrangements, see Cloud Security for Healthcare Organisations; for the regulatory side of offsite storage, Requirements for External Storage of Medical Information.
Disclaimer: This article is general information. The authoritative texts are the MHLW guidelines and the METI/MIC provider guidelines. Consult counsel on contract terms.
The Seven Criteria at a Glance
| # | Criterion | What to verify | Risk if you cannot |
|---|---|---|---|
| 1 | Guideline alignment | Which ministry's guideline, which requirement, performed by whom | "Compliant" cannot be checked |
| 2 | Data residency | Country/region for production, backups and logs separately | Offshore storage surfaces and cannot be moved |
| 3 | Certification | Name, number, certified scope, expiry | Certified — but your service is out of scope |
| 4 | Subcontracting transparency | Platform, monitoring, development, support | An unseen third tier touches production |
| 5 | Segregation and encryption | Tenant separation method, encryption at rest and in transit | A multi-tenant incident propagates |
| 6 | Availability and recovery | SLA, RTO/RPO, backup method, restore testing | You cannot meet the fee criteria |
| 7 | Exit and data return | Format, deadline, cost, proof of deletion | Effective lock-in |
Of these, items 2, 3, 4 and 7 cannot be changed after signing. Residency is baked into the architecture, certification scope is the provider's own business decision, the subcontracting chain is their business model, and return terms cannot be added later if they are not in the contract. Put the weight of your selection on those four.
Verifying Guideline Alignment
| Bound party | Ministry | Guideline |
|---|---|---|
| Hospitals | MHLW | Guidelines for the Safe Management of Medical Information Systems (6.0, May 2023) |
| Providers | METI / MIC | Guidelines for safe management by providers of systems and services handling medical information |
A cloud provider is directly bound by the latter. The MHLW guidelines come in four volumes — overview, governance, planning, and operations — addressed respectively to decision-makers, managers and operators. Where cloud is used, parts of the planning and operations requirements end up performed by the provider.
In practice the effective step is to require a mapping table giving the performing party for each requirement. A one-line "we comply" cannot be checked; a table forces blanks and "performed by the hospital" entries into view, and doubles as the blueprint for your own arrangements. See The Three-Ministry Guidelines and Implementation Steps.
MHLW published a Q&A on edition 6.0 in May 2025, and on 14 May 2025 a cybersecurity checklist and manual for healthcare organisations covering cloud, BCP, IoT and BYOD — a useful base for building your provider questions.
Ask About Residency in Three Parts
Plenty of providers will answer yes to "is the data stored in Japan?" The question is insufficient, because production data, backups and logs can live in different places.
| Subject | How to ask | Common reality |
|---|---|---|
| Production | State the region where data is stored | Usually a domestic region |
| Backups | State the region where backups are stored | Often a second region for redundancy; sometimes offshore |
| Logs and audit trails | State where logs are held and for how long | Frequently forwarded to a monitoring SaaS, sometimes offshore |
| Operator location | State the countries where staff operating production are located | 24/7 monitoring is often run from an overseas site |
| Temporary copies | Is data copied elsewhere during fault investigation? | Copying to a development environment is often unprocedured |
The fourth row is a separate question from physical residency. Data in a domestic region that is administered by people abroad is, in effect, accessible across the border. Do not stop at "the data is in Japan" — ask who touches it.
The fifth is also missed. Copying production data to a development environment or a support engineer's machine during fault investigation is common. Agree before signing whether it is prohibited or governed by a procedure — request, approval, time limit, deletion afterwards.
Reading Certifications: Not Whether, But How Far
| Certification | Subject | What it means to a hospital |
|---|---|---|
| ISO/IEC 27001 (ISMS) | Information security management generally | The most broadly applicable evidence; scope must be checked |
| ISO/IEC 27017 | Cloud-specific controls | Additional evidence for a provider holding medical data in cloud |
| ISO/IEC 27018 | Personal data in public cloud | Controls on handling personal data |
| Privacy Mark | Personal information (domestic scheme) | Well recognised in Japan; limited to personal data |
| SOC 2 | Service organisation controls | A report, not a certification — you must read the report itself |
What matters is not possession but three things:
- Certified scope — which sites and services; is the service you are buying inside it?
- Validity — not lapsed or suspended; the accreditation body's register can be checked by certificate number
- Platform versus provider — "AWS/Azure holds the certification" and "the provider building on it holds one" are different facts
The third comes up constantly. Proposals do present a platform's certification as if it were the provider's own. A physically hardened platform says nothing about the permission model or logging design of the application above it — those are the provider's responsibility. Separate which side of the shared responsibility model is being discussed. See Security Design and the Shared Responsibility Model for AI EMRs.
Japan's ISMS accreditation body is ISMS-AC. On how certification and scope work, see What Is an ISMS? and Defining ISMS Scope.
Transparency of Subcontracting
Cloud services are structurally layered. Behind the provider you contract with sit the platform, monitoring services, a CDN, mail delivery, outsourced development. Sign without seeing that chain and, when something goes wrong, you cannot even locate where it went wrong.
| Type | What to verify |
|---|---|
| Platform | Provider, region, services used |
| Monitoring and operations | Whether outsourced, to whom, with what access |
| Development and maintenance | Country of the development site; any offshoring |
| Support desk | Whether outsourced; whether it can reach patient data |
| Change notification | Whether you are told before a subcontractor changes |
The last row is the practical one. Verifying the chain at signature is not enough — it changes during the term. Whether a prior-notice clause exists determines whether your picture stays current. See Supply Chain Risk for Hospitals.
Data Return on Exit
The most neglected criterion at selection, and the most regretted later. Cloud migration costs are high, and without return terms in the contract you lose all leverage at the next replacement.
| Item | What the contract should say |
|---|---|
| Format | CSV, a standard format (e.g. SS-MIX2), or a database dump — avoid proprietary-only |
| Coverage | Clinical data only, or also attachments, images and audit logs |
| Deadline | How many days after termination delivery occurs |
| Cost | Whether the work is chargeable, and how it is calculated |
| Migration cooperation | Whether they will brief the successor vendor and disclose data specifications |
| Deletion | When deletion completes including backups, and issuance of a certificate |
Format is the crux. If data can only leave in a proprietary shape, migration acquires a conversion project, with the cost and schedule that implies. Make "must be exportable in a standard format" a requirement at purchase. See Security Requirements for EMR Replacement and The EMR Data Migration Guide.
Backup deletion is again the item that slips. Deleting production leaves generations in backup. Confirm whether "deletion complete" includes them, and by when.
Availability, Recovery, and the Fee Criteria
Level 1 of the FY2026 electronic clinical information coordination system development addition requires backups by multiple methods with part held offline, plus a BCP for cyberattacks with exercises. On a cloud system, whether you can satisfy this depends on how the provider delivers the service.
Official Q&A indicates that a cloud-internal approach — backup to a logically separated area within the cloud service, where prompt recovery is possible — also satisfies the criterion. So cloud is not disqualifying. But you must confirm whether the architecture genuinely constitutes a "logically separated area." A copy into another bucket inside the same account is lost with the account.
Check specifically:
- Whether backups sit behind a different permission boundary from production
- The number of generations retained (at least three is indicated for daily backups)
- Whether restore tests have actually been performed, and how often
- Measured — not estimated — recovery time
See Backup Design for Hospitals: the 3-2-1 Rule, A BCP for Cyberattacks, and The FY2026 Fee Revision.
Conclusion
- Weight selection towards the four things you cannot change after signing: residency, certified scope, subcontracting, exit terms
- Verify guideline alignment through a mapping table of who performs each requirement, not a declaration
- Ask about residency separately for production, backups and logs — and about where operators are
- For certifications, read scope, validity, and platform-versus-provider
- Subcontractors change during the term; require prior notice
- Put format, coverage, deadline, cost, cooperation and deletion into the contract; refuse proprietary-only export
- To meet the fee criteria, confirm backups sit behind a different permission boundary
Comparing cloud providers from proposals alone rarely reveals differences; differences appear once you build the questions and line up the answers. For a review of existing cloud contracts or requirements ahead of a replacement, contact us. If you are on the provider side and being asked to evidence your posture, see ISMS certification support.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines, edition 6.0 (PDF) | MHLW
- FY2026 Fee Revision | MHLW
- Information Management System Accreditation Center (ISMS-AC)
- Personal Information Protection Commission
Note: guideline requirements and fee criteria change with revisions and official Q&A. Check the latest published material.