HIPAA in the cloud
Moving patient data to the cloud splits the work, not the duty
A cloud platform takes over the buildings, the hardware and the layers beneath your account. The Security Rule still applies to everything you build on top. This page sets out how the split works in any cloud, what the agreement must settle, and the decisions on region, keys, logs, backups and exit that stay yours.
Back to HIPAA services01 · Why the host is a BA
Holding the data is enough to make the host a business associate
Reading it is not the test. Maintaining it is.
HIPAA defines a business associate by what a vendor does with protected health information for you, and the verbs are broad: it creates, receives, maintains or transmits it. A cloud provider that keeps your electronic PHI (ePHI) on its disks is maintaining it, whether or not it can decrypt a single byte.
HHS guidance on cloud computing addresses the case where the customer encrypts the data and holds the only key. The provider is still a business associate and still needs a Business Associate Agreement (BAA). Encryption lowers the risk. It does not change the provider's role.
- Covered entity
- A health plan, a clearinghouse, or a provider that bills electronically. Your customer, if you sell software to clinics.
- Business associate
- You, when you handle PHI for a covered entity. The cloud host, when it holds PHI for you.
- Subcontractor
- A business associate of a business associate. The rules follow the data down the chain.
- Conduit
- A carrier that only passes data through with transient storage. A host that keeps data does not fit this narrow exception.
02 · Who owns what
Who owns which safeguard
The provider runs the platform. You run your use of it.
| Safeguard area | The provider | You |
|---|---|---|
| Facilities and hardware | Data-centre access, power, disposal of failed disks | Nothing to run, but read the provider's reports on them |
| Agreement | Offers its standard BAA and names the services it covers | Accepts it before ePHI arrives and keeps ePHI inside its scope |
| Identity and access | Secures its own staff access to the platform | Every user, role, key and token in your account, with MFA for people |
| Network | Isolation between customers | What is public, what is private, and every open port |
| Encryption | Offers encryption features and default settings | Turns them on where needed and decides who holds the keys |
| Logging | Produces platform logs you can switch on | Switches them on, protects them and reviews them |
| Backups and recovery | Durable storage and snapshot tools | Backup scope, restore tests and the contingency plan |
| Risk analysis | Assesses its own platform | Assesses your system, including how you configured the cloud |
Where a row says the provider offers a feature, the safeguard only exists once you use it. Most cloud findings sit in the right-hand column.
03 · The agreement
Reading a cloud provider's BAA
Large providers offer standard terms. Read them; do not assume them.
Hyperscale providers rarely sign a customer's own BAA. They offer one agreement for everyone, accepted in a console or folded into the main contract. That makes reading it more important, because you adapt to it rather than the other way round.
- Which services it covers. The BAA applies to a named set of services. Anything outside that set must not hold ePHI.
- How incidents reach you. The Security Rule expects a business associate to report security incidents. See what the provider will report, and how.
- Its own subcontractors. The provider must bind its subcontractors to the same protections.
- Return or destruction. At the end of the contract PHI must be returned or destroyed where feasible. Know how the provider does this.
- Fit with the service terms. The service-level and deletion terms should not contradict the BAA.
No one certifies the cloud for HIPAA
HHS does not certify or endorse cloud providers, and there is no official HIPAA certificate for a platform or for a company. A provider's audit reports help your risk analysis. They do not make your account compliant.
04 · Region and access
Where the data lives and who can reach it
HIPAA does not ban offshore storage. It asks you to weigh the risk.
The rules do not require ePHI to stay in the United States. HHS guidance does expect the risk analysis to consider where data is stored and who can reach it from where. Many US customers write a region limit into their own contracts, so check yours before choosing a region.
- Pick the regions that may hold ePHI, and block the rest at the account or organisation level.
- Give engineers working access without standing access to production data. Grant data access just in time, and log it.
- Treat the cloud console's root or owner account as a sealed emergency key, with hardware MFA and no daily use.
- Keep a list of every place ePHI is copied: replicas, exports, analytics stores, support tickets.
05 · Keys to exit
Keys, logs, backups and the day you leave
Four decisions that outlast the migration.
Provider-managed keys
The platform creates, stores and rotates the keys. Simple and usually on by default.
- Protects against stolen disks
- Little to administer
- The provider's staff and your admins share the trust
Customer-managed keys
You create the key in a key service and control who may use it.
- Separate key admins from data admins
- Revoking the key cuts off the data
- More work: rotation, access, recovery
Encryption is an addressable specification under the Security Rule, so you decide and document. Data encrypted to the standard HHS describes, with the key kept safe, can fall outside the breach-notification duty.
Record and review
The Security Rule requires audit controls that record and examine activity in systems holding ePHI.
- What happens
- Turn on control-plane and data-access logs
- Ship them to a store your admins cannot edit
- You get
- A trail of who touched what
- Good practice
- A named reviewer and a set rhythm
- Watch for
- ePHI written into application logs
Restore, not just copy
The contingency plan needs a data backup plan and a way to restore.
- What happens
- Back up every ePHI store
- Run a timed restore test
- You get
- Evidence that recovery works
- Good practice
- Backups in a separate account or project
- Watch for
- Snapshots anyone in the account can share
Leave cleanly
When a workload or a provider is retired, PHI must be returned or destroyed.
- What happens
- Inventory every copy
- Delete, or destroy the key
- Keep a record of what was removed
- You get
- A closed account with nothing left behind
- Good practice
- Exit steps written before go-live
- Watch for
- Closing the account and hoping
06 · Mistakes
Mistakes we see in cloud HIPAA programmes
Each one is a process gap, not a missing product.
- Accepting the BAA after the migration. Test data turned out to be real data, and it arrived first.
- Borrowing the provider's audit report. The provider's SOC 2 or ISO report covers its side. Your side needs your own evidence.
- Seeding test environments from production. A copy of live records in a test account carries every duty the original does.
- Forgetting the second vendor. Monitoring, email and error-tracking tools that receive ePHI need their own BAAs.
- One person holds data and keys. If the same admin can read the data and manage the key, the key adds little.
- No exit record. Without proof of deletion you cannot show what happened to PHI when a service ended.
The provider-specific pages go further: the agreement and account set-up on AWS, identity and Microsoft 365 on Azure, and data perimeters on Google Cloud.
Sources: 45 CFR 160.103 (definitions of business associate and subcontractor); 45 CFR 164.308, 164.312, 164.314 and 164.316 (Security Rule); 45 CFR 164.402 and 164.504(e) (breach definitions and business associate contracts); HHS Office for Civil Rights, Guidance on HIPAA and Cloud Computing; HHS guidance on rendering PHI unusable, unreadable or indecipherable.
Questions about HIPAA in the cloud
Is a provider's HIPAA-eligible service already compliant?
No. Eligible means it may hold ePHI under the agreement.
Eligible or covered means the service sits inside the provider's BAA. Whether your use of it meets the Security Rule depends on how you set it up and run it.
Can our ePHI be stored outside the United States?
HIPAA does not forbid it, but your risk analysis and contracts may.
The rules contain no data-location requirement. HHS expects you to consider location in the risk analysis, and many customer contracts add a US-only clause. Check both before you choose a region.
Do we need to run our own risk analysis if the provider has audits?
Yes. The analysis covers your system, not the platform.
The Security Rule requires an accurate and thorough risk analysis of the ePHI you hold. Provider reports are inputs to it. Your configuration, staff, code and vendors are the rest.
What happens to PHI when we close a cloud account?
You must be able to show it was returned or destroyed.
Business associate contracts require return or destruction of PHI at termination where feasible. Plan the exit: list every copy, delete it or destroy the key, and keep the record.
Find the gaps in your side of the cloud.
A HIPAA risk assessment reviews how your cloud accounts are set up against the Security Rule. Counsel should confirm how the provider's agreement applies to your contracts.