If you're storing or processing electronic protected health information (ePHI), your practical options are the major hyperscalers, Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure, plus enterprise file platforms like Box and Dropbox Business. None of them are "HIPAA certified" out of the box, because that certification doesn't exist. What makes any of these providers usable for ePHI is a signed Business Associate Agreement (BAA) and your own discipline in sticking to the vendor's HIPAA-eligible services list.
Do these two things before anything else:
- Execute a BAA with your chosen provider and confirm which specific services fall under it.
- Restrict all ePHI workloads to services on the vendor's official HIPAA-eligible allowlist. A service left off that list, even from the same vendor, is not covered.
Pro Tip: Print or save the vendor's eligible-services page and date it. Vendors update these lists, and your compliance posture needs a timestamped record of what was covered when you configured the workload.
Here's the catch healthcare IT teams underestimate: a signed BAA and a SOC 2 report tell you the vendor built a secure platform. They say nothing about whether your team configured encryption, locked down access, or turned on audit logging correctly. That gap, not the vendor's infrastructure, is where most HIPAA violations involving cloud services actually happen.
Table of Contents
- Which Cloud Providers Are HIPAA Compliant Cloud Providers?
- How Do You Choose a HIPAA Compliant Cloud Provider?
- What Security Controls Does HIPAA Require in the Cloud?
- Securing Bioinformatics Workloads in the Cloud
- Where to Verify HIPAA Cloud Guidance
- Why Most HIPAA Cloud Advice Misses the Real Risk
- A Different Kind of Partner for Regulated Data Work
- Sources
- FAQ
Which Cloud Providers Are HIPAA Compliant Cloud Providers?
No cloud provider is "HIPAA compliant" as a blanket label. What you're actually evaluating is whether a provider will sign a BAA, which of its services fall under that BAA, and whether its technical controls let you meet the HIPAA Security Rule. Nineteen or so vendors show up regularly in healthcare IT procurement conversations. Some are full infrastructure platforms; others are narrower file-storage or backup tools that slot into a broader architecture.
Amazon Web Services (AWS) is the default choice for organizations running large-scale compute or storage workloads involving PHI. AWS signs BAAs with covered entities and business associates and maintains an extensive list of HIPAA-eligible services, from EC2 and S3 to more specialized analytics and machine learning tools. Its compliance tooling, including AWS Artifact for on-demand access to audit reports, is mature enough that most large health systems already run some workloads there. The tradeoff is scale: AWS's service catalog is so broad that keeping a current internal record of which services your team actually uses under the BAA takes real governance discipline.
Google Cloud Platform (GCP) stands out for a reason healthcare IT teams specifically care about: Assured Workloads, a control layer built to isolate regulated workloads with defined data residency and access boundaries. GCP publishes detailed HIPAA compliance documentation and a specific list of services in scope, and it offers a BAA to any customer who requests one. For healthcare analytics or research workloads where you need a demonstrable data boundary, GCP's tooling maps more directly onto that requirement than most competitors.
Microsoft Azure wins on integration for organizations already standardized on Microsoft. Azure's HIPAA BAA is built into its Product Terms, and it documents exactly which services are in scope. Azure Policy regulatory compliance initiatives let administrators map controls directly to HIPAA and HITRUST requirements inside the same dashboard they already use for Microsoft 365 and Active Directory governance. That policy-driven approach is genuinely useful for enterprises trying to enforce configuration standards across dozens of departments without manual audits.
Box (Box for Healthcare) targets a narrower problem: secure document storage and collaboration. If your PHI exposure is mostly clinical documents, imaging reports, and files shared between care teams rather than large compute pipelines, Box's healthcare-specific tier offers a BAA and controls purpose-built for that use case, including granular sharing permissions and retention policies.
Dropbox Business covers similar ground with a lighter footprint. Teams that need straightforward file sync and sharing, without the complexity of a full enterprise content platform, can get a BAA and admin controls sufficient for basic PHI file storage, provided the account is configured correctly and business tier controls are actually turned on.
Beyond these five, a wider set of tools show up in healthcare cloud storage and backup conversations: Microsoft OneDrive and Google Drive for everyday file storage under their parent platforms' BAAs; Carbonite, Backblaze, and IDrive for backup-focused storage; Sync and Egnyte as enterprise file-sync alternatives with compliance-oriented tiers; and backup and data-management platforms like Veeam, Rubrik, Cohesity, Druva, HYCU, and Eon for organizations managing backup and disaster recovery across hybrid or multi-cloud environments. Each of these can be part of a HIPAA-compliant architecture, but the same rule applies across the board: confirm a BAA is available for the specific plan you're buying, and verify which features that BAA actually covers before you route any ePHI through it.
To actually initiate a BAA, go directly to the vendor's trust or compliance portal rather than a sales rep's word. AWS handles this through AWS Artifact, GCP and Azure through their respective compliance documentation pages linked above, and Box and Dropbox through their enterprise/healthcare sales channels. In every case, ask for the current HIPAA-eligible services list in writing, not a verbal assurance that "everything is covered."
How Do You Choose a HIPAA Compliant Cloud Provider?
Selecting a provider isn't about picking the biggest name. It's about matching a provider's controls, documentation, and contract terms to your specific ePHI workload and risk tolerance. Work through these criteria in order, because each one gates the next.
- Confirm BAA availability for your exact plan tier. Some vendors sign BAAs only for enterprise or business tiers, not free or entry-level plans. Ask explicitly whether the tier you're buying is covered.
- Request the HIPAA-eligible services allowlist. HHS guidance is direct on this point: services outside that list generally aren't authorized for ePHI under the BAA, even from the same vendor.
- Verify key management options. Ask whether the provider supports customer-managed encryption keys (CMEK) or bring-your-own-key (BYOK). This matters more for research and genomic data than most teams initially assume, since it determines who can technically access decrypted data.
- Check audit logging depth and retention. Confirm the provider logs access at the object or record level, not just account-level activity, and that logs retain long enough to satisfy your incident response and breach investigation timelines.
- Pin down breach notification timing. Insist the BAA specifies a concrete notification window, ideally 30 days or sooner, rather than vague "prompt notification" language.
- Ask for subprocessor disclosure. Any vendor using downstream subcontractors that touch ePHI needs to disclose them, and your BAA needs audit rights over that chain.
- Request current attestation reports. SOC 2 Type II, ISO 27001, and HITRUST reports show independent verification of the vendor's internal controls. Ask for the most recent report, not a marketing summary of one.
When you call or email a vendor's compliance team, use direct language: "Can you provide your current HIPAA-eligible services list and your standard BAA template for review?" A vendor that hedges, delays, or can't produce a BAA template within a few business days is a red flag for a clinical or research workload handling real patient data.
Pro Tip: Build a shared-responsibility matrix before you sign anything. List every control the vendor's BAA and attestations claim to cover on one side, and every control your team must configure on the other. That document becomes your evidence file for audits and vendor due diligence.
Minimum acceptance criteria for clinical workloads should include a signed BAA, a documented eligible-services list, encryption at rest and in transit as standard, and at least one current third-party attestation report. If a provider can't produce all four, treat that as a stop condition, not a negotiation point.
What Security Controls Does HIPAA Require in the Cloud?
A BAA gets you legal cover. It does not configure a single setting. The shared responsibility model puts infrastructure security on the vendor and configuration security on you, and misconfiguration on the customer side is the most common source of cloud-related HIPAA gaps.
Four control areas need direct attention:
- Encryption: Use customer-managed keys (CMEK) or bring-your-own-key (BYOK) wherever the provider supports it, combined with envelope encryption for data at rest and TLS 1.2 or higher for everything in transit.
- Identity and access: Enforce multi-factor authentication (MFA) on every account with ePHI access, apply least-privilege roles rather than broad admin grants, and use dedicated service accounts per application rather than shared credentials.
- Logging and monitoring: Feed access logs into a SIEM or centralized monitoring tool, set retention long enough to support investigations, and alert on anomalous access patterns, like a service account suddenly pulling records outside its normal pattern.
- Backups and breach coordination: Use immutable or append-only backup storage where available to protect against ransomware, and confirm your BAA specifies exactly how the vendor will coordinate with you if it detects a breach on its side.
One detail HHS guidance flags that surprises a lot of IT teams: encryption alone doesn't remove a vendor's business associate status. Even if a cloud provider never holds the decryption key, the act of storing or transmitting encrypted ePHI can still make it a business associate requiring a BAA. Don't assume encryption is a workaround for skipping that contract.
Securing Bioinformatics Workloads in the Cloud
Genomic and computational biology pipelines raise the stakes on data residency and provenance in ways a standard EHR system doesn't. A single sequencing run or protein modeling job can touch terabytes of data across dozens of ephemeral compute instances, and every one of those instances needs the same access controls as your primary database.
Innovabiotech's approach to this, detailed in its Security and Confidentiality policy, treats data residency and key management as design decisions made before a pipeline runs, not settings adjusted afterward. In practice, that looks like:
- Isolated project environments modeled on Assured Workloads style segmentation, keeping regulated data boundaries explicit rather than assumed.
- Dedicated encryption keys per project rather than shared organizational keys, so a compromise in one workload doesn't expose others.
- Ephemeral compute paired with encrypted scratch storage, so temporary processing environments don't become long-lived, unaudited copies of sensitive data.
- Service accounts scoped per pipeline, which keeps audit logs readable instead of a tangle of shared credentials.
Compute-heavy computational biology work multiplies your attack surface with every parallel job you spin up. Strict service account separation and encrypted scratch storage aren't extra steps. They're what keeps an audit log meaningful once you're running hundreds of ephemeral instances at once.
Compliance discipline in HIPAA compliant cloud providers only takes you so far if your pipeline architecture ignores the same principles. Teams handling large biological datasets can review methods for large-scale dataset analysis for storage patterns that align with these residency and provenance requirements.
Compliance depends on picking providers that publish clear HIPAA-eligible service lists and configuring every workload inside those boundaries, not on any vendor's marketing claims.
| Point | Details |
|---|---|
| No shortcut on the BAA | A signed Business Associate Agreement is mandatory before any ePHI touches a cloud provider. |
| Stick to the allowlist | Only use services on the vendor's published HIPAA-eligible services list, even within the same account. |
| Configuration is your job | The shared responsibility model puts encryption, access control, and logging setup on your team, not the vendor. |
| Demand real documentation | Request current SOC 2, ISO 27001, or HITRUST reports and a written breach notification timeline before signing. |
| Bioinformatics needs extra isolation | Innovabiotech applies dedicated keys and ephemeral, scoped compute environments for computational biology workloads. |
Where to Verify HIPAA Cloud Guidance
Check these sources directly rather than relying on vendor sales pages alone:
- HHS guidance on HIPAA and cloud computing, the federal source for allowlist and BAA requirements.
- Google Cloud's HIPAA compliance documentation and Microsoft Azure's HIPAA offering page for current eligible-services lists.
- Sentrix's healthcare GRC resources for governance and risk management frameworks that extend beyond individual vendor documentation.
Why Most HIPAA Cloud Advice Misses the Real Risk
The conventional advice on this topic stops at "pick a provider that offers a BAA," as if the contract were the finish line. It isn't. The BAA gets you a vendor willing to accept liability for its side of the arrangement. It says nothing about whether your engineering team left a storage bucket public, skipped MFA on a service account, or routed data through a service that quietly fell outside the eligible list six months after you signed.
What gets underestimated is how much HIPAA compliance in the cloud is actually a documentation and discipline problem, not a vendor selection problem. AWS, GCP, and Azure all offer mature enough tooling that a competent team can build a defensible architecture on any of them. The organizations that get burned are the ones that treat the signed BAA as the compliance program instead of the starting point for one.
If there's one place to spend disproportionate attention, it's key management and workload isolation, especially for research and computational workloads that generate more ephemeral compute and more data movement than a typical clinical system. That's where audit trails get messy fastest, and where a clean architecture up front saves you from an unreadable mess of logs later.
— Hooman
A Different Kind of Partner for Regulated Data Work
Choosing between AWS, GCP, Azure, and enterprise file platforms solves your infrastructure problem. It doesn't solve the problem of who's actually running the computational biology or protein modeling work on top of that infrastructure. Innovabiotech isn't a cloud provider competing with the names in this guide. It's the team that designs and executes the bioinformatics pipeline that sits inside your compliant cloud architecture, with the same security discipline this article just walked through already built into how projects run.
That distinction matters if you're a research team trying to hire both cloud expertise and computational biology expertise separately. Innovabiotech's protein design and computational modeling services and peptide design services run on dedicated project environments with the encryption and access-control practices described above, so you get a partner who already treats data isolation as a default, not an afterthought you have to specify in a statement of work. If your next project involves hit-to-lead optimization, enzyme engineering, or de novo peptide design that touches sensitive data, start with a project consultation to scope the security requirements alongside the science.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
FAQ
Which Cloud Storage Providers Are HIPAA Compliant?
No provider is "HIPAA compliant" by default. AWS, Google Cloud Platform, Microsoft Azure, Box, and Dropbox Business will all sign a BAA and support HIPAA workloads when configured correctly and limited to their published eligible-services lists.
Who Are the Big Cloud Providers?
The three dominant hyperscalers are Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Enterprise file platforms like Box and Dropbox Business round out the practical options for healthcare organizations with lighter infrastructure needs.
Is Google Cloud HIPAA Compliant?
Google Cloud offers a signed BAA and a published list of HIPAA-eligible services, plus Assured Workloads for isolating regulated data. Whether your specific use is compliant depends on staying within that eligible-services list and configuring access controls correctly.
Can iCloud Be HIPAA Compliant?
Apple does not publish a standard BAA for iCloud aimed at covered entities and business associates, which makes it unsuitable for storing ePHI in most healthcare organizations. Stick to providers that explicitly offer a BAA and a documented eligible-services list, like AWS, GCP, or Azure.
Does Signing a BAA Make a Cloud Provider Fully Compliant?
No. A BAA establishes the vendor's legal obligations, but your organization is still responsible for configuring encryption, access controls, and logging correctly under the shared responsibility model.