What Is HIPAA-Compliant Hosting?

HIPAA-compliant hosting is infrastructure for storing, processing, and transmitting electronic protected health information (ePHI) that meets the HIPAA Security Rule’s administrative, physical, and technical safeguards. When an outside provider hosts ePHI on your behalf, it must also sign a Business Associate Agreement (BAA). No host is compliant on its own label: compliance depends on how the environment is configured and what runs on it.

In simple terms, HIPAA-compliant hosting keeps patient data secure, controls who can access it, records access, and enables recovery if something goes wrong. When an outside provider hosts the data, a BAA sets out its responsibilities for protecting it.

At QuickBlox, we host the chat, video, files, and AI conversations that healthcare apps run on in our HIPAA cloud, in a customer’s own cloud account, or on-premises. What we see most often is that teams secure their main database well, then leave PHI unprotected in the places they didn’t think of as data: attachments, recordings, logs, and backups. This page is written with those gaps in mind.

What Makes Hosting HIPAA-Compliant?

Hosting is compliant when the environment meets the safeguards of the HIPAA Security Rule and, where an outside provider hosts ePHI, that provider signs a BAA. The rule groups those safeguards into administrative, physical, and technical controls, covered in full in What Is HIPAA Compliance?. For hosting, they translate into six areas of control. The table shows common hosting controls; the specific technologies and backup arrangements depend on your risk analysis, architecture, and contracts.

Safeguard	Typical implementation	Where it’s often missed
Encryption	ePHI encrypted at rest and in transit (TLS)	Backups, file storage, and logs left unencrypted
Access control	Unique user IDs, role-based access, MFA, automatic log-off	Shared admin accounts, support staff with standing access
Audit controls	Logs of who accessed or changed ePHI, and when	Application-level access is not logged, only server events
Integrity	Protection against improper change or deletion	Changes to records or files that go undetected
Backup and recovery	Regular backups, copies kept apart from production, a tested recovery plan	Backups exposed to the same outage, deletion, or compromised credentials as production; restores never tested
Physical and network security	Secured data centers, firewalls, intrusion detection	Assumed, never verified with the provider’s audit reports

One point is widely misstated. Under the current Security Rule, encryption is addressable: implement it when reasonable and appropriate; otherwise, document why and implement an equivalent alternative if one is reasonable. For hosted ePHI, encryption at rest and in transit is the expected answer in practice, and HHS has proposed making it required.

For an overview of the technical controls used to protect ePHI, see What Are HIPAA Technical Safeguards?.

Where PHI Lives in a Healthcare App

Hosting has to protect every copy of PHI, not just the primary database. In the healthcare apps we host, PHI routinely turns up in places teams don’t list in their risk assessment:

Chat messages and attachments: lab results, photos, and insurance cards shared in conversation.
Call recordings: stored video or audio from consultations.
Logs: application and server logs that capture message content or patient identifiers.
Backups and disaster-recovery copies: full copies of ePHI, often in another region.
Push notifications: message previews sent through Apple or Google notification services.
AI processing: transcripts and prompts sent to AI services for documentation or triage.
Monitoring and analytics tools: error trackers and dashboards that record request data.

Each of these needs the same safeguards as the database, and third-party services that handle PHI on your behalf, as business associates or subcontractors, need appropriate BAA coverage. The useful question isn’t “is our database encrypted?” but “where else does patient data end up?” Mapping that path is the first step in choosing hosting.

HIPAA-Eligible vs HIPAA-Compliant: What’s the Difference?

A HIPAA-eligible service is one a provider will cover under its BAA; a HIPAA-compliant deployment is one configured and operated to meet the Security Rule. AWS, Microsoft Azure and Google Cloud each publish lists of services covered by their BAA. Using a service on that list makes compliance possible. It doesn’t make your deployment compliant.

There is also no official HIPAA certification for hosting. HHS doesn’t certify or endorse cloud providers. Independent audits such as SOC 2 Type 2, HITRUST or ISO 27001 show that a provider’s controls have been tested, which is useful evidence, but none of them is a HIPAA certificate.

Why Your Hosting Provider Is a Business Associate

A hosting provider that creates, receives, maintains, or transmits ePHI for a covered entity or another business associate is itself a business associate and must sign a Business Associate Agreement. HHS guidance on cloud computing is explicit on two points that often surprise teams:

Encryption doesn’t remove the obligation. A cloud provider that stores encrypted ePHI is still a business associate, even if it doesn’t hold the decryption key.
The conduit exception is narrow. It covers services that only transmit data with transient storage, such as an internet service provider. A host that stores ePHI, even temporarily beyond transit, doesn’t qualify.

The BAA sets out how the host may use PHI, its safeguard duties, and its breach-reporting obligations. Alongside it, the service agreement should cover system availability, backup and recovery, where data is stored, and how data is returned or destroyed when the contract ends.

Who Is Responsible for What

Hosting compliance is shared: the host secures the infrastructure, and you secure what you build and run on it. Where the line falls depends on the hosting model and your agreement, and HHS recommends documenting that split. The table shows the typical split on managed hosting; on self-managed cloud infrastructure, more responsibility for operating systems, applications, access controls, and backups moves to your team.

Area	Host (typical, managed hosting)	You
Data center and network security	Yes	Verify through audit reports
Operating system and platform patching	Yes, as agreed	Anything you deploy and run yourself
Encryption at rest and in transit	Provides and enables it, as agreed	Confirms it covers every PHI store, including files and backups
User access and permissions	Secures admin access to infrastructure	Manages app users, roles and access reviews
Audit logging	Logs infrastructure activity	Logs and reviews who accessed patient data in your app
Backup and recovery	Runs backups, as agreed	Sets recovery targets and tests restores
Risk assessment and policies	Its own	Yours, covering the whole PHI path
BAAs	Signs yours; holds BAAs with its subcontractors	Signs with your own customers and the vendors that handle PHI for you

