Picture a small but growing telehealth startup—call it Acme Health, Inc. Acme writes none of its own infrastructure. Its application runs on a public cloud, its patient records sit in a managed database, its appointment reminders flow through a third-party messaging service, its support tickets live in a SaaS help desk, and its analytics team pipes anonymized-ish usage data into an off-the-shelf dashboard. On the day Acme signs its first hospital client, its founders ask a question that sounds simple and is not: which of these vendors are subject to HIPAA, and what do we have to make them sign?

The honest answer surprises almost everyone the first time they hear it. Under the modern interpretation of the Health Insurance Portability and Accountability Act of 1996—HIPAA—nearly every one of those cloud vendors is a business associate, legally bound by federal health-privacy and security law, directly liable to the government for violations, and required to sign a particular kind of contract before a single byte of patient data may flow to them. The vendor that merely stores encrypted files it cannot read is a business associate. The vendor that never once "looks at" the data is a business associate. The reseller's subcontractor three layers down the stack is a business associate. The comfortable intuition—"we just hold the data, we don't use it, so we're more like the post office"—was specifically and deliberately killed by the U.S. Department of Health and Human Services in 2016.

This guide explains how we got here and what it means in practice. We will define the key players in plain language, trace the rise and fall of the famous "conduit exception," dissect the business associate agreement that 45 C.F.R. 164.504(e) requires, walk through the Privacy, Security, and Breach Notification Rules as they land on a cloud arrangement, explain the encryption-based breach "safe harbor" that every general counsel should understand, and map the shared-responsibility model that decides who pays when there is a breach. We will look hard at enforcement—the Office for Civil Rights audits, the tiered penalties, the multimillion-dollar resolution agreements—and at the sweeping 2024–2025 proposal to overhaul the HIPAA Security Rule, which, if finalized, would change cloud compliance more than anything since 2013. Finally, we will tackle the frontier problem everyone is wrestling with right now: what happens when protected health information is fed into artificial intelligence and analytics systems. Throughout, the goal is the same—give a hospital administrator, a SaaS founder, a privacy lawyer, and a curious patient one map they can all read.

The Cast of Characters: Covered Entities, Business Associates, and Subcontractors

HIPAA is not, despite popular belief, a general medical-privacy law that binds everyone who ever sees your chart. It is a law that binds two categories of organizations, plus the people they hire. Understanding the categories is the whole ballgame, because they determine who must comply and who must sign what.

A covered entity is the front line. The HIPAA Rules define three kinds: health plans (insurers, HMOs, employer group health plans, government programs like Medicare and Medicaid), health care clearinghouses (the back-office processors that translate claims data between formats), and health care providers who transmit health information electronically in connection with certain standard transactions—essentially, any doctor, hospital, pharmacy, lab, or clinic that bills electronically. See 45 C.F.R. 160.103. If you are a hospital or a health insurer, you are a covered entity, full stop.

A business associate is anyone outside the covered entity's own workforce who creates, receives, maintains, or transmits protected health information (PHI) to perform a function or service for, or on behalf of, that covered entity. The statutory and regulatory hook is the Health Information Technology for Economic and Clinical Health Act of 2009 (the HITECH Act) and the implementing definition at 45 C.F.R. 160.103. The classic examples are billing companies, claims processors, transcription services, IT contractors, lawyers and accountants who handle PHI, and—central to our story—cloud service providers (CSPs) that host or store electronic protected health information (ePHI) for a covered entity. The four verbs matter enormously: create, receive, maintain, or transmit. Notice that "use" or "view" is not on the list. A vendor that merely maintains PHI—that is, stores it—is squarely within the definition, even if it never reads a word of it. We will return to that point, because it is the hinge on which the entire cloud analysis turns.

A subcontractor is the third character, added by the 2013 Omnibus Rule, and it is the reason HIPAA liability flows down the supply chain like water. A subcontractor is a business associate that another business associate hires to help perform its services and that, in doing so, creates, receives, maintains, or transmits PHI. A subcontractor is itself a business associate, with the same direct liability. So if Acme Health (a business associate of its hospital client) stores patient data on a cloud platform, that cloud platform is Acme's subcontractor and is therefore also a business associate—bound by HIPAA, directly liable to the government, and required to sign its own agreement with Acme. The chain has no theoretical end. The cloud provider that uses a sub-processor for backups has just created another subcontractor business associate, and so on down the stack. The HHS guidance is blunt about this: there is no exception for "how far down the chain" the data travels. Each link must be papered with a compliant agreement and each link is independently accountable.

It helps to hold a concrete hierarchy in your head. The hospital is the covered entity. Acme Health, processing patient data for the hospital, is the hospital's business associate. The cloud platform hosting Acme's database is Acme's subcontractor business associate. The cloud platform's offsite backup vendor is a subcontractor's subcontractor business associate. Every one of them is bound by HIPAA's Security Rule and the relevant parts of the Privacy and Breach Notification Rules, and every adjacent pair must have a written agreement between them. The covered entity does not need a contract directly with the deepest subcontractor; rather, the obligation passes down, link by link, through a chain of agreements. That distinction—obligations flow down the chain rather than radiating from the top—is one of the most commonly misunderstood features of the whole regime, and getting it wrong is how organizations end up with gaps in their paperwork that surface only after a breach.

