Key takeaways

  • A cloud provider that stores or processes protected health information for you is a business associate. HIPAA requires a written contract with satisfactory assurances before you share PHI (45 CFR 164.308(b), 164.502(e)).
  • All three providers sign a BAA, but each covers only listed services. Microsoft says a BAA does not by itself ensure compliance, and Google says the customer is solely responsible for its use of the services. AWS says there is no HIPAA certification for a cloud provider.
  • HHS's cloud guidance says a provider that holds only encrypted data and has no key is still a business associate, and encryption alone does not meet the Security Rule.
  • Email is where most practices leak PHI. A BAA covers the mail platform, but you still need MFA, encryption in transit, retention, logging and staff rules for what may be sent.
  • Keep a written risk analysis that names each cloud service, where PHI sits, who can reach it, and how you would get it back.

The short version

Medical practices, billing companies, labs and the vendors that serve them now run on the cloud: email, file sharing, scheduling, imaging, backups. HIPAA does not ban that. It asks for two things. First, a written agreement with every cloud provider that touches protected health information (PHI). Second, your own safeguards on top of the provider's. Most problems we see come from treating the first as if it covered the second.

This article is for practice managers, compliance officers and owners of firms that handle PHI for others. It covers the legal basis, the contract each large provider offers, what the U.S. Department of Health and Human Services (HHS) has said about cloud services, and a practical checklist for Microsoft 365, Google Workspace and Amazon Web Services. It is general information, not legal advice.

Why a cloud provider is a business associate

HIPAA calls a person or company that handles PHI on behalf of a covered entity (a health care provider, health plan or clearinghouse) a business associate. The Security Rule says a covered entity may let a business associate create, receive, maintain or transmit electronic PHI only after it obtains satisfactory assurances that the associate will protect the information, and that those assurances must be written in a contract. The Privacy Rule says the same. A business associate that hires its own subcontractor must obtain the same kind of assurances. The relevant text is 45 CFR 164.308(b) and 164.502(e).

Microsoft puts it plainly on its compliance page: when a covered entity engages a cloud service provider such as Microsoft, the provider is a business associate, and when a business associate uses a cloud provider the cloud provider also becomes one. AWS says the same about itself. In HHS's cloud computing guidance, issued by its Office for Civil Rights in October 2016, the rule is explicit: a cloud provider that creates, receives, maintains or transmits electronic PHI for a covered entity or business associate is a business associate, even if it stores only encrypted data and has no key.

What HHS says about cloud computing

The official HHS page was not reachable from our research tools when we prepared this article. We therefore relied on a law-firm summary of the guidance (see sources) and on the regulation text. Confirm the points below on hhs.gov before you rely on them. The guidance, as summarized, makes these points.

  • No-view services are still covered. OCR uses the term for a provider that stores encrypted data it cannot decrypt. Lacking a key does not exempt the provider from business associate status, and such providers cannot claim the conduit exception, which applies to carriers that only transmit data.
  • Encryption is not enough. It reduces the chance that someone views data, but it does not protect against malware or guarantee availability in an emergency, so the full Security Rule applies.
  • A BAA is required, and the service level agreement helps. The SLA can define each side's duties. You still must understand what the provider does with the data to complete your own risk analysis.
  • Responsibilities can be shared. If you authenticate users and the provider relies on that, one action can satisfy a requirement for both. The provider remains responsible for controls such as limiting its administrators' access.
  • Breach notification applies. Cloud providers must document security incidents and follow the business associate breach rules.
  • Location and mobile access are allowed with care. Servers outside the United States are permitted, though the guidance says to weigh the extra risk. Access from phones and tablets is allowed with appropriate safeguards.
  • HIPAA does not require a provider to hand over security documentation or let you audit it, so ask for audit reports as a matter of diligence and write down what you received.
  • Availability matters. The Security Rule requires PHI to remain available during emergencies and disasters.

Microsoft 365

Microsoft says it enters into BAAs with covered entity and business associate customers. The agreement is available through the Microsoft Online Services Data Protection Addendum by default for customers that are covered entities or business associates, and the signed text is available on the Service Trust Portal. The BAA covers listed services only. For Office 365 in the commercial cloud, Microsoft lists, among others, Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, Microsoft Entra ID and the Microsoft Purview portal. Check the current list on Microsoft Learn before you put PHI into any other service or a consumer product.

Microsoft also states three limits that matter. Having a BAA does not ensure compliance, because your organization is responsible for its own compliance program and for how it uses the services. There is no HHS-approved certification a business associate can hold. And Microsoft cannot use a customer's own BAA form, because its services are standardized for all customers.

In practice, a compliant Microsoft 365 tenant for a practice usually includes: MFA for everyone, conditional access that blocks legacy sign-in, mailbox auditing turned on, sensitivity labels and data loss prevention rules for PHI patterns, retention settings that match your records policy, restricted external sharing in SharePoint and OneDrive, and managed devices. Those settings are your side of the shared responsibility.

Google Workspace

Google offers a HIPAA Business Associate Addendum that a customer accepts online. It applies only to the "Covered Services" listed in an attachment, and Google may update that list with notice but may remove a service only on at least 12 months' notice. The BAA does not apply to other Google products, or to PHI held outside the covered services, such as offline storage or third-party apps connected to the account.

