Sell SaaS to hospitals long enough and the same question always arrives: "Is our data separated from the other hospitals' data?" Multi-tenancy itself is rarely the objection. What is being asked is whether you can explain the separation mechanism.
It is also the central question of your ISMS risk assessment. The tenant boundary is where a healthcare SaaS concentrates its greatest information security risk: a breach there does not end with one customer, it reaches every hospital under contract.
This article covers the risks a multi-tenant healthcare SaaS must handle in its ISMS and how to assess and treat them. On scope itself, see Designing ISMS Scope for a Healthcare Company.
Disclaimer: General information only. Interpretation of Japan's three-ministry guidelines is governed by MHLW, METI, and MIC publications; the standard, by the standard and the accreditation and certification bodies. Confirm the adequacy of a specific architecture with your customers and with specialists.
Why Multi-Tenancy Is Different in Healthcare
| Dimension | Ordinary SaaS | Healthcare SaaS |
|---|---|---|
| Impact of a leak | Commercial information | Special care-required personal data; irreversible harm to individuals |
| Blast radius | Customers within one tenant | Thousands to tens of thousands of patients per tenant |
| Impact of an outage | Work stalls | Care stops — time-critical work is involved |
| Who demands explanation | IT department | The hospital's medical information security officer, executives, sometimes auditors |
| Framework to satisfy | Contract and security policy | Three-ministry guidelines, personal information law |
The structural driver is that hospitals carry their own obligations under the three-ministry guidelines. To discharge them, they have no choice but to demand explanations from their suppliers. "It's secure" does not clear that bar; they want to know the separation mechanism and who can reach across tenants. See The Three-Ministry Guidelines.
Availability also carries different weight. An ISMS treats confidentiality, integrity, and availability in parallel, but in healthcare SaaS loss of availability stops clinical care. If your risk criteria score availability impact on an ordinary SaaS scale, the conclusions will not match reality.
Choosing a Separation Model
| Model | What it is | Strength | Cost and operation | Position in healthcare |
|---|---|---|---|---|
| Row-level | Tenant ID column, filtered in the application | Weak | Cheapest, simplest | An application bug is a breach. Hard to defend for medical data |
| Schema / database | A schema or database per tenant | Medium–strong | Moderate; heavier as tenant count grows | Easy to explain; widely adopted |
| Instance | Separate application and database instances | Strong | High; deployment and patching get complex | Premium tier for large hospitals and demanding customers |
| Account / physical | Separate cloud accounts or VPCs | Strongest | Highest | For specific demands; hard to make standard |
What matters more than the choice is being able to explain the choice and the residual risk. If you use row-level separation, show why it is sufficient and how you guarantee the filter always applies — test coverage, a shared query layer, static analysis, review discipline. In ISMS terms, that is precisely your risk treatment and risk acceptance record.
A common workable design is schema/database separation as standard, with instance separation as a premium tier. Run the risk assessment separately per model and make the configuration difference explainable in the SoA.
Detection also counts. Tests for a missing tenant ID, monitoring for cross-tenant access, alerts on anomalous extraction volume. You will be asked not only for a design that does not break, but for a mechanism that notices if it does.
Explaining Data Location and Cross-Border Transfer
Under the three-ministry framework, a supplier handling medical information is expected to make the storage location, governing law, and jurisdiction clear and explicable to the hospital.
| Item | What is checked | Commonly missed |
|---|---|---|
| Production data region | Domestic or not; which region | Managed-service metadata living in another region |
| Backup location | Same region or elsewhere | Disaster-recovery replication to an overseas region nobody noticed |
| Logs and monitoring data | Sent to a monitoring SaaS? | Patient data leaking into APM and error monitoring |
| CDN and WAF path | What is retained at the edge | Cache configured to hold personal data |
| Generative AI and external APIs | Destination, and whether data trains models | Terms changing when a feature is added |
| Where maintenance is performed | Access from overseas sites | Offshore development, 24-hour monitoring suppliers |
| Governing law and jurisdiction | Contractual terms | Cloud provider's standard terms left under foreign law |
Logs and monitoring data are the most common miss. Teams track the production database region carefully while stack traces containing patient IDs or request bodies flow to an error-monitoring SaaS. Registering logs and monitoring data as assets in their own right in the inventory closes this structurally.
Where generative AI features are embedded, document the destination, retention, and training use so it can be produced on demand. See Generative AI in Healthcare: Legal and Security and Security for AI Voice Charting. For cloud questions generally, see Cloud Security for Medical Institutions.
Backup and Restore Isolation
A frequent blind spot: tenants separated in production, mixed in backup.
- Backup granularity — one blob for all tenants, or per tenant? A single blob cannot serve a single-tenant restore request
- Restore unit — can you restore one tenant to one point in time? Whole-estate restore means one hospital's mistake affects others
- Isolation of the restore target — does the temporary recovery environment preserve tenant boundaries? A verification restore where all tenants are visible is the classic hole
- Access rights to backups — are they readable under weaker permissions than production?
- Key management — who holds the decryption keys; per-tenant or shared?
- Restore drill records — not just a procedure, but evidence it was executed
Hospitals are themselves expected to manage backup generations and recovery procedures. Asking the same of their suppliers follows naturally. Being able to state RTO and RPO per tenant shortens procurement conversations considerably.
Tenant Administration and Support Operations
Technically sound separation is routinely crossed by operational privilege. Auditors and hospital reviewers always dig here.
| Privilege | Risk | Approach |
|---|---|---|
| Cross-tenant read for staff | Support can view every hospital's data | Never standing — request, approve, time-bound |
| Impersonation | Logging in as a customer account | Always log it, and consider notifying the hospital |
| Direct production database access | Unbounded reads during incidents | Bastion, recording, approval — retain the queries |
| Deploy rights | One change affects all tenants at once | Change management, review, staged rollout |
| Tenant-side admin rights | Inappropriate grants inside the hospital | Publish recommended authorisation design and provide review tooling |
| Leavers and transfers | Rights persist | Both directions: your own review, plus features prompting the customer's |
Design impersonation with particular care in healthcare. It is genuinely useful and simultaneously a path by which the vendor can read any patient's clinical record at will. Execution logging, prior approval, or customer visibility — at least one is required, and enforcing it in the system rather than in policy alone makes audits dramatically easier.
Tenant-side administration looks like the customer's problem but is continuous with yours. If a hospital has configured "every staff member can see every patient" and an incident follows, your product design is questioned too. Documenting recommended settings and providing a feature that surfaces deviations is the realistic boundary. See Demarcating Responsibility and The Shared Responsibility Model.
Answering Per-Customer Audit Demands
As contracts accumulate, so do bespoke check sheets and requests for on-site audits. The only way to protect your team's capacity while discharging accountability is a standard explanation package that absorbs most of the individual requests.
- Certificate and scope note (one page) — showing operation and maintenance are inside registered scope
- Security white paper (10–20 pages) — separation model, data location, encryption, authorisation, logging, backup, incident response
- Three-ministry mapping table — guideline requirements against your measures
- Responsibility demarcation table — three columns: hospital, vendor, cloud provider
- Standard check sheet answers — pre-written responses, so only differences need filling
- Audit response policy — terms for accepting on-site audits and the alternatives you offer
This package can be generated from ISMS documents. Risk assessment, SoA, operating procedures, incident procedures — the hospital-facing material is those contents translated into the hospital's vocabulary. Treat the ISMS documents as the source of truth and derive the rest, so updates happen once. See Integrating ISMS Documents with the Three-Ministry Guidelines.
Knowing what hospitals ask in advance sharpens the package: Security Check Sheets for Vendors is written from the buyer's side.
Conclusion
- The tenant boundary is where the greatest risk concentrates — a breach reaches every customer, and availability cannot be scored on an ordinary SaaS scale
- What matters is explaining the choice and the residual risk, plus both a design that does not break and detection if it does
- The most-missed item in data location is logs and monitoring data — register them as assets in their own right
- Make backup and restore work per tenant; an all-tenants-visible verification restore is the classic hole
- Impersonation and direct production access will always be examined — enforce recording in the system
- Absorb bespoke audit demands with a standard explanation package derived from ISMS documents
Pottech supports ISMS certification with a focus on healthcare, including multi-tenant risk assessment and production of hospital-facing disclosure documents and risk treatment lists. Three-ministry guideline support is available as an option (from ¥1.5M).
See ISMS Certification Support or contact us. The overall picture is in What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Ministry of Economy, Trade and Industry
- Ministry of Internal Affairs and Communications
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
Note: the guidelines are revised over time, and the level of separation and explanation expected varies by customer. Check the ministries' publications for current content.