Who Secures Your Patient Data in the Cloud? The Shared Responsibility Model for Healthcare SaaS

Ask a busy practice owner who is responsible for securing the patient data inside their scheduling app, their billing portal, or their patient-messaging tool, and the honest answer is usually some version of: “The vendor — that’s what we pay them for.” It is a reasonable assumption. It is also the single most expensive misunderstanding in healthcare IT, because it is only half true.

Every cloud and software-as-a-service (SaaS) product your practice uses runs on a split known as the shared responsibility model. The vendor secures the platform. You secure how you use it. The breaches that hit small practices almost never come from the half the vendor owns. They come from the half the practice owns and assumed someone else was handling — a clinician account with no multi-factor authentication, a former employee whose login was never disabled, an admin role handed to someone who only needed to read reports.

This guide explains who is responsible for securing patient data in a cloud or SaaS app, what the shared responsibility model actually divides, and exactly which settings a small healthcare practice should own and configure. It closes with a reusable shared-responsibility checklist you can apply to any vendor that touches your electronic protected health information (ePHI).

What is the shared responsibility model in healthcare?

The shared responsibility model is the cloud industry’s way of drawing a line between what the provider protects and what the customer protects. The exact line moves depending on the kind of service:

• Infrastructure as a Service (IaaS) — you rent raw compute and storage. The provider secures the physical data center and hardware; you secure the operating system, applications, and data on top of it. This is the most you-own model.
• Platform as a Service (PaaS) — the provider also manages the operating system and runtime; you secure your application and its data and access.
• Software as a Service (SaaS) — the provider runs the entire application. This is what most small practices use: a finished web app like an EHR, a billing platform, or a patient-engagement tool. The vendor owns nearly everything except your accounts, your configuration choices, and your data governance.

Here is the part that trips people up: even in SaaS, where the vendor owns the most, the customer always owns identity, access, and configuration. No cloud vendor can stop a valid login from a credential you failed to revoke, an admin role you over-granted, or a staff member who was socially engineered into approving a login prompt. Those are yours by design.

The cloud provider is responsible for the security of the cloud. You are responsible for security in the cloud. In a small practice, almost every preventable breach lives on your side of that line.

For a healthcare practice, the model maps onto HIPAA cleanly. Your SaaS vendor that creates, receives, maintains, or transmits ePHI on your behalf is a business associate, and that relationship is governed by a Business Associate Agreement (BAA). But — and this is the crux — the BAA divides liability, not operational work. It does not configure MFA for you. It does not deprovision your leavers. Understanding the model is how you make sure no security task falls into the gap between “the vendor assumed we did it” and “we assumed the vendor did it.”

Does a BAA make a SaaS vendor secure?

No — and treating it as if it does is a common, costly error. A signed BAA is a contract that obligates the business associate to safeguard ePHI and to follow the HIPAA Security Rule. It is necessary, and you should never put patient data into a SaaS tool that will not sign one. HHS is explicit that a cloud service provider creating, receiving, maintaining, or transmitting ePHI on your behalf is a business associate, and that it is both contractually liable under the BAA and directly liable for compliance with the HIPAA Rules — see HHS guidance on HIPAA and cloud computing. We have written separately on which vendors in your chain actually need to sign a BAA, and on what a BAA does and does not do.

What a BAA does not do is operate the controls on your behalf. It does not turn on MFA, set password policy, define who is an administrator, review audit logs, or remove access when someone leaves. Those are configuration and governance tasks that live on the customer side of the shared responsibility line, in your tenant, under your control. A practice that signs ten BAAs and configures none of those settings has documented its liability while leaving the actual door unlocked.

This is also why a vendor breach does not automatically mean you did something wrong — and why your own clean configuration does not make you immune to one. The two halves are independent. The model’s value is that it tells you precisely which half is yours to get right.

How to secure the SaaS apps that store your ePHI

You do not need an enterprise security team to own your half well. You need to apply the same small set of controls to every app, consistently. In order of impact:

Lock down identity first

Identity is the front door of every SaaS app, and it is almost always the half you own.

• Require multi-factor authentication for every user, especially administrators. Phishing-resistant MFA where the app supports it. This is the highest-leverage control you own; we cover where it matters most in MFA for healthcare.
• Use single sign-on (SSO) if the app offers it. One identity provider you control is easier to secure and to switch off in an emergency than a dozen separate passwords.
• Set a real password policy and block reused or breached passwords where the platform allows it.

