What does HIPAA require for cloud computing in healthcare?
HIPAA cloud computing means running healthcare workloads on third-party cloud infrastructure, such as AWS, Azure, or Google Cloud, while still meeting every administrative, physical, and technical safeguard the HIPAA Security Rule requires for electronic protected health information (ePHI). The cloud provider secures the infrastructure underneath. The covered entity remains responsible for everything configured on top of it, backed by a signed Business Associate Agreement (BAA) and a documented risk analysis covering exactly where ePHI lives in the cloud.
That last sentence is the part most organizations get wrong, and it is expensive when they do.
Not Sure Where Your Cloud Liability Actually Starts Under HIPAA?
The Part of Cloud Compliance Nobody Configures Correctly
A signed Business Associate Agreement with AWS, Azure, or Google Cloud does not transfer your HIPAA liability. It adds another party who can be liable alongside you. That distinction has already cost one healthcare organization $2.7 million, and the same gap keeps showing up in OCR’s most recent settlements.
In a typical cloud migration review, the first thing we check is not the encryption settings. It is whether anyone can actually produce the BAA for every service touching ePHI, not just the primary hosting provider, but the backup tool, the monitoring dashboard, the e-fax integration someone set up two years ago and forgot was even connected. More often than we would like, that list has a gap nobody noticed because the service “just worked,” and working is not the same as covered.
Here is the uncomfortable math: cloud providers secure the data center, the hypervisor, the physical hardware. You configure the identity permissions, the encryption settings, the network rules, the access logging. If someone on your team or your MSP’s team leaves a storage bucket public, that is not AWS’s failure. AWS built a secure storage product. A person configured it wrong. HIPAA does not care whose cloud it was. It cares whether ePHI was exposed and whether you can prove you did your due diligence beforehand.
This guide breaks down exactly where that line sits: what your cloud provider owes you, what you owe your patients, and what OCR has already proven it will fine you for getting backwards.
Is the Cloud HIPAA Compliant?
No cloud platform is HIPAA compliant on its own. There is no official HIPAA certification for cloud infrastructure. A cloud provider can offer the tools and configurations needed to support compliance, encryption, access controls, a signed BAA, but compliance itself depends on how the covered entity configures and documents its use of those tools.
According to the U.S. Department of Health and Human Services’ guidance on HIPAA and cloud computing, a covered entity may use cloud services of any configuration, public, hybrid, or private, provided it executes a BAA with the cloud service provider, and the type of configuration used can itself affect the required risk analysis. In plain terms: the government has already said the cloud is fine. It never said configuration-agnostic was fine.
When a vendor tells you their cloud is HIPAA compliant, what they mean is they offer the tools and configurations needed to support your compliance, provided you use them correctly. That distinction is not pedantic. It is the entire reason breaches happen even when the underlying infrastructure was never at fault.
Your cloud provider handles: physical data center security, hardware redundancy, the underlying network infrastructure, and the security of their managed services as built. AWS, Azure, and Google Cloud all offer a BAA covering specific in-scope services, the contractual document making them legally accountable as a business associate under HIPAA.
You handle: identity and access management, encryption configuration, network segmentation, audit logging, incident response, and proving all of it through documentation. The provider gives you a locked building. You are still responsible for deciding who gets a key.
What that split looks like in practice depends on which kind of cloud service you are actually running, and that detail matters enough to earn its own section below.
| Cloud Service Model | Provider Responsibility | Customer Responsibility |
|---|---|---|
| IaaS (e.g. AWS EC2, Azure VMs) | Physical hardware, hypervisor, network backbone | OS, patching, encryption, network config, identity management |
| PaaS (e.g. managed databases, serverless) | Platform security, underlying patching | Access configuration, data handling, application logic |
| SaaS (e.g. practice management, billing tools) | Nearly all security layers under the product | User access management, account hygiene, BAA verification |
What Has OCR Actually Penalized in Cloud and BAA Cases?
OCR has penalized healthcare organizations for storing PHI in the cloud without a signed Business Associate Agreement, most notably Oregon Health & Science University’s $2.7 million settlement in 2016. More recently, OCR’s enforcement pattern has centered on missing or incomplete risk analyses that fail to account for cloud environments, the single most-cited deficiency in current Security Rule investigations.
Most HIPAA-and-cloud content references breach statistics in the abstract. Here is what actually happened when cloud-specific failures landed in front of regulators.
In 2016, Oregon Health & Science University settled with OCR for $2.7 million after storing the PHI of more than 3,000 patients on a cloud-based server with no Business Associate Agreement in place. Not a sophisticated attack. Not a zero-day exploit. A storage decision made without the one contract HIPAA explicitly requires before ePHI touches a third party’s infrastructure. The data itself may have been reasonably secure. The absence of a BAA made the organization liable regardless.
That case is nearly a decade old, and the lesson has not aged out. According to OCR’s own 2024 Report to Congress, the agency identified numerous instances where regulated entities’ risk analyses were inadequate, incomplete in scope, or never conducted at all, a finding specific enough that OCR launched a formal Risk Analysis Initiative in October 2024 targeting exactly this gap. That risk analysis has to explicitly account for cloud environments, not just on-prem systems, to satisfy the requirement under 45 CFR §164.308(a)(1). If you’re not sure whether what you’ve already done qualifies, how a Security Risk Assessment differs from a general IT review is worth reading before your next audit finds out for you.
Civil monetary penalties have also climbed with inflation. As of the latest HHS adjustment, effective January 28, 2026, the steepest tier, willful neglect not corrected within 30 days, now tops out at $2,190,294 per violation, with the same number applying as the annual cap for repeated violations of the same provision. That’s not a hypothetical ceiling. It’s the number OCR can actually write on a check request.
The pattern across every cloud-related enforcement action wears different details but the same root cause: someone assumed the cloud vendor’s security posture was the whole answer. It never is. A vendor that can’t view your encrypted data because it doesn’t hold the decryption key is still your business associate under HIPAA, a point OCR has stated explicitly: even a cloud service provider that only stores encrypted ePHI and lacks the key is still a business associate under the rule. Encryption changes what they can see. It doesn’t change what they’re liable for, or what you’re liable for either.
What Safeguards Apply Once ePHI Leaves Your Building?
The HIPAA Security Rule organizes its requirements into three categories, codified under 45 CFR Part 164, Subpart C. Cloud computing does not replace any of them. It just changes where you implement them.
Administrative safeguards are the paperwork that proves the technology means something. This includes a current, cloud-environment-aware risk analysis, workforce training on cloud-specific risks like shared accounts and public link sharing, a named compliance officer, and vendor oversight covering every cloud subcontractor that might touch ePHI, not just your primary provider. If you’re vetting a cloud or security vendor’s compliance posture specifically, MSSP for Healthcare: What HIPAA Requires from Your Security Partner breaks down the six criteria any provider touching your ePHI actually has to meet. More than half of the Security Rule’s actual requirements live in this category, and it is the category OCR cites most often when things go wrong. What HIPAA actually requires across mandatory and voluntary frameworks in 2026 maps each safeguard category to the specific provisions OCR investigates and the enforcement actions that have resulted from gaps in each.
Physical safeguards sound irrelevant to the cloud until you remember that ePHI still touches physical devices on your end: laptops, workstations, mobile devices accessing cloud-hosted systems. Your cloud provider’s data center has its own physical controls covered under their BAA. Your endpoints are yours. Lost laptop, no remote wipe, no documented device disposal procedure, that is a physical safeguard failure regardless of where the data ultimately lived.
Technical safeguards are where most of the real work happens in a cloud context: encryption at rest and in transit using algorithms aligned with NIST-validated cryptographic standards (still addressable rather than required under the current rule, though that flexibility is on its way out under the proposed Security Rule update), access controls built on least privilege and multi-factor authentication, audit logging across the management plane and the data plane, and integrity controls that flag unauthorized changes before they become a breach you discover three months later in a routine audit. According to NIST Special Publication 800-66, which provides implementation guidance for the HIPAA Security Rule, a risk-based approach means safeguard selection should reflect the specific risks to ePHI, the likely impact of a given incident, and the resources the organization actually has available, not a one-size checklist applied uniformly across every cloud service.
Cloud compliance is one piece of a much bigger picture. If you’re trying to see how it fits alongside everything else your IT environment touches, from help desk to endpoint management to the rest of your compliance stack, Managed IT Services for Healthcare: The Complete Guide is where that full picture lives.
How Responsibility Shifts Across IaaS, PaaS, and SaaS
How those safeguards actually map onto your environment depends on which type of cloud service is holding the data:
Infrastructure as a Service (IaaS): raw virtual machines and storage, AWS EC2, Azure Virtual Machines. You control almost everything above the hardware layer: the operating system, patching, encryption, network configuration, identity management. This gives you the most flexibility and the most ways to misconfigure something. If your EHR database runs on IaaS, your team owns nearly every safeguard category the Security Rule names.
Platform as a Service (PaaS): managed databases, managed Kubernetes, serverless functions. The provider handles the underlying platform security and patching. You are still responsible for how you configure access to that platform, what data goes into it, and whether your application logic leaks ePHI somewhere it should not, in a log file, an error message, a cached query result.
Software as a Service (SaaS): a finished application, a cloud-hosted practice management tool, a billing platform. The vendor controls nearly every security layer underneath the product. Your job shrinks to user access management, your own account hygiene, and confirming the vendor actually signed a BAA rather than just claiming compliance in their marketing copy.
If your organization runs all three, which most do, you do not have one compliance posture. You have three, and each needs its own checklist.
The common failure mode across all of this is not a missing tool. It is a tool that exists, sits unconfigured, and gives you a false sense of coverage. Encryption available is not encryption enabled. Logging available is not logging reviewed. Certifications like HITRUST CSF or SOC 2 Type II, often cited by cloud vendors and MSPs as proof of compliance maturity, describe the strength of a control environment. They do not replace the entity-specific risk analysis and BAA chain HIPAA actually requires.
A Practical Path to Cloud HIPAA Compliance
Here is the order that actually works, based on what audits and post-breach investigations consistently reveal organizations skipped.
Map where your ePHI actually lives. Not where you think it lives. Cloud sprawl means data ends up in backup snapshots, log exports, and SaaS integrations nobody remembers approving. You cannot protect what you have not inventoried.
Not Sure Where Your ePHI Actually Lives Across Your Cloud Environment?
Confirm a BAA exists for every service touching that data. Your primary cloud provider, yes, but also every SaaS tool plugged into your environment, every subcontractor your MSP uses, every analytics or monitoring tool that might capture PHI in a log line. One missing BAA is what cost Oregon Health & Science University $2.7 million. For the full documentation checklist OCR expects to see beyond just the BAA register, the 2026 HIPAA Compliance Checklist covers administrative, physical, and technical safeguards end to end.
Configure access control before you configure anything else. Multi-factor authentication on every account touching ePHI, role-based access tied to actual job function, and a quarterly review process that catches the access nobody remembered to revoke.
Turn on encryption and verify it, do not assume it. At rest and in transit, with documented key management. If you are choosing not to encrypt something, document the compensating control and the reasoning, because addressable means justify it, not skip it.
Build logging into a habit, not a feature. Centralized, immutable, and actually reviewed on a schedule, not just collected and forgotten until an incident forces someone to go looking.
Run the risk analysis annually, and again after any major cloud change. New service, new region, new vendor, new integration. Each one shifts your risk profile, and OCR expects your documentation to reflect that.
Here is the order that actually works, based on what audits and post-breach investigations consistently reveal organizations skipped.
Map where your ePHI actually lives. Not where you think it lives. Cloud sprawl means data ends up in backup snapshots, log exports, and SaaS integrations nobody remembers approving. You cannot protect what you have not inventoried.
Confirm a BAA exists for every service touching that data. Your primary cloud provider, yes, but also every SaaS tool plugged into your environment, every subcontractor your MSP uses, every analytics or monitoring tool that might capture PHI in a log line. One missing BAA is what cost Oregon Health & Science University $2.7 million.
Configure access control before you configure anything else. Multi-factor authentication on every account touching ePHI, role-based access tied to actual job function, and a quarterly review process that catches the access nobody remembered to revoke.
Turn on encryption and verify it, do not assume it. At rest and in transit, with documented key management. If you are choosing not to encrypt something, document the compensating control and the reasoning, because addressable means justify it, not skip it.
Build logging into a habit, not a feature. Centralized, immutable, and actually reviewed on a schedule, not just collected and forgotten until an incident forces someone to go looking.
Run the risk analysis annually, and again after any major cloud change. New service, new region, new vendor, new integration. Each one shifts your risk profile, and OCR expects your documentation to reflect that.
In remediation work after a cloud-related incident, the gap is almost never the technology. It is the documentation. The organization can usually point to a backup system that ran successfully every night for two years. What it usually cannot produce is a record of when that backup was last test-restored, or who reviewed the access logs in the prior twelve months. The systems worked. Nobody could prove it on paper, and on paper is what OCR asks for first. None of this is glamorous. All of it is what separates an organization that survives an OCR investigation from one that becomes the next cited settlement.
The Cloud Did Not Create This Risk, It Just Made It Easier to Outsource Without Noticing
Cloud computing genuinely makes healthcare IT better: better uptime, easier scaling, faster disaster recovery than most organizations could build on-prem. None of that is in question. What is in question is whether the convenience quietly erodes the discipline HIPAA has always required, because the infrastructure is no longer visibly yours.
It still is. The server just moved. And the threats targeting what is now on that server have not slowed down. The cybersecurity threats hitting healthcare organizations hardest in 2026 covers what each attack type costs operationally and which HIPAA provisions it triggers when it succeeds.
Getting HIPAA right in the cloud is not a permanent headache. It is a known, finite list of safeguards and a clear responsibility split, once you have actually mapped both, ideally aligned to recognized frameworks like the NIST Cybersecurity Framework alongside the Security Rule itself. The organizations that get burned are not the ones using AWS, Azure, or Google Cloud. They are the ones who never figured out exactly where their cloud vendor’s job ended and theirs began.