If you are building or reviewing a healthcare data program, this taxonomy should be the first thing you map, the same way a privacy team maps data flows when developing a privacy compliance program. You cannot protect data you have not located, and you cannot paper relationships you have not identified.

The Conduit Exception, and Why It Almost Never Saves a Cloud Provider

For years, vendors reached for a single lifeline to avoid business-associate status: the conduit exception. The argument went like this. HHS has always recognized that some entities merely transport information without meaningfully accessing it—the U.S. Postal Service, a courier delivering paper records, an internet service provider moving packets, a telephone company carrying a call. These pure transmission services are conduits, not business associates, even though PHI passes through their hands, because their access to the data is transient and incidental to the transport. The post office that delivers a sealed envelope of medical records is not a business associate. That much has never been controversial.

The temptation was obvious. Cloud storage providers argued, in effect, "We're just a digital post office. The data sits on our servers, but we don't use it—especially if it's encrypted and we don't have the key—so we're a conduit, not a business associate, and we don't need to sign anything or comply with HIPAA." For a while, the boundaries were genuinely murky, and the rapid evolution of cloud services outpaced the regulatory guidance.

In October 2016, HHS's Office for Civil Rights (OCR) issued "Guidance on HIPAA & Cloud Computing"—a detailed FAQ that remains the single most important document for anyone wrestling with these questions. The guidance slammed the conduit door shut for cloud providers, and it did so on a clean conceptual basis. The conduit exception, OCR explained, is narrow. It is limited to entities that provide mere courier services, such as the postal service or its electronic equivalent, and whose access to PHI is transient. The distinction is between transmission—including any temporary, incidental storage of data needed to perform the transmission—and the persistent maintenance of data. A cloud provider that stores ePHI, even for a customer, is maintaining it. Maintenance is not transient. Therefore a CSP that maintains ePHI on behalf of a covered entity or business associate is a business associate, period.

Two corollaries from the 2016 guidance deserve to be carved in stone, because they are where intuition fails:

First, encryption does not change the answer. A CSP that stores only encrypted ePHI, and that lacks the decryption key, is still a business associate. The reasoning is precise: the entity continues to receive and maintain the information (the four verbs again), and "the lack of an encryption key does not exempt a CSP from business associate status." OCR explicitly rejected a "no-key, no-liability" theory. Encryption is a critical security control—and, as we will see, it can transform a CSP's breach-notification exposure—but it does not transform the legal status of the vendor. The encrypted box is still maintained by the vendor, so the vendor is still a business associate.

Second, "no-view" services are still business-associate services. Many CSPs offer what the guidance calls "no-view" arrangements, in which the provider contractually promises not to access or view the customer's ePHI. That promise is excellent practice and is genuinely meaningful for limiting risk—but it does not make the provider a conduit. A no-view CSP still maintains the data, so it remains a business associate and must comply with the Security Rule in full and with the applicable provisions of the Privacy and Breach Notification Rules. We will unpack precisely how those obligations apply to a no-view provider below, because the allocation is subtler than people expect.

The practical upshot, restated as plainly as possible: if a cloud vendor stores, hosts, processes, or transmits your ePHI for you, assume it is a business associate and that you need a business associate agreement with it. The exceptions are vanishingly rare—a pure transmission pipe and nothing more. If you find yourself constructing an elaborate argument for why your storage vendor is "really just a conduit," you have almost certainly lost. The same instinct that leads organizations to over-retain data and assume that holding it is harmless—an instinct we caution against when discussing data minimization and avoiding the over-retention of personal information—is the instinct that leads them to under-paper their vendor relationships.

The Business Associate Agreement: What 45 C.F.R. 164.504(e) Actually Requires

If business-associate status is the what, the business associate agreement (BAA) is the how. The BAA is the contract that makes the whole chain enforceable. It is not optional, it is not a formality, and a covered entity that lets a vendor touch PHI without one has itself committed a HIPAA violation regardless of whether the vendor behaves perfectly. The agreement is required by, and its contents are dictated by, 45 C.F.R. 164.504(e), supplemented for the security side by 45 C.F.R. 164.314(a).

Section 164.504(e) is worth understanding clause by clause, because a BAA that omits a required term is not a "weak" BAA—it is, in OCR's eyes, a missing BAA, and the covered entity has failed to obtain satisfactory assurances. A compliant business associate agreement must, at minimum:

Establish the permitted and required uses and disclosures of PHI. The agreement must spell out exactly what the business associate may do with the data, and the agreement may not authorize the business associate to use or disclose PHI in a way the covered entity itself could not. This is the contractual embodiment of HIPAA's central restraint: the data may be used only for the agreed purpose and the law's narrow permitted purposes.

