A cloud provider that stores only encrypted patient data, and holds no key to read it, is still a HIPAA business associate. That one point from federal guidance shapes every healthcare cloud migration, because it means the contract and the shared security duties get settled before a single record moves.
This guide covers what the move gives you, where it goes wrong in practice, and the order to do the work in.
Why healthcare cloud migration starts with a business associate agreement
Covered entities and business associates can use a cloud service provider to store or process electronic protected health information, but only under a HIPAA-compliant business associate agreement (BAA). That's the rule in the HHS Office for Civil Rights guidance of October 2016, as Hunton Andrews Kurth summarised it.
The agreement has to set out permitted uses and disclosures, require safeguards that implement the Security Rule, and require the provider to report security incidents it learns of. How detailed and how frequent those reports are is left to the two parties to agree.
Encryption doesn't get a provider out of this. Per Bricker Graydon's reading of the same guidance, a provider holding only encrypted data, with no decryption key of its own, is still a business associate, and its service level agreements must be consistent with the BAA and the HIPAA rules.
Practically, that moves a question onto your procurement checklist that many teams leave until late: will the vendor sign a BAA at all, and for which of its services?
What do you actually gain by moving to the cloud?
You hand off the security of the physical infrastructure and gain resilience options that are expensive to build yourself. AWS puts it as a split: it operates and controls security of the cloud, while customers handle security in the cloud.
In its October 2025 post on HIPAA compliance on AWS, the company also points to multi-AZ and multi-Region options for backup and resiliency, and notes that customers can inherit its control certifications through the HITRUST shared responsibility matrix. They still carry their own third-party attestation.
For healthcare cloud migration, that's a vendor describing its own platform, so weigh it as a description of what's available, not a promise of what you'll get. The gains are real, but every one of them is conditional on configuration you do yourself.
We'd also be cautious about the cost savings you'll see in vendor brochures. The sources we read didn't give a figure we could stand behind, and the number depends heavily on what you run and how much of it you rebuild.
Where the risks actually sit
Most healthcare cloud migration risk sits in your own configuration, not in the provider's data centre. AWS states it plainly: customers "do not automatically inherit HIPAA compliance by using HIPAA eligible services." Eligibility says a service can be used with patient data. It doesn't say your setup is compliant.
The cost of getting that wrong can run for years. HIPAA Journal reported in February 2023 that a misconfigured cloud storage environment at mobile pharmacy provider mscripts had been publicly accessible since September 2016, according to a third-party forensic investigation. The files exposed data on 66,372 patients, including images of prescription bottles and insurance cards.
Shared duties get split in ways teams don't expect
In what OCR calls no-view services, where only the customer controls who can see the data, the customer may be the one responsible for access controls such as authentication and unique user identification. The provider may cover encryption. One party's actions can satisfy a requirement for both, which is helpful, and also means nobody owns a gap unless you write down who does.
Your own risk analysis can't be outsourced
OCR expects customers to understand the provider's environment well enough to run their own risk analysis and set their own risk management policies. Storing data on servers outside the US is allowed, but the guidance asks you to weigh the risks of the country where the servers sit.
Not every service in the account is cleared for patient data
With AWS, you may process, store or transmit patient data only with HIPAA-eligible services, even if other services are available in the same account. Small details matter: AWS says resource tags must not hold patient data, for example.
Best practices, in the order to do them
Photo by erwinbosman on Pixabay
Work from contract to controls to the applications that sit on top. Skipping ahead in a healthcare cloud migration to the build is the usual way a migration ends up redone.
- Get the BAA signed and read which services it covers before choosing an architecture.
- Run your own risk analysis against the provider's environment, including where data will physically live.
- Write down who owns each security control, using the provider's shared responsibility documentation as the starting point.
- Configure the controls, test them, and only then move real records.
What the configuration work includes
The AWS post lists what customers have to set up. Networking comes first: private and public subnets, security groups and encrypted connections back to on-premises systems. Access follows, with least-privilege roles and multi-factor authentication.
Encryption is needed at rest and in transit, with keys managed deliberately. Logging deserves more care than it gets, because log data can leak patient information too; AWS advises keeping it out of monitoring data and scanning for it. Backups need a plan, not a default.
Plan for mobile and for the apps on top
Clinicians and patients will reach cloud-hosted records from phones. OCR allows that where physical, administrative and technical safeguards are in place and BAAs cover any third party with access.
The same applies to the products your patients touch. Octopi designed and built OptimalMD's website, members portal and mobile app, and each of those front ends depends on whatever infrastructure sits beneath it. If you're building or rebuilding that layer, our apps and SaaS work is where that happens.
Hosting choices also decide how portable the whole thing is later, which our guide to HIPAA-compliant cloud hosting options compares in more detail.
Don't forget what a move does to your website and integrations
Moving hosting changes URLs, redirects and response times, and a careless cutover can cost you search visibility. We cover that in healthcare website migration SEO.
On the data side, records have to keep flowing to the systems that already exist. The HL7 and FHIR integration guide explains how those connections are usually built, and it's worth reading before you decide what moves first.
Our view on sequencing a healthcare cloud migration: move the least clinically critical workload first, check that the controls and the monitoring behave, and move on from there. Nothing in the sources we read tells you how long that takes, and anyone quoting a fixed timeline without seeing your systems is guessing.
Frequently asked questions
Does encrypting the data mean the cloud provider doesn't need a BAA?
No. OCR's guidance treats a provider as a business associate even when it stores only encrypted data and lacks the key.
Can patient data be stored on servers outside the US?
The guidance allows it. It also asks you to include the risks of the server's country in your own risk analysis.
If a provider has HIPAA-eligible services, are we compliant?
No. AWS says customers don't automatically inherit compliance by using eligible services. You still configure the controls yourself.
Can staff reach cloud-stored records from mobile devices?
Yes, with appropriate physical, administrative and technical safeguards, and with BAAs covering any third parties that have access.
Cover photo by Antoni Shkraba on Pexels
Sources
- HHS Releases Guidance on HIPAA and Cloud Computing — Hunton Andrews Kurth
- OCR releases HIPAA guidance on cloud computing services — Bricker Graydon
