HIPAA Compliance in the Cloud: The Complete Framework Guide

Key Takeaways

• HIPAA compliance in the cloud means protecting electronic protected health information (ePHI) to the standard of the HIPAA Rules while it lives in AWS, Azure, or Google Cloud. Moving ePHI to a cloud provider does not transfer your liability. It splits it.
• A cloud provider’s Business Associate Agreement (BAA) covers the platform it runs. Your configuration, access, encryption, and monitoring of ePHI on top of that platform stay your responsibility, which is where almost every cloud HIPAA violation happens.
• The HIPAA Security Rule technical safeguards in 45 CFR §164.312 (access control, audit controls, integrity, person authentication, and transmission security) map directly to concrete cloud controls you can implement and prove.
• Compliance is continuous, not a one-time attestation. You need to locate ePHI as it spreads, detect drift and exposure, and keep evidence audit-ready across multi-cloud, not pass a single point-in-time check.
• Orca uses agentless SideScanning™ to discover ePHI across a cloud estate, map posture to the Security Rule, and surface the exposed attack paths to that data, so the part you own is something you can see and prove.

HIPAA compliance in the cloud is the practice of protecting electronic protected health information (ePHI) to the standard set by the HIPAA Rules while that data is stored and processed in cloud services like AWS, Azure, and Google Cloud. It combines the Privacy Rule, the Security Rule, and the Breach Notification Rule with the cloud’s shared-responsibility model.

The hook that catches most teams is simple. Moving ePHI to the cloud does not hand your HIPAA liability to the provider. It divides it. The provider secures the platform under a Business Associate Agreement, and everything you build on top of that platform, every bucket, role, key, and log, is yours to secure and prove.

This guide is written for security and platform engineers, not lawyers. It covers the Rules that apply, what the BAA does and does not cover, the Security Rule controls mapped to real cloud settings, a step-by-step checklist, and how to prove compliance continuously instead of once a year. Organizations managing HIPAA alongside other regulatory requirements should also understand the fundamentals of multi-cloud compliance.

What Is HIPAA Compliance (and What It Means in the Cloud)?

HIPAA compliance is meeting the requirements of the Health Insurance Portability and Accountability Act for protecting patient health information. It applies to covered entities (healthcare providers, health plans, and clearinghouses) and to business associates, the vendors that handle protected health information (PHI) on their behalf.

In the cloud, that definition gains an operational edge. A cloud provider holding your ePHI is a business associate, so HIPAA follows the data into the provider’s infrastructure. The Department of Health and Human Services (HHS) made this explicit in its Guidance on HIPAA & Cloud Computing: a cloud service provider that creates, receives, maintains, or transmits ePHI is a business associate, even when it only stores encrypted data and cannot read it.

That last point matters. HHS rejected the idea that a “no-view” provider escapes HIPAA. Lacking the decryption key does not exempt a provider from business associate status or obligations. So the compliance question is never “did we put ePHI somewhere safe,” it is “can we demonstrate, control by control, that the ePHI is protected wherever it now lives.”

Why the cloud changes the HIPAA equation

The Security Rule was written with traditional, organization-owned infrastructure in mind. Cloud infrastructure is dynamic, ephemeral, and multi-account, which breaks the assumptions behind a static, once-a-year audit.

Three properties drive the change. Cloud resources spin up and down by the minute, so the systems holding ePHI on Monday may not exist on Friday. Identities and permissions multiply across services, so “who can reach this data” is a moving target rather than a fixed list. And most estates span more than one provider, so the same control has to be proven in AWS, Azure, and Google Cloud at once. The result is that point-in-time evidence goes stale fast, and continuous visibility becomes the only honest way to claim compliance.

The HIPAA Rules That Govern the Cloud

Three of the HIPAA Rules shape what you do in the cloud: the Privacy Rule, the Security Rule, and the Breach Notification Rule. The Security Rule carries the most weight for a security team, because it is the one that translates into technical controls.

The Privacy Rule (use & disclosure of PHI)

The Privacy Rule governs who may use and disclose PHI and for what purpose, and it grants patients rights over their own data. It is mostly a policy and process discipline rather than a configuration one.

In the cloud, the Privacy Rule shows up as the “minimum necessary” principle. Access to PHI should be limited to what each role actually needs, which is a policy goal that you enforce with the Security Rule’s access controls. The connection is direct: a Privacy Rule promise to limit disclosure is only real if your IAM and data permissions in the cloud actually enforce it.

The Security Rule — administrative, physical & technical safeguards

