Healthcare Cloud Migration: 8 Compliance Pitfalls to Avoid

Healthcare cloud migrations are not a technical problem. The technical lift is usually straightforward. What makes them hard is HIPAA — specifically, the gap between "we're using a HIPAA-eligible service" and "we have actually configured it in a HIPAA-compliant way." Those are very different things, and auditors know it.

Here are the eight pitfalls we see most often, in rough order of how expensive they are when they go wrong.

1. Treating a BAA as a Checkbox

A Business Associate Agreement is necessary but not sufficient. Microsoft, AWS, and Google will all sign BAAs, but the BAA only covers services that are on the covered-services list for that vendor. Enable a service that isn't covered — say, a preview feature or a region outside the BAA scope — and any PHI that touches it creates a reportable breach.

What we do: Maintain a written inventory of every service touching PHI, map each one to the vendor's covered-services list, and re-check the list quarterly. Vendors add and remove services from BAA coverage more often than you'd think.

2. Encryption Keys in the Wrong Place

AES-256 at rest is table stakes. The harder question is who holds the keys. If your cloud vendor manages the keys, you are trusting them not to be compelled to hand your data over. If you manage the keys in the same cloud, you've reduced but not eliminated the risk.

For high-sensitivity workloads — behavioral health, substance abuse records under 42 CFR Part 2, genomics — we recommend Customer-Managed Keys (CMK) with a separate key management account, ideally backed by an HSM. Azure Key Vault Premium, AWS CloudHSM, and Google Cloud HSM all support FIPS 140-2 Level 3 hardware modules.

3. Audit Logs That Don't Prove Anything

HIPAA's audit control requirement (45 CFR 164.312(b)) is vague enough that every auditor interprets it differently. The common failure mode: logs exist, but they don't capture who accessed which patient record. CloudTrail and Azure Activity Log capture API calls, not row-level database access.

What we recommend: Enable database-level audit logging (SQL Server Audit, PostgreSQL pgAudit, or equivalent), ship logs to immutable storage (S3 Object Lock, Azure Blob immutable tier), retain for six years minimum, and test your ability to reconstruct "who accessed Jane Doe's chart on March 12" before an auditor asks.

4. Backups That Are Also Encrypted by Ransomware

If your backup destination can be written to by the same credentials that operate production, ransomware will encrypt your backups too. We've seen it happen to healthcare customers more than once. They had "backups." The backups were unusable.

Immutable object storage (S3 Object Lock in Compliance mode, Azure Blob immutable policies) is the answer. The backup job writes the object, sets the retention lock, and the object cannot be deleted or modified for the retention period — not by an attacker, not by the storage admin, not by support. Test restores monthly, not annually.

5. Over-Permissioned Service Accounts

The default IAM role that your backup software or integration engine asks for is usually far too broad. "Give the service admin on the storage account" is the fastest way to a breach. Every non-human identity should be scoped to the minimum set of actions and the minimum set of resources, and every permission should be reviewed quarterly.

Specifically for healthcare: scope database access by patient cohort where possible, and never use the same credential for the application and the reporting layer.

6. PHI in Non-Production Environments

The dev and QA databases are almost always a disaster. Production data gets copied in for testing, email addresses are real, names are real, sometimes SSNs are real, and access controls are much looser than production. This is a HIPAA violation waiting to be discovered.

Fix: Use deterministic data masking — tools like Delphix, Tonic.ai, or a scripted masking stage in your CI pipeline. Real names become fake names, but the same real name always becomes the same fake name, so referential integrity survives. Run the mask before data leaves production, not after.

7. Vendor Sub-Processors You Haven't Mapped

Your EHR cloud vendor uses a cloud hoster. The cloud hoster uses a backup vendor. The backup vendor uses a colocation provider. Every link in that chain needs a BAA, and every link is a potential audit finding. Most healthcare IT leaders have never traced the chain beyond their direct vendor.

Ask for a sub-processor list from every BA, read it, and flag anyone who isn't willing to provide one.

8. Assuming "The Cloud Is HIPAA Compliant"

There is no such thing as a HIPAA-compliant cloud. There are HIPAA-eligible services, and there are HIPAA-compliant configurations that use them. Your auditor cares about the second. "We're on Azure" is not an answer. "We're on Azure, in the US commercial region, with these services from the HIPAA covered-services list, with these specific controls enforced by Azure Policy, with these logs shipped to Sentinel, with these CMK-backed keys, and with these quarterly access reviews" is an answer.

What We'd Actually Do

For a mid-sized healthcare organization (50 to 500 providers), here's the pattern we recommend:

• Landing zone first. Deploy a dedicated subscription or organization structure for PHI workloads. Don't mix regulated and non-regulated workloads in the same account.
• Policy as code. Azure Policy or AWS Config rules that deny non-compliant resources — unencrypted storage, public endpoints on databases, missing tags. This is what turns compliance from a quarterly fire drill into a continuous process.
• Immutable backup target. Separate cloud account, immutable object storage, separate credentials, tested restores monthly.
• Centralized logging. Sentinel, Chronicle, or a third-party SIEM. Six years of retention for anything touching PHI. Alert on known bad patterns (mass exports, off-hours access, geographic anomalies).
• Annual tabletop exercise. Walk through a simulated breach. Who calls OCR? When? Who drafts the notification? You do not want to answer these questions in the middle of an actual breach.

Three Takeaways

1. HIPAA compliance is a configuration story, not a vendor story. Signing a BAA is the beginning, not the end.
2. Your backups are the control that matters most during a ransomware event. Make them immutable, separate, and tested.
3. Sub-processors and non-production environments are where the real risk hides. Most audits find problems in the places the IT team hadn't thought about.