Prohibit further uses and disclosures not permitted by the contract or required by law. The default is no; the agreement carves out the specific yeses.

Require appropriate safeguards. The business associate must agree to use appropriate safeguards—and, for ePHI, to comply with the Security Rule—to prevent unauthorized use or disclosure. After the 2013 Omnibus Rule, this is not merely contractual; the Security Rule applies to business associates directly by force of statute, BAA or no BAA. But the BAA must say it anyway.

Require reporting of breaches and security incidents. The business associate must report to the covered entity any use or disclosure not provided for by the contract, including breaches of unsecured PHI and any security incidents of which it becomes aware. The timing and detail of that reporting is one of the most heavily negotiated parts of any real-world BAA, and we discuss it below.

Flow down to subcontractors. The business associate must ensure that any subcontractors that create, receive, maintain, or transmit PHI on its behalf agree to the same restrictions and conditions. This is the contractual mechanism that makes liability travel down the chain. A BAA that fails to require flow-down is defective.

Make PHI available for the access, amendment, and accounting-of-disclosures rights that the Privacy Rule gives individuals, to the extent the business associate holds PHI in a designated record set—so that the covered entity can meet its own obligations to patients.

Make internal practices available to HHS for purposes of determining the covered entity's compliance.

Return or destroy PHI at termination, if feasible, when the contract ends—and if return or destruction is not feasible, extend the protections for as long as the business associate retains the data and limit further use to the reasons that make return or destruction infeasible.

Authorize termination by the covered entity if the business associate materially breaches the agreement.

Two practical cautions follow from this list. First, a BAA is not a substitute for a commercial contract, and vice versa. The BAA governs HIPAA compliance; a separate master services agreement, order form, or service level agreement (SLA) governs price, uptime, support, and the rest of the commercial relationship. A well-run cloud arrangement has both. The SLA can and should address availability, data backup and recovery, and the division of security responsibilities—but the parties must ensure the SLA does not contradict the BAA or HIPAA. An SLA term that, for instance, let the provider purge data on short notice without honoring the covered entity's access obligations, or that limited the covered entity's right to its own ePHI, would be unenforceable to the extent it conflicts with HIPAA. The same care that goes into negotiating any software license agreement and into drafting software license agreements with attention to key terms and negotiation points should go into harmonizing the BAA and the SLA.

Second, do not rely on the cloud provider's standard click-through BAA without reading it. The major hyperscale providers all offer a HIPAA-eligible service tier with a form BAA, and those forms are generally competent. But "HIPAA-eligible" is not the same as "HIPAA-compliant"—it means the provider will sign a BAA and that certain services within its catalog are in scope. The customer remains responsible for confining its PHI to the in-scope services, configuring them correctly, and not spilling data into the out-of-scope corners of the platform. Many breaches trace not to a defective BAA but to a misconfigured storage bucket left publicly readable, a logging service that captured PHI it should not have, or a "shadow" use of a service the BAA never covered.

The Privacy, Security, and Breach Notification Rules in the Cloud

HIPAA is implemented through three principal rules, and a cloud arrangement implicates all three. Walking through them in turn—especially through the lens of a no-view CSP—shows how the obligations actually allocate.

The Privacy Rule

The Privacy Rule (45 C.F.R. Part 164, Subpart E) governs the permissible uses and disclosures of PHI in any form, paper or electronic. For a cloud provider, the headline is straightforward: even a no-view CSP may not use or disclose ePHI except as the BAA and HIPAA permit. The provider cannot mine the data for its own purposes, cannot sell it, cannot use it to train its products, and cannot disclose it outside the agreed channels. The fact that the provider promises not to look does not relax these rules; it reinforces them. A no-view CSP that nonetheless accessed and used customer ePHI for an unpermitted purpose would violate both its contract and the Privacy Rule.

The Privacy Rule is also the source of the data-disposition obligations that surprise vendors at the end of a relationship. A CSP has no general duty to retain ePHI after the service term ends—indeed, the Privacy Rule's minimum-necessary and disposition principles point the other way, toward returning or destroying the data unless another law requires retention. This is one place where good HIPAA practice and good general data-governance practice converge: holding data you no longer need is pure downside risk, the same lesson at the heart of data minimization.

The Security Rule

The Security Rule (45 C.F.R. Part 164, Subpart C) is where the cloud action mostly lives, because it governs ePHI specifically and imposes administrative, physical, and technical safeguards. Since 2013, the Security Rule applies directly to business associates, including CSPs. A no-view CSP must therefore conduct or contribute to a risk analysis, implement access controls, audit controls, integrity controls, and transmission security, and maintain the administrative scaffolding—policies, training, contingency planning—that the Rule demands.