The HIPAA Security Rule sets the safeguards for protecting ePHI specifically, and it is organized into three groups: administrative, physical, and technical. In the cloud, the provider handles most physical safeguards (data center security, hardware disposal) under its BAA. Administrative safeguards (risk analysis, workforce policies, training) stay with you. Technical safeguards are where cloud configuration lives.

The technical safeguards in 45 CFR §164.312 are the spine of a HIPAA cloud program. Each safeguard includes implementation specifications marked either “required” or “addressable”. “Addressable” does not mean optional. It means you must implement the safeguard or document an equivalent alternative.

Security Rule technical safeguard (§164.312)	What it requires
Access control (a)	Unique user IDs, emergency access, automatic logoff, and encryption/decryption of ePHI
Audit controls (b)	Hardware, software, or procedural mechanisms that record and examine activity in systems with ePHI
Integrity (c)	Protect ePHI from improper alteration or destruction, and corroborate it has not been changed
Person or entity authentication (d)	Verify that anyone seeking access to ePHI is who they claim to be
Transmission security (e)	Guard ePHI in transit against unauthorized access, with integrity controls and encryption

These map cleanly onto cloud settings, which is the section after next. The Security Rule also defines your broader HIPAA compliance requirements: a documented risk analysis under §164.308 is the administrative safeguard auditors ask for first.

The Breach Notification Rule

The Breach Notification Rule requires covered entities to notify affected individuals, HHS, and in large cases the media when unsecured PHI is breached. Business associates must notify the covered entity. The clock is tight: notification to individuals is required without unreasonable delay and no later than 60 days from discovery.

One detail changes cloud architecture. Breaches of properly encrypted ePHI generally fall under a safe-harbor and do not trigger notification, because encrypted data rendered unreadable is not “unsecured.” That single fact is why encryption with keys you control is the highest-leverage control in a cloud HIPAA program: it protects the data and it limits your reporting exposure when something goes wrong.

The Shared Responsibility Model & Business Associate Agreements (BAAs)

The core of cloud HIPAA is the shared responsibility model: the cloud provider secures the infrastructure, and you secure what you put on it. A BAA is the contract that makes the provider legally accountable for its share. Signing one is necessary, and it is nowhere near sufficient.

A BAA commits the provider to safeguard the ePHI its platform handles and to report incidents on its side. It says nothing about whether you left a storage bucket public, attached an over-permissive role to a workload, or shipped logs with PHI to an unmonitored sink. HHS guidance is blunt on this division: the customer remains responsible for implementing the safeguards on the services it configures. The misconfiguration is yours, and so is the violation.

This is the objection worth dismantling head-on. “We use AWS and signed a BAA, so we’re HIPAA compliant” is the single most common and most expensive misread in cloud healthcare. The BAA covers the platform. Your configuration, access, encryption, monitoring, and the evidence that all of it works are the part HIPAA actually holds you to.

Is AWS / Azure / Google Cloud HIPAA compliant? (CSP eligibility + the configuration gap)

No cloud provider is “HIPAA compliant” as a product, and any vendor claiming otherwise is overselling. What AWS, Azure, and Google Cloud each offer is HIPAA eligibility: they will sign a BAA and they publish a list of HIPAA-eligible services that may be used with ePHI.

The gap sits between eligible and compliant. A service being HIPAA-eligible means you are allowed to put ePHI on it under the BAA. It does not mean your specific deployment is configured to the Security Rule. You close the gap by using only eligible services for ePHI, configuring each one correctly (encryption on, access scoped, logging enabled), and proving it. AWS security essentials, Azure security essentials, and securing Google Cloud workloads explain the native controls each platform provides.

What Does a HIPAA-Compliant Cloud Look Like? (Required Controls)

A HIPAA-compliant cloud is one where every Security Rule technical safeguard maps to a configured, monitored control on the services that hold ePHI. The six controls below cover §164.312 in the order a practitioner would implement them.

Encryption of ePHI in transit & at rest

Encrypt ePHI everywhere it sits and everywhere it moves. The Security Rule lists encryption as addressable, but given the breach safe-harbor, treat it as mandatory in practice. Enable encryption at rest on every store that can hold ePHI (object storage, block volumes, managed databases, backups, snapshots) and enforce TLS for data in transit between services.

Control your own keys. Use a cloud key management service (AWS KMS, Azure Key Vault, Google Cloud KMS) with customer-managed keys so you, not just the provider, govern access to the plaintext. This satisfies the §164.312(a) encryption specification, and because properly encrypted data counts as secured, a breach of it is generally not reportable.

Access controls & least privilege to PHI

