When a healthcare organization migrates workloads to cloud infrastructure, the existing Business Associate Agreement structure doesn't transfer. The BAA you signed with your on-premises hosting provider doesn't extend to AWS. The BAA you have with your EHR vendor doesn't cover the cloud infrastructure their SaaS runs on. The data flows change, the data processors change, and the legal obligations must be rebuilt from scratch.
This is not a legal department problem — it's an engineering problem. The reason OCR audits consistently find BAA gaps in post-migration healthcare systems is that the technical decisions that determine which parties need BAAs are made by engineers in the first weeks of a migration project, before anyone has thought to involve legal.
What Creates a BAA Obligation
A Business Associate is any entity that performs functions or activities on behalf of a Covered Entity that involve the use or disclosure of PHI, or provides certain services to a Covered Entity where the provision of the service involves access to PHI. The key phrase: "on behalf of." A cloud provider running your workloads that has access to PHI — even encrypted PHI — is a Business Associate. Your analytics platform that processes de-identified data is not, if the de-identification satisfies the Safe Harbor or Expert Determination method under 45 CFR §164.514.
AWS, Azure, and GCP all offer BAAs for their HIPAA-eligible services. HIPAA-eligible does not mean HIPAA-compliant — it means the provider is willing to sign a BAA and has implemented controls appropriate to support HIPAA compliance on your part. The compliance obligation remains with you.
AWS's HIPAA-eligible services list covers roughly 150 services. Services not on the list — including many AI/ML services, some analytics services, and some developer tools — cannot be used to process PHI under a BAA with AWS. If your migration plan involves these services touching PHI, you either need an architectural change or an alternative provider that offers BAA coverage.
The Sub-Processor Chain
Cloud-native architectures routinely involve sub-processors: the cloud provider's managed database service, a third-party monitoring tool deployed via the marketplace, a CI/CD platform with deployment access to production systems. Each entity in this chain that has access to PHI — even incidentally — requires a BAA. The mapping exercise for a moderately complex cloud-native healthcare application typically reveals 8-15 entities requiring BAAs.
Encryption and the "Holds" Problem
A common misconception: if PHI is encrypted at rest and in transit, the cloud provider doesn't need a BAA because they can't read it. This is wrong. OCR has consistently held that encryption does not eliminate the Business Associate relationship — it only satisfies certain Security Rule requirements. The BAA obligation arises from access to PHI, not the ability to read it.
The exception is customer-managed encryption keys (CMEK) with key custody architectures where the provider has no key access. AWS's CloudHSM and Azure's Managed HSM configurations, implemented correctly, can reduce or eliminate the BAA requirement for specific data flows. This is a niche architecture with significant operational complexity — and it requires legal review of whether the specific configuration satisfies OCR guidance.
The Migration Architecture Checklist
- Map every data flow involving PHI before writing infrastructure code — not after
- For each service in the data flow, check the provider's HIPAA-eligible services list
- For services not on the HIPAA-eligible list that will access PHI, find alternatives or redesign the data flow
- Execute BAAs with all cloud providers before any PHI is migrated
- Review sub-processor chains — SaaS tools deployed to your cloud environment may have their own sub-processors
- Update your risk analysis under 45 CFR §164.308(a)(1) to reflect the new architecture
- Test audit logging continuity — the cloud migration must not create gaps in your PHI access audit trail
The most common post-migration BAA gap we see is not with the primary cloud provider — it's with third-party monitoring, logging, and observability tools. If your APM tool, log aggregation service, or error tracking platform processes application logs that contain PHI, it needs a BAA. Most do not offer one.
Working with Your Legal Team
The BAA review for a cloud migration requires legal and engineering to work together on the data flow map. The legal team can't identify what needs BAAs without understanding what data flows where. The engineering team can't make the right architectural decisions without understanding which data flows create BAA obligations. This is why cloud migrations break BAA structures — the two teams work in sequence rather than in parallel. Our healthcare technology practice structures the BAA mapping exercise as a joint exercise from the first week of a migration project.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.