The split is also why a compliant host doesn’t make a compliant product. For the full picture of what a platform needs, see What Makes a Telehealth Platform HIPAA-Compliant?

HIPAA Cloud Hosting on AWS, Azure, and Google Cloud

All three major clouds can support HIPAA-compliant cloud hosting. Each signs a BAA and publishes the services it covers, but each leaves the configuration to you:

AWS: the BAA is accepted through AWS Artifact and applies only to HIPAA Eligible Services.
Microsoft Azure: the BAA is included in Microsoft’s product terms for in-scope services.
Google Cloud: the BAA covers a published list of products. It can be accepted in the console, and some customer agreements already include it; either way, confirm it’s in place before using covered products with PHI.

The common failure is using a service outside the covered list, such as a logging, messaging, or AI service added later, without checking whether the BAA extends to it.

Hosting Models at a Glance

Where your environment runs changes how much of the work is yours.

Model	Isolation	Who operates it
Shared HIPAA cloud	Customers share infrastructure; data and access are kept separate	The vendor
Dedicated cloud	Resources reserved for one customer	The vendor, on the terms you agree
Your own cloud account	An account your organization holds	The vendor or your team
On-premises	Servers you own, in your own facility	Your team

Any of these can meet HIPAA’s safeguards. The differences are isolation, who does the operational work, and what your contracts commit each party to. On-premises gives the most control and carries the most responsibility.

Common Misconceptions About HIPAA Hosting

“Our cloud provider is HIPAA compliant, so our app is.” The provider makes services eligible and signs a BAA. Configuration, access control, and everything in your application remain yours.

“Our BAA covers every service we use.” A cloud BAA covers only the services on its eligible list. The service added for search, logging, or AI six months after launch is the one most likely to fall outside it.

“On-premises is automatically more compliant than cloud.” Compliance comes from safeguards and how they are run, not location. On-premises moves the whole workload, from patching to backups, onto your team.

“PHI is only in the database.” It is in attachments, recordings, logs, backups, and notifications too.

How to Evaluate a HIPAA Host

Ask these questions before you sign:

Will you sign a BAA, and which services does it cover?
Where is data stored, including backups and disaster-recovery copies?
Is encryption on by default at rest and in transit, and who manages the keys?
What do your audit logs capture, and how long are they kept?
How often are restores tested, and what are your recovery time and recovery point targets?
Who patches what?
Which subcontractors handle ePHI, and do they have BAAs with you?
Which independent audit reports can you share?
What happens to our data when the contract ends?

Red flags: a provider describing itself as “HIPAA certified”, reluctance to sign a BAA before you commit, or vague answers on backups and logging. When you’re ready to compare options, see our HIPAA-compliant hosting.

The QuickBlox Perspective

QuickBlox hosts the communication layer of healthcare apps: chat, video calling, file sharing, and AI agents. That puts us where the forgotten copies of PHI tend to live. Messages can carry attachments, and consultations may generate recordings or transcripts. Each of those PHI stores needs its own access controls, retention, and recovery arrangements.

So we treat the whole path as in scope. Encryption at rest and in transit, role-based access, two-factor authentication, and automatic log-off are built into our HIPAA deployments and cover the messages and files themselves, not just the server they sit on. Log monitoring, intrusion detection, and malware scanning are available as additional security integrations. We sign a BAA covering the chat, video, AI, and hosting infrastructure we run for you.

Teams choose where that runs: our HIPAA cloud, their own AWS, Azure, or Google Cloud account, or on-premises. If you’re mapping where PHI goes in your app, we’re happy to walk through it with you or see the options for HIPAA-compliant hosting.

Sources

Common Questions About HIPAA-Compliant Hosting

What is healthcare hosting?

Healthcare hosting is server or cloud infrastructure for applications that handle patient data, such as telehealth platforms, patient portals, and electronic health records. In the US, it usually means hosting that meets HIPAA's safeguards and comes with a signed BAA.

Does a hosting provider need to sign a BAA if the data is encrypted?

Yes. HHS guidance says a provider that stores encrypted ePHI is still a business associate, even if it can't decrypt the data. Encryption reduces risk and affects breach notification, but it doesn't replace the BAA.

Can PHI be hosted on shared cloud infrastructure?

Yes, if the provider signs a BAA and the environment isolates each customer's data and access. Shared, dedicated, and on-premises hosting can all be compliant. The difference is how much isolation and control you get and how much of the work falls on your team.

How long do HIPAA audit logs need to be kept?

HIPAA requires security policies and related documentation to be kept for six years, but that doesn't set a blanket retention period for every audit log. Set and document log retention based on your risk analysis, any other requirements that apply, and your contracts, including your agreement with the host.

Can push notifications contain PHI?

They shouldn't. Notifications travel through Apple's and Google's push services and can appear on a locked screen, and standard push delivery shouldn't be assumed to be covered by a BAA. The safe pattern is a notification that only says a new message is waiting.

Does every healthcare app need HIPAA-compliant hosting?

Only apps that handle PHI on behalf of a covered entity or business associate fall under HIPAA. A consumer wellness app with no provider or health-plan relationship may not, though it can still fall under the FTC's Health Breach Notification Rule and state privacy laws.

Communication Tools

Ready Solutions

DEV DOCUMENTATION

DEV RESOURCES

Infrastructure