Restrict access to ePHI to the identities that genuinely need it, and no more. This satisfies §164.312(a) access control and §164.312(d) authentication, and it is the cloud expression of the Privacy Rule’s minimum-necessary principle.

In practice that means unique identities (no shared accounts), multi-factor authentication on anything that can reach PHI, and scoped IAM policies instead of wildcard permissions. The hard part in the cloud is entitlement sprawl: roles accumulate permissions over time until far more identities can reach a PHI datastore than anyone intended. Managing that is the job of cloud infrastructure entitlement management, and tying access to a role-based access control model keeps the minimum-necessary promise enforceable.

Audit controls & logging

Record and examine activity wherever ePHI lives, as required by §164.312(b). In the cloud that means turning on the control-plane and data-plane logs (CloudTrail, Azure Monitor, Google Cloud Audit Logs), capturing access to PHI data stores, and retaining the records long enough to investigate an incident and satisfy an auditor.

Logging that nobody watches is a finding waiting to happen. Pair collection with review, alerting on anomalous access to PHI, and protect theaudit logs themselves from tampering. The Security Rule wants both the record and the examination of it, not just storage.

Integrity controls & file-integrity monitoring

Protect ePHI from improper alteration or destruction, per §164.312(c). The cloud-native versions of this are object-versioning and immutability features (such as S3 Object Lock), database point-in-time recovery, and write-once backup policies that an attacker or a mistake cannot silently overwrite.

Add detection on top of prevention. Monitor for unexpected changes to ePHI stores and to the configurations that protect them, so an unauthorized modification surfaces rather than sitting undetected until disposal.

Transmission security

Guard ePHI as it crosses networks, per §164.312(e). Enforce TLS for every service-to-service and client-to-service path that carries PHI, disable weak protocols and ciphers, and avoid sending ePHI over public endpoints when private connectivity (VPC endpoints, private link) is available.

The common cloud failure is internal traffic assumed to be safe. ePHI moving unencrypted between microservices inside a VPC still breaches transmission security if that path is not protected, so treat east-west traffic with the same rigor as north-south.

Data classification & locating ePHI

You cannot protect ePHI you cannot find, and in the cloud it spreads. The first control is discovery: knowing every place ePHI lives, including the copies in dev and test environments, analytics pipelines, and backups that nobody registered.

Classify data so the controls above apply consistently to every ePHI store, not just the production database everyone remembers. Data discovery and classification underpin every HIPAA program. Without knowing where ePHI lives, you cannot consistently apply encryption, access controls, logging, or monitoring. Cloud data security risks and best practices explores how to discover and protect sensitive cloud data at scale.

HIPAA Cloud Compliance Checklist (Step-by-Step)

This checklist turns the Rules and controls above into an implementation sequence. Work through it in order, because each step depends on the ones before it.

1. Sign a BAA with every provider and vendor that touches ePHI. That includes your cloud providers and any SaaS or processing service that stores, transmits, or sees PHI. No BAA, no ePHI on that service.
2. Inventory and classify all ePHI across your cloud accounts. Find every store of PHI, including copies in dev, test, analytics, and backups. You can only protect what you can locate.
3. Encrypt ePHI in transit and at rest, with keys you manage. Turn on encryption for every store and enforce TLS for every path, using a cloud KMS with customer-managed keys.
4. Enforce least privilege and MFA to every system holding ePHI. Remove shared accounts and wildcard permissions, require multi-factor authentication, and scope roles to the minimum necessary.
5. Enable audit logging everywhere ePHI lives, and retain it. Capture control-plane and data-plane activity, alert on anomalous access, and protect logs from tampering.
6. Run and document a Security Rule risk analysis (§164.308). Identify risks to ePHI, rate them, and record the decisions. This is the administrative artifact auditors request first.
7. Stand up breach detection and an incident response plan. Define how you detect exposure of PHI and how you meet the 60-day Breach Notification Rule timeline.
8. Continuously monitor for drift, misconfiguration, and new exposure. Static checks decay as infrastructure changes, so watch for new public buckets, widened permissions, and disabled logging as they happen.
9. Map your cloud controls to the Security Rule and keep evidence audit-ready. Maintain a live mapping from each §164.312 safeguard to the configured control and its proof, across every cloud you run.

Common HIPAA Cloud Compliance Challenges & Violations

Most cloud HIPAA failures are not exotic. They are everyday misconfigurations on the customer’s side of the shared-responsibility line, each one breaching a specific safeguard. The pattern is consistent: the platform was fine, the configuration on top of it was not.