The addendum puts duties on both sides. Google must report security incidents and breaches it discovers to the customer, and breach notice is due no later than 60 calendar days after discovery. It must bind subcontractors that handle PHI to the same protections, and it remains responsible for them. When the services end, it returns or destroys the PHI. The customer must use the available controls to keep PHI within the covered services, and is solely responsible for ensuring that its and its users' use of the services complies with HIPAA. Google's HIPAA Implementation Guide is described as informational only, and Google does not guarantee compliance through it.

For a practice on Google Workspace, that means accepting the BAA before PHI enters the account, turning on 2‑Step Verification, limiting which add-ons and third-party apps may connect, controlling external sharing in Drive, and using Vault retention to match your records policy.

Amazon Web Services

AWS has a standard Business Associate Addendum that a customer can review, accept and manage in AWS Artifact. AWS says that customers may use any service in an account designated as a HIPAA account, but should only process, store and transmit PHI in services that AWS lists as HIPAA eligible. The addendum is built around the AWS shared responsibility model, in which AWS secures the infrastructure and the customer secures what it builds on top. AWS also states that there is no HIPAA certification for a cloud service provider; it aligns its risk management program with FedRAMP and NIST SP 800-53.

Because AWS is a toolbox, most of the compliance work is yours. A sound design uses a dedicated account for PHI, encryption at rest and in transit with customer-managed keys, private networking, logging that cannot be altered by the workload's administrators, narrow identity and access policies, and tested backups in a second region or account. The BAA does not configure any of this for you.

Each large cloud has its own key, secret and audit services, and a design for PHI uses them. On Amazon Web Services (AWS): AWS Key Management Service (AWS KMS) for encryption keys, AWS CloudHSM for single-tenant hardware security modules, AWS Secrets Manager for credentials and AWS CloudTrail for a record of account activity. On Google Cloud: Cloud Key Management Service (Cloud KMS), Cloud HSM, Secret Manager and Cloud Audit Logs. On Microsoft Azure: Azure Key Vault, Azure Key Vault Managed HSM and the activity log in Azure Monitor. On Oracle Cloud Infrastructure (OCI): Oracle Cloud Infrastructure Vault (OCI Vault) for keys, with secrets handled by Oracle's separate Secret Management service, and the OCI Audit service. A BAA covers only the services it lists, so check that each of these is on the list before PHI touches it.

HIPAA-compliant email

Email is the most common route by which PHI leaves a practice. A BAA with Microsoft or Google makes the platform eligible to carry PHI, but several decisions remain yours.

  • Platform and plan. Use a business plan that is covered by the BAA, not a free or consumer account.
  • Sign-in. Turn on MFA, ideally phishing-resistant, for every mailbox and every administrator.
  • Transport and message protection. Require TLS between servers and use message encryption for external recipients who cannot receive mail over TLS. Decide in writing which kinds of PHI may go by email at all.
  • Authentication of your domain. Publish SPF, DKIM and DMARC so that criminals cannot send mail that looks like yours. See our article on email authentication and resilient Exchange.
  • Devices. Require a screen lock, device encryption and the ability to wipe a lost phone.
  • Retention and logging. Keep audit logs of mailbox access, set retention to match your policy, and know how to produce a mailbox on request.
  • People. Train staff on misdirected mail, phishing and the minimum necessary rule, and set out what to do when a message goes to the wrong person.

The risk analysis ties it together

The Security Rule requires an accurate and thorough assessment of the risks to the confidentiality, integrity and availability of the electronic PHI you hold (45 CFR 164.308(a)(1)(ii)(A)). A cloud service belongs in that analysis like any other system. For each service, record what PHI it holds, who at the provider and in your office can reach it, how it is encrypted, how it is backed up, how you would leave the service, and which BAA covers it. Our article on the HIPAA Security Rule explains how this assessment fits into the larger compliance program, including the proposed update to the rule.

A checklist before you move PHI to a cloud service

  • Is there a signed BAA, and does it list the specific service you plan to use?
  • Is PHI limited to covered or HIPAA-eligible services only?
  • Do you have the provider's audit reports on file, and who reviewed them?
  • Are MFA, logging, encryption, sharing limits and retention configured and documented?
  • Is the service in your risk analysis, and is the analysis dated this year?
  • Can you export your data, and have you tested a restore from an independent backup?
  • Do your own subcontractors, such as an IT provider or billing vendor, have BAAs with you?

How Clayton Cybernetics can help

Our team designs and operates secure environments for organizations that handle regulated data, including healthcare. We configure Microsoft 365, Google Workspace and cloud platforms to the safeguards above, set up email authentication and encryption, document the shared-responsibility split, and help you prepare the written risk analysis and the BAA paperwork you will need to show a regulator, a payer or a client. Contact us at (305) 404-9404 to review your current setup.

Sources

This article is general information, not legal advice. BAA terms and covered-service lists change; confirm them with each provider and your counsel before you place PHI in a service. The HHS cloud computing page itself could not be opened for this review, so its points are taken from a law-firm summary of the guidance. Last reviewed .

Keep reading

Need help with this?

One view of your entire cybersecurity program, in near real time.

Clayton Secure