HIPAA Compliant Hosting: Provider vs Customer Responsibility

There is no such thing as a HIPAA-certified hosting provider.

HHS does not certify hosting, cloud platforms, or software for HIPAA compliance, and no recognised body issues a HIPAA certification that transfers compliance to a customer. When a provider says it is “HIPAA compliant hosting,” what it can actually mean is that it helps its customers meet their HIPAA obligations, it will sign a Business Associate Agreement, and it manages its own portion of the environment to the required standard.

That distinction is the whole article. Compliance is shared, and most of it stays with you.

Who HIPAA actually applies to

Two categories of organisation carry HIPAA obligations directly.

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who conduct certain transactions electronically. Hospitals, clinics, insurers and practices.

Business associates are organisations that create, receive, maintain or transmit protected health information on behalf of a covered entity. Billing companies, EHR vendors, analytics platforms, and, importantly for this article, infrastructure providers storing electronic PHI.

Since the HITECH Act and the Omnibus Rule, business associates are directly liable for complying with the Security Rule. Subcontractors of business associates are covered too, which means the obligation flows down the whole supply chain.

Why your hosting provider is a business associate

This point trips up a lot of organisations, so it is worth being precise.

HHS guidance on cloud computing states that a cloud service provider that creates, receives, maintains or transmits ePHI on behalf of a covered entity or business associate is itself a business associate. That holds even if the provider only stores encrypted data and does not hold the decryption key.

In other words, "we encrypt it, so our provider cannot see it" does not remove the need for a Business Associate Agreement. If the provider stores ePHI, a BAA is required.

Covered entities can be penalised for not having a BAA in place, or for having an incomplete one, even when no other violation has occurred. The missing contract is itself the finding.

What the BAA is and is not

A Business Associate Agreement sets out the permitted uses and disclosures of PHI by the business associate, how the business associate supports individuals' rights under the Privacy Rule, breach notification obligations, and both parties' responsibilities for safeguarding the data.

What it is not is a transfer of your compliance to the provider. Signing a BAA with your host means your host has taken on obligations for the part it controls. It does not mean your application, your access controls, or your staff practices are now compliant.

A provider that will not sign a BAA cannot be used to store ePHI. That is the first filter, and it is binary.

The responsibility split

The Security Rule organises its requirements into administrative, physical and technical safeguards. Where each falls depends on the service model. For infrastructure where the provider runs hardware and platform and you run everything on top, the split generally looks like this.

Typically the provider's responsibility

• Physical security of the data centre: access control, surveillance, environmental controls
• Hardware lifecycle, including secure disposal of storage media
• The hypervisor and platform layer, including patching
• Network infrastructure up to the boundary of your environment
• The provider's own workforce training, access policies and incident response
• Signing and honouring the BAA

Typically your responsibility

• Your risk analysis, which the Security Rule requires and which nobody else can do for you
• Guest operating systems, including patching
• Applications and databases
• Access control and identity: who can reach ePHI, with what authentication
• Encryption configuration for data at rest and in transit
• Audit logging of access to ePHI, and actually reviewing it
• Backup configuration and tested recovery
• Your own workforce training, policies and sanctions
• Breach notification to affected individuals and HHS

Shared, and where misunderstandings happen

• Encryption, where the provider may supply the capability and you must enable and manage it
• Logging, where the provider logs its layer and you log yours
• Incident response, where both parties have obligations and the BAA should define how they connect
• Network security, where the provider secures the infrastructure and you configure your own firewalls and segmentation

The shared category is where most real-world failures sit. Each party assumes the other has it covered. We wrote about this pattern more broadly in the shared responsibility model nobody reads.

What the proposed Security Rule update would change

This needs stating carefully, because many articles describe it as though it is already law.

HHS published a Notice of Proposed Rulemaking to update the HIPAA Security Rule in the Federal Register on 6 January 2025. The comment period closed on 7 March 2025. As of mid-2026, it remains a proposed rule. A final rule was expected in spring 2026 and that date slipped; the federal regulatory agenda now targets July 2027 for final action, and those timelines are not binding.

If finalised in its proposed form, it would make several significant changes:

• Encryption of ePHI at rest and in transit would become required rather than addressable, with limited exceptions
• Multi-factor authentication would be required for systems accessing ePHI
• Network segmentation would become an explicit requirement
• Regular technical testing, including penetration testing and vulnerability scanning, would be mandated at set intervals
• Covered entities would need written verification, at least annually, that their business associates have implemented required technical safeguards

That last point changes the provider relationship considerably. Under the proposed rule, a signed BAA alone would no longer be sufficient evidence. Covered entities would need their providers to demonstrate controls on a recurring basis.

HHS estimated first-year compliance costs across regulated entities at roughly $9 billion. Once a final rule publishes, the proposal allows around 240 days to comply in total.

The practical advice from most compliance advisors is to prepare against the proposed requirements now, particularly encryption and MFA, since both are sound practice regardless of the rule's final form.

What to ask a hosting provider

Will you sign a BAA? If the answer is no or hesitant, stop.

What does your BAA actually commit you to? Read it rather than confirming it exists. Breach notification timelines and subcontractor terms matter.

Which safeguards do you own, specifically? Ask for this in writing, mapped to the Security Rule's administrative, physical and technical categories.

What independent attestations can you provide? SOC 2 Type II reports and similar evidence are not HIPAA certifications, but they are the sort of documentation that supports your risk analysis and would support the annual verification the proposed rule describes.

Is the hardware dedicated or shared? Multi-tenant infrastructure can support HIPAA workloads. Dedicated infrastructure simplifies the evidence, since the answer to who else was on this hardware becomes nobody.

Where is the data physically stored, and where are backups kept? We covered why these can differ in data residency: where your data actually lives.

How does incident response connect between us? Who notifies whom, how fast, and through which channel.

The mistakes that actually cause findings

Treating the BAA as the compliance programme. It is a contract that defines one relationship. Your risk analysis, policies and technical controls are still yours.

Assuming encryption is on because the provider supports it. Supporting a capability and having it enabled are different states.

Logging without reviewing. Audit logs that nobody looks at satisfy nothing and help with nothing during an investigation.

Untested backups. A backup that has never been restored is an assumption rather than a control.

Forgetting non-production environments. Test and staging environments populated with real patient data carry the same obligations as production, and they are routinely less protected.

Frequently asked questions

Is there such a thing as HIPAA certified hosting? No. HHS does not certify hosting providers or technology for HIPAA compliance. Providers can support compliance, sign a BAA, and provide third-party attestations, but compliance remains the responsibility of each regulated entity.

Does a hosting provider need to sign a BAA if the data is encrypted? Yes. HHS guidance treats a cloud provider that stores ePHI as a business associate even when it holds only encrypted data without the key.

What is the difference between a covered entity and a business associate? Covered entities are health plans, clearinghouses and providers conducting certain electronic transactions. Business associates handle PHI on behalf of covered entities. Both carry direct Security Rule obligations.

Is the 2026 HIPAA Security Rule in effect? No. It was proposed in January 2025 and, as of mid-2026, has not been finalised. The federal regulatory agenda targets July 2027 for final action, and that date is not binding.

Does using a HIPAA compliant host make my application compliant? No. The provider covers its layer. Your application, access controls, encryption configuration, logging and policies remain your responsibility.

Can multi-tenant cloud be used for HIPAA workloads? Yes, with a BAA and appropriate controls. Dedicated infrastructure is not required, though it simplifies some of the evidence an auditor may ask for.