• Public storage exposing ePHI. A misconfigured S3 bucket or blob container holding patient records gets exposed to the internet, breaching access control (§164.312(a)) and transmission security (§164.312(e)).
• Over-permissioned identities reaching PHI. A workload or user role with wildcard permissions can read a database of PHI it never needed, breaching the access-control and minimum-necessary requirements.
• Unencrypted ePHI. A database, volume, or backup left unencrypted, or PHI sent over an unencrypted internal path, breaches the encryption and transmission-security specifications and forfeits the breach safe-harbor.
• Missing or disabled audit logs. A PHI datastore with logging turned off leaves no record of access, a direct breach of audit controls (§164.312(b)).
• ePHI sprawled into unmanaged copies. Production data cloned into a dev environment or analytics bucket outside the BAA’s scope creates ePHI nobody is protecting or monitoring.
• ePHI on a non-eligible service or with no BAA. Putting PHI on a service the provider has not made HIPAA-eligible, or one with no signed BAA, is a violation regardless of how well it is configured.

The scale is not theoretical. In July 2025, Change Healthcare notified OCR that a February 2024 ransomware attack on its systems had exposed the protected health information of roughly 192.7 million people, the largest breach in U.S. health-data history according to HHS. Hacking and IT incidents are now the leading cause of breached health records on the OCR portal, which is exactly the failure mode cloud misconfiguration feeds.

How to Choose a HIPAA-Compliant Cloud Service Provider

Choosing a provider for ePHI is mostly about verifying its share of the shared-responsibility model and confirming it gives you the controls to handle yours. Start from one non-negotiable: the provider must sign a BAA. If it will not, the conversation is over.

Use these criteria to evaluate any provider or SaaS vendor that will touch PHI:

• Willingness to sign a BAA, and what the BAA covers. Read the actual terms, including breach-notification commitments and which services the BAA scopes in.
• A published list of HIPAA-eligible services. Confirm the specific services you plan to use for ePHI are eligible, not just that the provider “supports HIPAA.”
• Independent attestations. SOC 2, ISO 27001, and HITRUST certifications show the provider’s controls are tested by a third party.
• Encryption with customer-managed keys. You should be able to hold and rotate your own keys through the provider’s KMS.
• Logging and audit depth. The provider must expose detailed access and configuration logs you can collect, retain, and review.
• Data residency and region controls. You need to constrain where ePHI is stored and replicated so it cannot land in a region or service outside scope.

Attestations from a provider apply to the provider, not to your account. A HITRUST-certified platform still leaves your configuration to you, so weigh how clearly the provider documents the responsibility split. The same procurement principles apply across most cloud compliance frameworks, making a multi-cloud compliance reporting checklist useful beyond HIPAA.

How to Continuously Maintain HIPAA Compliance in the Cloud

HIPAA compliance in the cloud is a continuous state, not a certificate. Infrastructure changes daily, ePHI spreads, permissions widen, and a configuration that passed last quarter’s audit can drift out of compliance by lunchtime. Proving HIPAA continuously means three things running all the time: knowing where ePHI is, knowing whether the controls on it still hold, and knowing which exposures actually reach the data.

This is the slice a security platform owns, and it is worth being precise: compliance is never something you buy. A tool cannot make you HIPAA compliant, but it can give you the visibility and evidence that the part you are responsible for is actually in place. That is the role Orca plays.

The Orca Cloud Security Platform uses agentless SideScanning™ to inventory a full cloud estate without deploying agents, then locates ePHI across it, including the copies in dev, test, and forgotten buckets that manual inventories miss. As a cloud-native application protection platform, it maps cloud posture to the HIPAA Security Rule, flags drift and misconfiguration as they appear, and uses attack path analysis to show which exposures, like a public workload with a path to a PHI datastore, an auditor and an attacker would both care about first. Because it prioritizes by exploitability and blast radius rather than raw severity, your team works the exposures to ePHI that matter, and keeps audit-ready evidence across AWS, Azure, and Google Cloud in one place.

Maintaining HIPAA Compliance in the Cloud

HIPAA in the cloud comes down to one division of labor: the provider secures the platform under a BAA, and you secure and prove everything you run on it. The Security Rule technical safeguards in §164.312 translate into concrete cloud controls, the checklist sequences them, and the work that never ends is proving they still hold as your environment changes. That continuous assurance, locating ePHI, detecting drift, and surfacing the real exposures to patient data, is the part you own.

To see how agentless, full-stack context locates ePHI and maps your cloud posture to the HIPAA Security Rule, get a demo.

Frequently asked questions about HIPAA Compliance in the Cloud