The EMR is down. Files are encrypted. A staff account was used by someone else. What happens first in these moments is not technical recovery — it is the scramble to establish whose responsibility this is. In most hospitals that scramble takes time, because the contract does not answer the question.
Demarcation is not something you settle after an incident. It is settled at implementation and written down. It gets deferred because procurement discussions proceed on the assumption that nothing will go wrong, and because the discussion itself is tedious both technically and contractually.
This article covers how to draw the line, what changes in the cloud, and how to write the result into contracts and SLAs. The technical design of shared responsibility is covered in AI EMR Security Design: Shared Responsibility and Zero Trust; here the weight is on reaching and documenting the agreement.
Disclaimer: General information only. Where responsibility actually falls depends on the specific contract and facts. Consult professionals and current primary sources for real contracting and dispute matters.
What You Are Actually Deciding
"Demarcation" is often used to mean "how much the vendor will look after." That is half right. Precisely, it means deciding three things for each domain:
- Operational responsibility — who runs it day to day
- Cost — who pays for recovery when it goes wrong
- Accountability — who faces patients, regulators, and the press
These three do not necessarily coincide, and that is the crucial point. A domain may be run by the cloud provider and paid for by the cloud provider, yet accountability to patients remains with the hospital, because the hospital is the party the patient has a relationship with.
So "we outsourced it, therefore it isn't our responsibility" may be true of operations and false of accountability. Outsourcing can transfer operations and cost; it cannot transfer accountability. Miss this and you will have drawn the line while leaving the important part undrawn.
| Type of responsibility | Transferable by outsourcing? | What it means in practice |
|---|---|---|
| Operational | Yes | Who runs it is set by contract |
| Cost | Yes | Liability caps and exclusions become the issue |
| Accountability | No | Patients and regulators are the hospital's to face |
Because of that asymmetry, the hospital needs to be able to explain what it delegated, even for the domains it delegated. That is the real substance of "supplier management."
How the Cloud Splits It
On premises, everything from the physical server to daily operation was one continuous stack managed by the hospital. In the cloud the stack breaks into layers, and the manager changes by layer.
| Layer | On-premises | IaaS | SaaS (cloud EMR, etc.) |
|---|---|---|---|
| Facility, power, cooling | Hospital | Provider | Provider |
| Physical servers and network | Hospital | Provider | Provider |
| Virtualization | Hospital | Provider | Provider |
| OS and middleware | Hospital | Hospital | Provider |
| Application | Hospital/vendor | Hospital/vendor | Provider |
| Access-permission settings | Hospital | Hospital | Hospital |
| User account management | Hospital | Hospital | Hospital |
| The data and what is entered | Hospital | Hospital | Hospital |
Look at the last three rows. Whichever model you choose, permissions, accounts, and data content stay with the hospital. "Go SaaS and security becomes the vendor's problem" is simply wrong.
Looking at the structure common to publicly reported incidents at healthcare organizations, the entry point is more often something left on the hospital's side — a departed employee's account still active, a shared privileged ID, a VPN appliance left unpatched — than a breach of the provider's platform. Demarcation is as much about confirming what remains yours as about choosing a vendor.
See Access Design and Privileged ID Management, Managing VPN Appliance Vulnerabilities, and Cloud Security for Medical Institutions.
The Six Areas That Stay Ambiguous
Disputes cluster in a small number of places. Clear these six first and the rest tends to settle.
1. Backups. Do not stop at "backups are taken." Who takes them, where are they held, who performs the restore, and who verifies it when? The restore actor and the time it takes are what matter during an incident. Under the FY2026 fee revision, the electronic clinical-information coordination system enhancement addition (level 1) requires backups by multiple methods with some held offline — so this line now touches reimbursement. See Backup Design for Hospitals: the 3-2-1 Rule.
2. Vulnerabilities and patching. Who applies OS and middleware patches, and who tests first? "Provider applies, hospital decides" fails unless the information needed to decide reaches the hospital. Contract for vulnerability notification.
3. Logs. Typically the provider collects and the hospital reviews. The friction points are retention period and disclosure format. Being told mid-investigation that logs expire after 30 days ends the investigation. Check whether disclosure is chargeable. See Log Management and Audit Trails.
4. First response. Who detects? Who notifies whom, within how many hours? Who holds the authority to take the service down? That last point matters: if the provider suspends service to protect other tenants, your clinic stops. Settle who decides and whether prior consultation is required.
5. Events at subcontractors. In cloud services, storage is usually subcontracted to an IaaS provider. State explicitly whether your direct counterparty bears responsibility for events there. Contracts excluding subcontractor failures as "causes not attributable to us" are common.
6. Data at termination. Return format (standard or proprietary), deadline, deletion afterwards, certificate of deletion. Data that cannot come back in a migratable format is effectively a hostage. Settling this at implementation is your leverage at the next renewal. See Security Requirements When Replacing an EMR.
Writing It Into the Contract and SLA
Make the matrix an annex
Scattered through the contract body, it cannot be consulted later. A single table classifying each domain as hospital / provider / joint, attached as an annex, is the most usable form. "Joint" exists because some domains genuinely cannot be assigned to one side — but always annotate what "joint" means, or it becomes "I assumed they were doing it."
| Item | Weak wording | Strong wording |
|---|---|---|
| Notification | Notify promptly | Notify the hospital's designated contact within 4 hours of becoming aware of the event |
| Recovery | Restore as soon as possible | RTO 8 hours, RPO 24 hours; treatment of failure per Article X |
| Backup | The provider takes daily backups | Provider takes daily backups, retains 3 generations, one of which is network-isolated; restores performed by the provider on hospital request; joint recovery test annually |
| Log disclosure | Disclosed as necessary | Audit logs retained 180 days, supplied in CSV within 5 business days of request, at provider's cost |
| Subcontracting | Work may be subcontracted | Subcontractors listed in Annex 3; changes notified in writing 30 days in advance; provider liable for subcontractors' acts |
The rule is simple: include the actor, the deadline, and the format. A clause missing those three is close to useless during an incident. See Writing SLAs and Responsibility Boundaries.
Check liability caps and exclusions
Most system contracts cap damages (a multiple of monthly fees, typically). That is unremarkable in itself, but be clear-eyed about the order-of-magnitude gap against the hospital's actual loss — lost revenue while care is suspended, patient notification, investigation, reputational recovery.
Where the cap cannot move, three substitutes exist:
- Cover your own side with insurance (Cyber Insurance for Hospitals)
- Design for fast recovery so the loss is smaller to begin with (BCP for Cyberattacks)
- Contract for specific preventive duties on the provider rather than for damages
The third is the most effective. Specifying in advance what constitutes non-performance changes vendor behaviour far more than arguing about a liability clause.
Revisit at renewal
Demarcation is not settled once. Revisit it whenever the service specification, the subcontractors, the guidelines, or your own organization changes. Making the matrix a mandatory item at contract renewal keeps document and reality from drifting apart.
Conclusion
- Demarcation means deciding operations, cost, and accountability per domain — and these do not coincide
- Accountability does not transfer. Patients and regulators remain yours
- In the cloud the manager changes by layer, but permissions, accounts, and data content always stay with the hospital
- Disputes concentrate in six areas: backups, patching, logs, first response, subcontractors, and termination data
- When documenting, include actor, deadline, and format; annotate anything marked "joint"
- Liability caps rarely move. Specifying preventive duties beats fighting over damages
For help drafting a responsibility matrix or reviewing existing contracts, contact us. To assess your current position first, start with The Three-Ministry Compliance Checklist and Implementation Steps. If you are on the provider side, see What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Version 6.0 full text (PDF) | MHLW
- On the FY2026 fee revision | MHLW
- Personal Information Protection Commission
- Information-technology Promotion Agency (IPA)
Note: where responsibility falls is determined by the specific contract and facts. Guidelines and reimbursement requirements are subject to revision; confirm against current primary sources.