Audit logging operates differently than access control. HIPAA’s audit control standard requires organizations to record and examine activity in systems containing ePHI. This is partly a detection mechanism and partly a legal and forensic one: when a breach occurs or is suspected, logs are how you reconstruct what happened, when, and to what data. Telehealth platforms that generate video session metadata, access records, and system events need those logs retained and reviewable in a compliant environment, not on infrastructure where the logging scope or retention period is undefined.
The shared-responsibility model that underlies most cloud offerings means the provider manages the physical layer and the hypervisor; the customer manages everything else. Firewall configuration, encryption implementation, access controls, logging setup, monitoring, all of it falls to the customer. For a development team that understands those requirements in detail, the model is workable, though still incomplete without a BAA. For many telehealth operators, it represents a compliance gap that can grow wider over time as the platform scales and control surface expands.
What HIPAA Hosting Actually Means
The definition of HIPAA hosting is more constrained than most practitioners assume. It is an environment built to satisfy HIPAA’s administrative, physical, and technical safeguard requirements, paired with a signed legal agreement that makes the hosting provider a Business Associate. Both elements must be present. Either alone is insufficient.
This is worth stating plainly because the market creates genuine confusion. A well-hardened server with no Business Associate Agreement (BAA) in place is not HIPAA hosting. Conversely, a platform that produces a BAA but deploys no meaningful controls around access or encryption is equally non-compliant. The BAA creates a legal obligation: the provider commits to handling ePHI according to HIPAA’s requirements and to notifying the covered entity of breaches. Without that agreement, the legal foundation does not exist, regardless of how robust the technical stack looks on paper.
Some providers make the distinction explicit in their own catalogues. A general cloud plan and a HIPAA offering may sit side by side, with only the latter carrying the BAA and the audited environment. That is not a marketing artifact. It reflects the architectural reality that HIPAA compliance requires a different build, not simply a different tier of the same build.
The Standard Cloud Problem
Not every telehealth operator is building from scratch. When a provider uses a third-party telehealth platform that itself holds ePHI on its own infrastructure and provides the BAA, the vendor assumes the Business Associate role for that hosted data. The compliance obligations for data the vendor controls belong to the vendor under the terms of the BAA.
Availability rounds out the technical picture. HIPAA requires that ePHI remain accessible and that covered entities can restore access following an incident. For a telehealth platform, this is not abstract. A system that loses data or cannot recover from a failure event has a compliance problem, not just an operational one.
A standard cloud plan from a major provider is often not HIPAA hosting. That sentence deserves no softening. Such plans typically include no BAA, no managed security controls, and no audited compliance environment. The infrastructure may be physically secure, geographically redundant, and performant. None of that on its own makes it HIPAA-compliant.
The Technical Controls Telehealth Actually Requires
This arrangement reduces the hosting question’s complexity considerably, the platform vendor has already made the infrastructure decisions, but it does not eliminate it. Covered entities still need to verify the BAA’s scope, understand what ePHI the vendor touches versus what remains on the provider’s own systems, and confirm that the integration boundaries between the vendor environment and any internal systems do not create an unmanaged exposure.
That qualifier matters because managed HIPAA hosting is sometimes positioned as compliance-in-a-box. It is not. What it does is remove the implementation burden for the foundational layer, reducing the likelihood that a control is misconfigured or omitted under deadline pressure. The legal and administrative work, internal risk assessments, workforce training, policies and procedures, still belongs to the covered entity.
The core requirements do not change based on who satisfies them. AES-256 at rest, TLS in transit, MFA, role-based access, audit logging, breach notification, and recovery capability are required regardless of which party’s infrastructure they run on. What the managed hosting or platform model determines is where the implementation accountability sits.
Start with what telehealth actually does. Unlike a billing platform or a records database, a telehealth system stores and transmits electronic protected health information in real time, as an encrypted video stream. That changes the compliance calculus. Most HIPAA workloads are static: patient records, lab results, billing files sitting in a database, protected by encryption at rest, access controls, and backup integrity checks. Those controls are well understood and well supported across many hosting environments. Telehealth adds a dynamic layer, low-latency secure streaming, that belongs inside the compliance perimeter, not outside it. A provider that treats its video infrastructure as a simple delivery mechanism and its database as the actual compliance concern has misread the regulation’s scope.
Where Managed HIPAA Hosting Changes the Equation
The contrast between managed HIPAA hosting and standard infrastructure is not a matter of degree, it is a matter of what responsibility is actually transferred. Managed HIPAA hosting provides the BAA plus a pre-configured layer covering firewall, encryption, MFA, logging, and backups, exactly the controls a telehealth workload requires. The provider has configured and audited these controls before the customer’s workload arrives. Their validation is operationally meaningful, but covered entities remain responsible for their own HIPAA compliance posture and cannot fully outsource that obligation to any vendor.
Multi-factor authentication addresses a specific and persistent threat: credential theft. It is among the most common entry points for breaches affecting healthcare environments. MFA at the platform level does not eliminate credential risk entirely, but it raises the cost of exploitation meaningfully. Pairing MFA with role-based access controls further limits blast radius if a single account is compromised, only the data and systems that role can legitimately access are within reach.
HIPAA compliance in the context of telehealth is not a storage problem. It is a streaming problem, a legal accountability problem, and a shared-responsibility problem, and these three pressures intersect in ways that standard cloud infrastructure is not built to address.
When the Third-Party Platform Model Applies Instead
By Randy Ferguson
A common baseline for telehealth is AES-256 encryption at rest combined with TLS encryption in transit. Both matter because ePHI is vulnerable in two states: stored and moving. A video session places ePHI in motion continuously for as long as the session runs. Encryption in transit under TLS is not optional or aspirational; it is the minimum.
Walk into any mid-sized telehealth operation and you will find teams that understand the technical controls well but have never reviewed whether their hosting contract includes a BAA, or whether the BAA they have covers the specific workloads now running in that environment.
Telehealth infrastructure decisions made under time pressure and with incomplete understanding of BAA scope are where much hosting-related HIPAA exposure originates. The technical controls are well understood; the legal accountability structure is where the ambiguity persists, and where careful review before deployment pays its highest return.
For teams building custom telehealth applications, hosting ePHI in their own infrastructure, or integrating clinical video into a platform they control, the hosting decision is directly a compliance decision. There is no intermediate abstraction. The environment runs ePHI, the provider must be a Business Associate, and the technical controls must be in place before the first patient session. Getting that sequence reversed, standing up the platform, then addressing compliance, is an exposure pattern that appears regularly in breach post-mortems.
