Hosting protected health information in the cloud is now the default, not the exception. But "HIPAA-compliant hosting" is not something a cloud provider can sell you off the shelf. Compliance is a property of how a system is configured, operated, and documented, not a checkbox a vendor flips on. This guide walks through what actually needs to be in place before you put electronic protected health information (ePHI) on AWS, Azure, Google Cloud, or any other cloud platform, and where the common mistakes happen.
If you are evaluating infrastructure for a telehealth platform, an EHR-adjacent tool, or any application that touches patient data, treat this as a working checklist rather than a legal opinion. Nothing here is legal advice: HIPAA obligations depend on your specific role (covered entity or business associate), your data flows, and your contracts, so confirm specifics with qualified counsel or a compliance advisor.
What "HIPAA-Conscious" Cloud Hosting Actually Means
There is no HIPAA certification for a cloud platform. The Department of Health and Human Services does not certify, approve, or endorse any product, service, or vendor as "HIPAA compliant." What exists instead is a framework of administrative, physical, and technical safeguards under the HIPAA Security Rule, plus a contractual mechanism (the business associate agreement) that extends legal obligations to vendors who handle ePHI on your behalf.
So when a hosting provider advertises "HIPAA-compliant hosting," what they usually mean is narrower and more useful: they will sign a business associate agreement, and their infrastructure includes the controls needed to support your compliance if you configure and use it correctly. The compliance outcome is still yours to build.
The Shared Responsibility Model
Every major cloud provider operates on a shared responsibility model, and it maps directly onto HIPAA obligations.
- The provider is typically responsible for: physical security of data centers, hypervisor and host-level isolation, network infrastructure, and the baseline security of the managed services it offers.
- You are responsible for: which services you use and how you configure them, identity and access management, encryption settings, network segmentation, logging and monitoring, patching of anything you manage (operating systems, containers, application code), and your own organizational policies and workforce training.
A cloud provider signing a business associate agreement does not shift this split. It extends HIPAA's legal obligations to the provider for the portion of the stack it controls, and makes clear that the provider can be held directly liable for its own HIPAA violations. It does not make your misconfigured storage bucket, overly broad IAM role, or missing audit log someone else's problem.
Get the Business Associate Agreement Right Before You Provision Anything
HHS guidance is explicit that when a covered entity or business associate uses a cloud service provider to create, receive, maintain, or transmit ePHI, that cloud provider is itself a business associate under HIPAA, even if it stores only encrypted data and never holds the decryption key. A signed BAA is required before any ePHI touches the platform, not after you discover a gap during an audit.
Two details catch teams off guard:
- Not every service in a cloud catalog is covered. Each major provider publishes a specific list of services included under its BAA. Using a service that is not on that list to process ePHI, even briefly for a quick integration or a prototype, puts you outside the agreement's protection entirely.
- Subprocessors need their own agreements. If your hosting provider relies on a subcontractor that also touches ePHI (a managed logging service, a third-party email provider, a monitoring tool), that subcontractor is a business associate too and needs its own BAA, usually flowed down through your primary vendor.
Practically, this means your infrastructure team and your compliance or legal function need a shared, current list of exactly which services are in scope, cross-checked against the provider's published eligible-services list before every new service gets adopted.
Mapping the Technical Safeguards to Cloud Infrastructure
The HIPAA Security Rule's technical safeguards (45 CFR 164.312) are written in plain, implementation-neutral language, which is exactly why they are easy to under-implement in the cloud. Here is how they translate into actual infrastructure decisions.
Access Control
Every user and service account touching ePHI needs a unique identity, not a shared credential. In cloud terms, this means individual IAM users or federated identities tied to a real person or service, role-based access scoped to least privilege, and an emergency access procedure (a documented "break glass" path) for urgent situations. Shared root accounts, long-lived static credentials, and overly permissive wildcard policies are the most common findings in real-world reviews.
Audit Controls
You need a record of who accessed or attempted to access ePHI, and when. On AWS this typically means CloudTrail plus service-level access logging; on Azure, Activity Log and diagnostic settings; on Google Cloud, Cloud Audit Logs. The logs themselves need protection too: ship them to a separate, access-restricted store so an attacker who compromises an application cannot also erase the evidence. Our audit logging guide for healthcare software covers what a defensible log actually needs to capture.
Integrity Controls
Mechanisms to detect unauthorized alteration of ePHI, such as checksums, versioning on storage buckets, and database-level integrity constraints, protect against both tampering and accidental corruption.
Person or Entity Authentication
Verifying that users are who they claim to be. Multi-factor authentication is not yet a blanket legal mandate under the current rule (more on that below), but it is close to table stakes in practice for anything touching patient data, and it is one of the single most effective controls against credential theft and phishing.
Transmission Security
ePHI moving across a network needs integrity controls and, in practice, encryption in transit. TLS 1.2 or higher for everything, internal service-to-service traffic included, not just the public-facing endpoint, is the realistic baseline. Internal traffic is where many teams quietly skip encryption because "it's inside the VPC."
Encryption: Where Teams Create Unnecessary Risk
Under the Security Rule as currently in force, encryption of ePHI is an "addressable" implementation specification, not a flatly "required" one. Addressable does not mean optional: if encryption is a reasonable and appropriate safeguard for your environment (and for ePHI in the cloud, it almost always is), you either implement it or document a specific, defensible alternative that achieves equivalent protection. In practice, very few organizations have a credible alternative to encryption, so treat it as mandatory in all but name.
The practical baseline most teams should hit:
- Encryption at rest for all storage holding ePHI: managed disks, object storage, databases, and backups, using provider-managed or customer-managed keys depending on your key control requirements.
- Encryption in transit everywhere, including internal service calls and database connections, not only the external TLS termination point.
- Key management with rotation and access logging, rather than static keys baked into configuration files or container images.
Choosing Eligible Services on AWS, Azure, and Google Cloud
Each major provider offers a BAA, but the mechanics differ:
- AWS offers a self-service business associate addendum through AWS Artifact and publishes a list of HIPAA-eligible services covering most core compute, storage, and database services, though not every AWS service is included, and some newer or specialized services may fall outside the current list.
- Microsoft Azure includes HIPAA/HITECH commitments within its Online Services Terms for in-scope customers, with the bulk of core Azure services covered.
- Google Cloud covers all in-scope Google Cloud services under its BAA once accepted through the console, which simplifies the "is this service covered" question somewhat, though configuration responsibility is unchanged.
Whichever platform you choose, the eligible-services list is not static. Re-check it whenever you adopt a new managed service, especially AI, analytics, or integration services that are added to provider catalogs faster than their compliance documentation sometimes catches up.
Network and Operational Considerations
Beyond the Security Rule's specific safeguards, a few architectural decisions consistently separate hosting setups that hold up under scrutiny from ones that do not:
- Network isolation. Keep ePHI-handling workloads in private subnets with no direct public exposure, reaching the internet only through controlled gateways, load balancers, or API layers.
- Backup and disaster recovery. Backups containing ePHI carry the same obligations as production data: encrypted, access-controlled, and covered by the same BAA scope. Test restoration regularly; an untested backup is a liability, not a safeguard.
- Environment separation. Keep production ePHI out of staging and development environments unless those environments carry identical controls. Synthetic or properly de-identified data is almost always the better choice for lower environments.
- Vendor and subprocessor tracking. Maintain a current inventory of every third-party service in the data path, each one mapped to a signed BAA.
What's Changing: The Proposed Security Rule Update
In January 2025, HHS's Office for Civil Rights published a notice of proposed rulemaking that would be the first substantial overhaul of the Security Rule since 2013. As proposed, it would remove the "addressable" category entirely, making virtually all current safeguards strictly required, and would add explicit requirements for encryption of ePHI at rest and in transit, multi-factor authentication, more frequent vulnerability scanning and penetration testing, and tighter incident response timelines, among other changes.
As of this writing, that rule has not been finalized. The comment period closed in March 2025 and the rule remains under review, with federal agencies' own regulatory agenda now pointing to further review well into 2027. Teams building new infrastructure today should treat the proposed direction as a strong signal of where enforcement expectations are heading and build to that bar now, since retrofitting mandatory encryption and MFA into an existing production system is considerably more disruptive than designing for it from the start.
A Practical Pre-Launch Checklist
- Signed BAA in place with the cloud provider before any ePHI is provisioned, not during or after.
- Every service in your architecture cross-checked against the provider's current eligible-services list.
- Unique identities and least-privilege roles for every human and service account; no shared credentials.
- Audit logging enabled across compute, storage, database, and identity layers, shipped to a separate access-restricted store.
- Encryption at rest on every data store, and TLS 1.2+ on every network path, internal traffic included.
- Multi-factor authentication enforced for administrative and application access to ePHI systems.
- Documented, tested backup and disaster recovery procedures covering ePHI specifically.
- Network segmentation keeping ePHI workloads out of public subnets.
- Full subprocessor inventory, each entry mapped to its own BAA.
- Written risk analysis and risk management process covering the cloud environment, updated as the architecture changes.
Sabyrix Technologies designs and builds healthcare and telemedicine software with these controls considered from the architecture stage, not added afterward. If you are planning a new platform or reviewing an existing one, our healthcare software development team can walk through your specific infrastructure and data flows; you can see our broader approach to security and compliance considerations on our Security and HIPAA overview page, or book a strategy call to discuss your project directly.
Frequently Asked Questions
Is AWS, Azure, or Google Cloud "HIPAA compliant" out of the box?
No. None of them can be, because compliance depends on how services are configured and used, not just on the infrastructure itself. Each provider offers a business associate agreement and a defined set of eligible services that can support a compliant architecture, but the configuration, access controls, and organizational processes remain the customer's responsibility.
Do I need a separate BAA for every cloud service I use?
You need the service itself to fall within the scope of your provider's BAA. Most providers cover this through one master agreement that lists which services are included, rather than a separate signature per service, but using a service outside that list to process ePHI is not covered even though the umbrella BAA exists.
Is encryption legally required under HIPAA right now?
Under the current Security Rule, encryption is an "addressable" specification: you must implement it unless you have a documented, reasonable alternative that provides equivalent protection. Given the difficulty of justifying an alternative for ePHI in a cloud environment, treat encryption at rest and in transit as a practical requirement. A pending proposed rule would make it explicitly mandatory with limited exceptions, but that change is not yet final.
Does multi-factor authentication matter if it isn't technically mandatory yet?
Yes. Even where current regulation does not name MFA explicitly, it is one of the most effective controls against the credential-based attacks that drive most healthcare data breaches, and it aligns with where the proposed rule and general security best practice are both heading.
Can a startup building an MVP use standard cloud hosting, or does it need a specialized HIPAA hosting vendor?
Standard major cloud platforms are a reasonable foundation for most healthcare applications, provided the BAA, eligible-services, and configuration requirements above are actually implemented. Specialized "HIPAA hosting" vendors can simplify some of this work, but they do not remove the need for proper configuration, access controls, and documentation on your side.