The crucial wrinkle for the cloud is the current Security Rule's distinction between "required" and "addressable" implementation specifications. A required specification must be implemented. An addressable specification must be implemented if reasonable and appropriate; if not, the entity must document why and implement an equivalent alternative measure where reasonable. Encryption of ePHI, both at rest and in transit, is presently addressable—a fact that astonishes people who assume HIPAA mandates encryption. It does not, at least not yet. (The 2024–2025 proposal discussed below would change exactly this.)

Because the cloud is a shared environment, the Security Rule's obligations are divided between the customer and the provider, and the precise division depends on the service model. In an infrastructure-as-a-service arrangement, the provider secures the physical data center and the underlying hardware while the customer secures the operating system, the application, and the data. In a software-as-a-service arrangement, the provider takes on much more of the technical stack. The parties must therefore allocate Security Rule responsibilities expressly—who patches, who encrypts, who manages keys, who controls access, who logs and monitors—and an addressable measure that one party reasonably relies on the other to perform must actually be performed by that other party. A gap here is not a contract problem; it is a compliance failure that can hurt both sides. We say more about this allocation in the shared-responsibility discussion below.

The Breach Notification Rule

The Breach Notification Rule (45 C.F.R. Part 164, Subpart D) requires notification when there is a breach of unsecured PHI. Three definitions do the heavy lifting. A breach is, in general, an impermissible use or disclosure that compromises the security or privacy of the PHI, subject to a risk-assessment and several enumerated exceptions. Unsecured PHI is PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized persons through a technology or methodology specified by HHS guidance—principally encryption that meets the relevant standard, or proper destruction. And the notification clock differs by role: a covered entity must notify affected individuals (and, depending on the breach's size, HHS and the media) without unreasonable delay and no later than 60 days from discovery, while a business associate must notify the covered entity of a breach without unreasonable delay and no later than 60 days from discovery, providing the information the covered entity needs to make its own notifications.

For a CSP, the Breach Notification Rule produces a clean, almost elegant result. A no-view CSP that suffers a breach of unsecured ePHI must report it up the chain to its covered-entity or business-associate customer. But if the ePHI was secured—encrypted to the HHS standard—then a security incident involving that data may not be a reportable "breach" at all, because the information was never "unsecured." This is the famous encryption safe harbor, and it is the most important single risk-management tool in the HIPAA toolkit.

The Encryption Safe Harbor: The Most Valuable Two Paragraphs in HIPAA

The breach safe harbor deserves its own section because it is widely misunderstood in both directions. People either overstate it ("we encrypt, so HIPAA doesn't apply to us") or ignore it entirely. The truth sits precisely in the middle.

Here is the mechanism. The Breach Notification Rule only requires notification for breaches of unsecured PHI. HHS has specified that PHI is "secured"—and thus outside the breach-notification obligation—when it is encrypted using a methodology that renders it unusable, unreadable, or indecipherable to unauthorized individuals, consistent with applicable National Institute of Standards and Technology (NIST) guidance, and the decryption key was not also compromised. If a laptop full of properly encrypted ePHI is stolen, or an encrypted storage volume is exfiltrated, but the attacker never obtained the keys, then there is no breach of unsecured PHI and, generally, no duty to notify. The data the thief holds is mathematical noise.

This is why so many sophisticated healthcare organizations encrypt everything, everywhere, all the time—not because the Security Rule strictly requires it today (it is merely addressable), but because comprehensive encryption converts most data-loss events from career-defining breach disclosures into non-events. The safe harbor is the carrot that has driven more real-world encryption adoption than any mandate could.

Now the careful reader will notice the tension with the conduit discussion, and it is worth resolving directly. We said encryption does not exempt a CSP from business-associate status. We are now saying encryption can exempt a data-loss event from breach notification. Both are true, and they operate on different questions. Business-associate status asks: "Are you subject to HIPAA?" Encryption does not change that answer, because you still maintain the data. Breach notification asks: "Did a reportable breach of unsecured PHI occur?" Encryption can change that answer, because properly encrypted data is "secured." A no-view CSP holding only encrypted ePHI it cannot read is therefore still a HIPAA business associate, must still sign a BAA, must still comply with the Security Rule—but if its encrypted store is compromised without the keys, it likely has no breach to report. Status and notification are simply two different doors, and encryption opens one while leaving the other locked.

One more honest caveat: the safe harbor protects only against the federal HIPAA breach-notification obligation. State data-breach notification laws vary, and some are less generous about encryption, may define "personal information" more broadly than HIPAA defines PHI, and may impose their own notification duties. A healthcare organization that breathes easy on HIPAA may still owe notice under a state statute. And of course, encryption that is poorly implemented—weak algorithms, keys stored next to the data, keys compromised alongside the ciphertext—provides neither real security nor the safe harbor. The shield works only if the encryption is real.

Shared Responsibility: Who Is on the Hook When Something Breaks

The single most important operational concept in cloud HIPAA compliance is the shared-responsibility model, and the most expensive mistakes happen in the gaps between the parties. The cloud provider is responsible for the security of the cloud—the physical facilities, the host infrastructure, the virtualization layer. The customer is generally responsible for security in the cloud—how it configures the services, who it grants access to, how it manages its own credentials and keys, and what data it chooses to put where. Between those two lies a contested middle ground that the BAA and SLA must allocate explicitly.

Consider a worked example. Acme Health stores patient records in a cloud object-storage service under a signed BAA. The cloud provider encrypts the storage hardware, runs a hardened data center, and patches the underlying platform—its half of the bargain. Acme, however, misconfigures a storage bucket so that it is readable by anyone on the internet, and a security researcher discovers thousands of patient files exposed. Whose fault is this? The cloud provider did everything its BAA required; the configuration error was Acme's, on Acme's side of the shared-responsibility line. Acme—not the provider—has suffered a breach of unsecured PHI (the files were exposed in readable form), and Acme must notify its hospital customer, which must in turn notify patients and HHS. The provider's flawless security of the cloud did not save Acme from its own failure of security in the cloud. Real OCR enforcement actions have repeatedly involved exactly this pattern: exposed databases, misconfigured servers, and unprotected storage that the customer—not the platform—left open.

Now flip the example. Suppose the breach traced to a flaw in the provider's own infrastructure—a failure on the provider's side of the line. There, the provider, as a business associate, has its own direct liability and its own duty to notify up the chain, and Acme's recourse runs through the BAA's indemnification and the provider's HIPAA obligations. The point is that the allocation is not academic. When something breaks, the first question is always on whose side of the shared-responsibility line did it break, and the answer is only as clear as the BAA, the SLA, and the configuration documentation made it.

This is why incident-response planning for healthcare organizations must be built around the cloud architecture, not around a fictional on-premises world. When a breach hits a multi-vendor stack, the covered entity needs to know instantly which vendor holds what, who must be notified, and within what window—the same discipline we describe in the context of cybersecurity incident response and protecting sensitive information during data breaches. And because so much sensitive work now happens on personal and remote devices reaching into cloud systems, the access-control and device-management questions that healthcare shares with every other industry—explored in trade secrets in the age of remote work and cloud computing—are HIPAA questions too. Mobile devices can reach ePHI in the cloud, which is convenient and dangerous in equal measure; the safeguards (encryption, remote wipe, access controls, a covering BAA where a vendor is involved) are what make the convenience survivable.

Security Incident Reporting: The Most Negotiated Clause in the BAA

Buried in the Security Rule and the BAA is a definitional landmine that consumes a startling amount of lawyer time. The Security Rule defines a "security incident" very broadly—as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations. Read literally, that definition sweeps in essentially every port scan, every blocked intrusion attempt, every failed login—events that occur thousands of times a day on any internet-facing system.

A BAA that required the business associate to report every such "security incident" in real time would be absurd, drowning the covered entity in noise. So the market has developed a sensible practice: BAAs typically distinguish between reportable security incidents (successful unauthorized access, actual breaches of unsecured PHI) and the background hum of unsuccessful attempts, which the parties handle through a periodic "deemed notice" clause—an acknowledgment that low-level pings and probes occur constantly and are reported in the aggregate, if at all. The genuinely consequential reporting obligations—breaches of unsecured PHI—are governed by the Breach Notification Rule's timelines, but the BAA can and often does impose stricter requirements, such as notice within 24, 48, or 72 hours rather than the regulatory 60-day outer limit. Covered entities want fast notice because their own clock is running; business associates want realistic windows that account for the time to investigate and confirm. Where that line gets drawn is one of the most heavily negotiated terms in any real BAA, and it is worth getting right, because in a breach the difference between "notice within 24 hours" and "notice within 60 days" can be the difference between a contained incident and a regulatory catastrophe.

OCR Enforcement and the Price of Getting It Wrong

HIPAA is enforced by the Office for Civil Rights within HHS, and the enforcement is real. OCR investigates complaints, conducts compliance reviews, runs periodic audit programs, and—importantly since the 2013 Omnibus Rule—can pursue business associates directly, not merely through the covered entities that hired them. A cloud provider that violates the Security Rule answers to OCR in its own right.

The civil monetary penalties are tiered by culpability, a structure set by the HITECH Act and codified at 42 U.S.C. 1320d-5 and 45 C.F.R. Part 160, Subpart D. The four tiers run from violations the entity did not know about and could not reasonably have known about, through reasonable cause, through willful neglect that was corrected, up to willful neglect that was not corrected—with per-violation minimums and maximums rising at each tier and an annual cap per identical provision. (The exact dollar figures are adjusted annually for inflation, so a current schedule should always be consulted rather than memorized.) Layered on top is the possibility, for the most egregious knowing misuse of PHI, of criminal penalties under 42 U.S.C. 1320d-6, including fines and imprisonment.

Two enforcement realities matter most for cloud arrangements. First, there is an affirmative defense and a 30-day cure window: a regulated entity can avoid a civil penalty for a violation that is not due to willful neglect if it corrects the violation within 30 days of when it knew or, exercising reasonable diligence, should have known of it. The escape hatch slams shut, however, where the violation was due to willful neglect—so the entity that buries its head in the sand, ignores known risks, or fails to do the required risk analysis cannot later claim the cure. Second, OCR's published resolution agreements have repeatedly hammered two specific failures: the absence of a thorough, enterprise-wide risk analysis, and the absence of a signed business associate agreement before PHI changed hands. Multimillion-dollar settlements have turned on a covered entity that handed PHI to a vendor with no BAA in place, or on an organization that never performed an accurate risk analysis and so never discovered the unencrypted server or the exposed database that eventually leaked. The lesson is unglamorous but reliable: do the risk analysis, sign the BAAs, and you eliminate the two most common paths to a penalty.

The structure of HIPAA enforcement—an administrative agency, tiered penalties keyed to culpability, a cure period, and the looming possibility of criminal liability for the worst conduct—is a useful template for understanding regulatory privacy enforcement generally, a theme that runs through any serious effort at building a privacy compliance program.

The 2024–2025 Security Rule Overhaul: The Biggest Change in a Decade

Now to the fast-moving part, the part that will reshape cloud HIPAA compliance if it is finalized. On December 27, 2024, OCR issued a Notice of Proposed Rulemaking (NPRM) to overhaul the HIPAA Security Rule for the first time in a meaningful way since 2013, formally published in the Federal Register on January 6, 2025, with the public comment period closing March 7, 2025. As of mid-2026, OCR is still working through more than four thousand comments and has not issued a final rule; the agency's regulatory agenda has targeted finalization for 2026, but under the current administration's deregulatory posture the proposal could be finalized, narrowed, delayed, or withdrawn. Treat everything in this section as a proposal—important to track and to prepare for, but not yet binding law. (HHS fact sheet; HHS NPRM page; HIPAA Journal status tracking.)

What the proposal would do is genuinely consequential, and it strikes directly at the cloud. The headline changes:

No more "addressable" specifications. The proposal would eliminate the distinction between "required" and "addressable" implementation specifications, making essentially all of them mandatory, with only narrow, documented exceptions. This is the change that ends the long era in which encryption was technically optional.

Mandatory encryption of ePHI at rest and in transit. Encryption, today merely addressable, would become required (subject to limited exceptions). For cloud providers and their customers, this is enormous: the encryption that already drives the breach safe harbor would become an affirmative legal duty, not just a smart practice.

Mandatory multifactor authentication (MFA). The proposal would require MFA for access to systems holding ePHI—a recognition that stolen passwords are the leading cause of healthcare breaches.

Network segmentation, vulnerability scanning, and penetration testing. Regulated entities would have to segment their networks to contain intrusions, conduct vulnerability scans on a regular cadence (the NPRM proposes specific intervals), and perform penetration testing periodically.

A written technology asset inventory and a network map. Entities would have to maintain an up-to-date inventory of their technology assets and a map of how ePHI moves through their systems—formalizing the data-flow mapping that good programs already do informally, and that is the necessary first step to securing anything.

Tighter, more specific risk analysis requirements, including a written assessment that follows enumerated steps, rather than the more open-ended risk-analysis obligation in the current rule.

Stronger business-associate and subcontractor obligations. Two cloud-specific provisions stand out. Business associates would have to verify, through written analysis and certification by a subject-matter expert, that they have deployed the required technical safeguards—an annual attestation of sorts. And business associates would have to notify covered entities within 24 hours when they activate their contingency plans (for example, when responding to a major security event), tightening the information flow that the current Breach Notification Rule leaves at 60 days for the bulk of the notice.

If finalized in anything close to this form, the proposal would standardize across the industry many controls that careful organizations already deploy, while forcing the laggards to catch up. The effective date would run 60 days after a final rule, with a proposed compliance window of 180 days after that—meaning organizations that wait for finality before starting will be scrambling. The prudent posture for any cloud-dependent healthcare entity is to treat the proposal as a preview of the floor: encrypt everything, deploy MFA everywhere, segment your networks, inventory your assets, map your data flows, and tighten your BAAs' notification clocks now. None of those steps is wasted even if the rule changes; all of them reduce real risk today and position the organization for whatever the final rule requires.

PHI in AI and Analytics: The Hardest Problem on the Horizon

The newest and least settled question is what happens when protected health information meets artificial intelligence and advanced analytics. Healthcare is awash in AI ambition—diagnostic models, clinical-decision support, ambient scribes that transcribe patient encounters, population-health analytics, predictive models for readmission or sepsis. Every one of those systems is hungry for data, and the most useful data is exactly the most sensitive: real patient records.

HIPAA does not prohibit using PHI to build or run AI, but it constrains it sharply, and the constraints map onto everything above. If a covered entity uses a third-party AI or analytics vendor that creates, receives, maintains, or transmits PHI, that vendor is a business associate and needs a BAA—same analysis as any cloud provider, because an AI platform is, for HIPAA purposes, a cloud platform that happens to do math. The BAA's permitted-use clause becomes the crucial battleground: may the vendor use the covered entity's PHI to train or improve its own models? Under the Privacy Rule and a standard BAA, the default answer is no—the vendor may use the data only to perform the contracted service for the covered entity, not to enrich its general-purpose model for the benefit of other customers. Vendors who want training rights must negotiate them explicitly, and covered entities should think very hard before granting them, because PHI fed into a model can be difficult to extract and models can sometimes be coaxed to regurgitate their training data.

The cleaner path, where it works, is de-identification. HIPAA's Privacy Rule provides two routes to de-identify PHI—the Safe Harbor method (removing 18 enumerated categories of identifiers) and the Expert Determination method (a qualified statistician certifies that the re-identification risk is very small), both at 45 C.F.R. 164.514. Properly de-identified data is no longer PHI and falls outside HIPAA entirely, which is why so much healthcare AI is trained on de-identified datasets. But de-identification is harder than it looks: rich, high-dimensional data (genomic data, detailed location traces, free-text clinical notes, imaging) can sometimes be re-identified by linkage, and a careless "anonymization" that leaves quasi-identifiers in place provides neither the legal status nor the protection it promises. Expert Determination exists precisely because the Safe Harbor list is a blunt instrument for modern data.

The frontier issues compound from there. Models can memorize and leak training data. Inference outputs can themselves constitute PHI. Audit logging of AI systems is technically difficult but essential to the Security Rule. And the same biometric and behavioral data that powers consumer health AI raises privacy questions that reach well beyond HIPAA into state biometric-privacy statutes—the terrain we cover in biometric data privacy laws and their impact on AI development. The honest assessment as of 2026 is that the law here is unsettled and moving quickly; the regulators have not finished thinking it through, the case law is thin, and the safest course is conservative: de-identify where you can, sign airtight BAAs with explicit (and usually narrow) use grants where you cannot, and document the risk analysis for every PHI-touching AI system as if OCR will one day ask to see it—because it might.

Wearables, the IoT, and the Edges of the Definition

A final boundary worth marking, because it trips people up: not all health data is PHI, and not every health gadget triggers HIPAA. HIPAA reaches PHI held by or for covered entities and their business associates. The same health metric can be inside or outside HIPAA depending on who holds it and why.

Consider wearable fitness trackers, a recurring example in HHS's own materials. If you buy a fitness tracker at retail and the manufacturer's app stores your heart-rate data, that company is generally not a covered entity or business associate, and HIPAA does not apply to that relationship—your data is governed instead by the FTC Act, the FTC's Health Breach Notification Rule for certain non-HIPAA health apps, and state privacy law. But change the facts: suppose a health plan distributes those same trackers to its members as part of a wellness program and engages a cloud vendor to collect and store the resulting individually identifiable health information. Now the data is being created and maintained for a covered entity, the cloud vendor is a business associate, and a BAA is required. The device is identical; the legal regime flipped because of who deployed it and for what purpose. This is the single best illustration of HIPAA's most counterintuitive feature: it is a law about relationships and roles, not about data sensitivity in the abstract. The same lesson appears in adjacent privacy contexts—a fact pattern can sit inside or outside a statute depending on the actors involved, which is why mapping the actors is always step one, whether under HIPAA or under the broader mobile-app privacy regime discussed in legal issues for mobile applications and privacy.

Cross-Border Storage and Data Localization

One more practical question rounds out the picture: may a CSP store ePHI on servers outside the United States? HIPAA itself does not prohibit it. The 2016 HHS cloud guidance acknowledges that a business associate may store ePHI overseas, but cautions that doing so can introduce additional risks to the confidentiality, integrity, and availability of the data—legal-process risks, foreign-government-access risks, and practical-control risks that vary by jurisdiction. A covered entity or business associate that permits offshore storage should account for those risks in its risk analysis and may reasonably impose additional safeguards or geographic restrictions through the BAA and SLA. The cross-border dimension also implicates a separate and rapidly evolving body of international transfer law that healthcare organizations operating globally cannot ignore, surveyed in international data transfers after Schrems II. HIPAA is permissive about geography; prudence and other laws are not.

Key Takeaways

The whole of cloud HIPAA compliance can be compressed into a handful of durable propositions. If you remember nothing else, remember these.

Almost every cloud vendor that touches your ePHI is a business associate, bound by HIPAA and directly liable to the government—and that liability flows down the chain to subcontractors and their subcontractors, link by link, through a chain of agreements.

The conduit exception is for pure transmission pipes only; it does not save a vendor that maintains (stores) your data. Encryption does not change business-associate status, and "no-view" services are still business-associate services.

You must have a business associate agreement that meets every requirement of 45 C.F.R. 164.504(e) before PHI changes hands. A BAA missing a required term is, in OCR's eyes, no BAA at all—and the absence of a BAA is one of the two most common paths to a penalty (the other being the absence of a real risk analysis).

The encryption safe harbor under the Breach Notification Rule is HIPAA's most valuable risk-management tool: properly encrypted, key-protected ePHI is "secured," so its compromise generally triggers no federal breach-notification duty. Encryption does not exempt you from HIPAA, but it can exempt a data-loss event from notification—two different doors.

Cloud compliance is a shared-responsibility exercise: the provider secures the cloud, the customer secures its use of the cloud, and the BAA and SLA must allocate the contested middle explicitly. The most common breaches live in the gaps.

The 2024–2025 Security Rule proposal, if finalized, would make encryption and MFA mandatory, eliminate the addressable/required distinction, and require network segmentation, asset inventories, data-flow maps, and tighter notification—so deploy those controls now regardless.

And when AI and analytics enter the picture, the same rules apply: the vendor is a business associate, the BAA's use grant is the battleground, training rights are not implied, and de-identification—done rigorously—is the cleanest exit from HIPAA's reach.

Frequently Asked Questions

Is a cloud storage provider a HIPAA business associate even if it only stores encrypted data it cannot read? Yes. The 2016 HHS cloud guidance is explicit: a CSP that receives and maintains ePHI is a business associate even if it stores only encrypted data and lacks the decryption key. Maintaining the data is enough; the lack of a key does not exempt the provider. Encryption affects the breach-notification analysis, not business-associate status.

Do I really need a business associate agreement with a major cloud provider, or is its standard terms-of-service enough? You need a BAA, specifically. The major hyperscale providers offer HIPAA-eligible service tiers and will sign a form BAA—use it. But "HIPAA-eligible" only means certain services are in scope and the provider will sign; you remain responsible for confining PHI to the in-scope services, configuring them correctly, and meeting your own Security Rule and risk-analysis obligations. Standard commercial terms without a BAA are not sufficient, and letting PHI flow to a vendor without a BAA is itself a HIPAA violation.

If we encrypt all of our ePHI, do we still have to comply with HIPAA? Yes. Encryption is a powerful security control and unlocks the breach-notification safe harbor for secured data, but it does not remove you from HIPAA's coverage or relieve you of the Security Rule, the Privacy Rule, or the BAA requirement. Encryption changes what you must report after an incident; it does not change whether the law applies to you.

What happens if a cloud breach is caused by our own misconfiguration rather than the provider's failure? Under the shared-responsibility model, a breach caused by your configuration—an exposed storage bucket, an open database, a mismanaged credential—falls on your side of the line. You, not the provider, have suffered the breach of unsecured PHI and bear the notification obligation up the chain. The provider's flawless security of its infrastructure does not cover your security failures in your use of it. This pattern accounts for a large share of real OCR enforcement actions.

Are the 2024–2025 HIPAA Security Rule changes in effect yet? No. OCR issued the proposed rule in December 2024, published it in the Federal Register on January 6, 2025, and closed comments on March 7, 2025. As of mid-2026 there is no final rule; finalization has been targeted for 2026 but could be delayed, narrowed, or withdrawn. Until a final rule issues, the current Security Rule governs. Prudent organizations are nonetheless implementing the proposed controls—mandatory encryption, MFA, segmentation, asset inventories, data-flow maps—now, because they reduce real risk and ease eventual compliance.

Can we use real patient data to train an AI model with a cloud AI vendor? Only carefully. If the vendor creates, receives, maintains, or transmits PHI, it is a business associate and needs a BAA, and a standard BAA does not grant the vendor the right to use your PHI to train or improve its own general models—you would have to negotiate that explicitly, and you should be very cautious about doing so. The cleaner approach where feasible is to de-identify the data under the Safe Harbor or Expert Determination methods of 45 C.F.R. 164.514, which removes it from HIPAA's scope—bearing in mind that rich, high-dimensional data can sometimes be re-identified, so de-identification must be done rigorously.

Does a fitness tracker or health app automatically fall under HIPAA? No. HIPAA reaches health data only when it is held by or for a covered entity or business associate. A consumer fitness app you download yourself is generally not covered by HIPAA—it is governed by the FTC Act, the FTC's Health Breach Notification Rule, and state law. But the same device deployed by a health plan as part of a wellness program, with a cloud vendor collecting the data, does bring HIPAA into play, and the vendor becomes a business associate. HIPAA is about roles and relationships, not the abstract sensitivity of the data.

How long must a cloud provider keep our ePHI after the contract ends? Generally, it should not keep it. The Privacy Rule and a compliant BAA require the business associate to return or destroy the PHI at termination where feasible (and, where not feasible, to extend protections and limit use for as long as it retains the data). A CSP has no general duty to retain ePHI past the service term unless another law requires it. Holding data you no longer need is risk without reward.

Related Articles

This article provides general information and is not legal advice. The HIPAA Rules and the pending Security Rule proposal are detailed and fast-moving, and their application depends on your specific facts. Consult qualified counsel before making decisions about HIPAA compliance, business associate agreements, or cloud arrangements involving protected health information.