Practice least privilege

Most SaaS breaches do more damage than they should because the compromised account could see far more than its job required.

• Grant the minimum role each person needs. A front-desk user rarely needs administrator rights; a biller rarely needs to export the entire patient database.
• Limit who holds admin. Two or three named administrators is plenty for a small practice. Every extra admin is an extra high-value target.
• Review roles on a schedule — quarterly is reasonable — and after every role change.

Close the offboarding gap

The account nobody remembered to disable is a recurring theme in real incidents.

• Deprovision access the day someone leaves — every app, not just email. Keep a list of which staff have which apps so nothing is missed.
• Reclaim shared logins. If a “front desk” account is shared, you cannot tell who did what and you cannot cleanly remove one person. Move to named accounts.

Turn on the visibility the vendor already gives you

• Enable and retain audit logging. Most healthcare SaaS platforms log access to records; you often have to switch it on and choose a retention period. Logs you never enabled cannot help you investigate.
• Set up alerts for risky events — new admin added, bulk export, logins from new locations — if the platform supports them.
• Know how to export your data. Before a crisis, confirm you can get your records out. This is both a continuity control and your leverage if you ever need to leave a vendor.

Govern the data itself

• Map which apps hold ePHI. You cannot protect data you have not located; this ties directly to keeping a current asset inventory of where your ePHI lives.
• Minimize what you store. Do not load full patient histories into a tool that only needs names and appointment times.
• Configure data-sharing and integration settings deliberately. Third-party integrations and open APIs are convenient and are also a common exposure path.

A healthcare SaaS shared-responsibility checklist

Use this for every vendor that touches ePHI. The left column is the vendor’s job to deliver; the right column is yours to configure and verify. The line between them is the whole point.

Security area	Vendor’s responsibility (security of the platform)	Your responsibility (security in the platform)
Infrastructure	Data-center physical security, hardware, network, hypervisor	Nothing — but confirm they attest to it (e.g., SOC 2, HITRUST)
Platform patching	Patch the application and underlying stack	Apply any client-side updates; keep browsers/endpoints current
Encryption	Encrypt data at rest and in transit on the platform	Enable encryption options offered; use only secure connections
Identity	Provide MFA, SSO, and role capabilities	Turn them on, enforce MFA, set password policy
Access	Provide a role/permission system	Assign least privilege, limit admins, review quarterly
Offboarding	Provide a way to disable accounts	Disable departing users promptly, end shared logins
Logging	Provide audit logs and (often) alerts	Enable logging, set retention, configure alerts, review them
Data governance	Store and process data per the BAA	Map ePHI, minimize data, control integrations and exports
Contractual	Sign and honor a BAA	Obtain the BAA, confirm scope, keep it current
Incident handling	Detect platform breaches and notify you	Have your own response and notification plan ready

A practice that can answer “done, and verified” for every cell in the right-hand column has closed the gap where most preventable breaches live — without buying a single new product.

Where this fits in the HIPAA Security Rule

None of this is optional under the Security Rule. Access controls, unique user identification, audit controls, and workforce access management are existing administrative and technical safeguards in HHS’s Summary of the HIPAA Security Rule, and they apply to the ePHI you hold in a vendor’s app exactly as they do to a server in your closet. The shared responsibility model is simply the practical map of who configures what to meet those safeguards when the system is someone else’s cloud. For the bigger picture of how these safeguards fit together, see our HIPAA Security Rule hub.

The Byzantine takeaway

The cloud did not remove your security responsibilities; it moved them. Your vendors are genuinely responsible for the platform — and most reputable healthcare SaaS providers do that part well. But identity, access, configuration, and data governance never left your side of the line, and that is precisely the side attackers target, because it is the side most often left on default.

Where to start: pick your three most sensitive SaaS apps, walk the right-hand column of the checklist above for each, and fix whatever is not “done and verified” — starting with MFA on every administrator account. That is an afternoon of work that closes the most common door, and it is exactly the kind of practical, team-effort security a small practice can own without an enterprise budget. If you want a second set of eyes on which of your apps hold ePHI and whether they are configured correctly, that is a conversation worth having.