HIPAA compliance in the cloud is a shared responsibility problem

At a glance

What this is: This is an analysis of how HIPAA compliance changes in cloud environments, with the key finding that BAAs cover the platform, but configuration and evidence remain the customer’s responsibility.

Why it matters: It matters because IAM, logging, encryption, and data discovery decisions in cloud programmes now determine whether ePHI is actually protected and defensible at audit time.

👉 Read Orca Security's guide to HIPAA compliance in the cloud

Context

HIPAA compliance in the cloud is really a control-evidence problem. Once ePHI moves into AWS, Azure, or Google Cloud, the question is not whether the provider is covered by a BAA. The question is whether your IAM, encryption, logging, and discovery controls actually keep ePHI protected wherever it lives.

The cloud breaks the assumptions behind one-time compliance checks. Identities multiply, workloads are ephemeral, and ePHI can spread into analytics, backups, dev/test, and forgotten storage. That makes HIPAA governance a continuous visibility exercise, not a paperwork exercise.

Key questions

Q: How should security teams govern ePHI in cloud environments?

A: They should treat ePHI as a continuously governed data class, not a static asset. That means mapping every storage location, scoping IAM to minimum necessary access, enforcing encryption with customer-controlled keys, and retaining audit evidence for each service that can touch PHI. A BAA helps define responsibility, but governance only holds when the customer controls the configuration.

Q: Why do BAAs not make a cloud environment HIPAA compliant by themselves?

A: Because a BAA only defines the provider’s obligations for the platform it runs. It does not secure the customer’s IAM roles, public exposure, logging gaps, or data sprawl. HIPAA compliance depends on how ePHI is configured, monitored, and proven in the customer environment, which is where most cloud violations occur.

Q: What breaks when cloud teams cannot find all copies of ePHI?

A: Every control becomes partial. You cannot encrypt, restrict, log, or monitor data you have not discovered, so hidden copies in backups, analytics, dev/test, and abandoned storage create blind spots. In practice, incomplete discovery means the organisation may be compliant on paper while still exposing PHI operationally.

Q: Who is accountable when ePHI is exposed in a cloud breach?

A: The provider may be accountable for its platform obligations under the BAA, but the organisation remains accountable for its own configuration, access model, and monitoring. HIPAA responsibility does not transfer to the cloud vendor. If the exposure came from mis-scoped permissions, public storage, or missing controls, the customer owns that failure.

Technical breakdown

Shared responsibility and the BAA boundary

The shared responsibility model separates platform security from customer configuration. Under HIPAA, the cloud provider can be a business associate and still leave the customer responsible for access scope, encryption choices, logging, and data handling above the platform layer. A BAA is necessary because it defines legal accountability for the provider’s part, but it does not secure public buckets, over-permissive roles, or unmonitored PHI exports. That is why cloud HIPAA failures are usually control failures, not contract failures.

Practical implication: map each ePHI control to the party that must operate it, then verify that customer-owned controls have evidence, not assumptions.

Access control, audit controls, and least privilege for ePHI

HIPAA’s technical safeguards translate cleanly into cloud IAM, but cloud estates make them harder to sustain. Unique identities, scoped permissions, MFA, and audit logging all apply, yet entitlement sprawl can gradually widen who can reach PHI data stores. Audit controls matter because HIPAA expects the system to record and examine access, not just retain logs somewhere. Least privilege therefore becomes a living governance problem across roles, service accounts, and data paths.

Practical implication: continuously review who can reach ePHI, and treat privilege drift as a compliance issue, not just an access hygiene issue.

Encryption, integrity, and transmission security in cloud services

HIPAA’s encryption and transmission requirements are especially important in the cloud because properly encrypted ePHI can fall under breach safe-harbor treatment. That makes key control, not just encryption status, the decisive factor. At rest, storage, backups, and snapshots all need protection. In transit, service-to-service traffic needs TLS even inside private networks if PHI moves there. Integrity controls such as versioning, immutability, and tamper-evident logging protect against silent corruption or deletion after access is gained.

Practical implication: standardise encryption with customer-controlled keys and pair it with integrity monitoring across every ePHI-bearing service.

Threat narrative

Attacker objective: The objective is to reach protected health information in a form that is usable, exposed, or reportable, while bypassing the evidence trail that should prove it was controlled.

1. Entry occurs when ePHI is placed into cloud services that are eligible under a BAA but not yet properly configured for HIPAA safeguards, leaving access paths, logs, or storage exposures in place.
2. Escalation happens when identity scope expands through over-permissive roles, shared access patterns, or uncontrolled data copies, allowing more systems and users to reach PHI than intended.
3. Impact is a reportable breach, audit failure, or prolonged exposure of unsecured ePHI that the organisation cannot prove was protected end to end.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

HIPAA cloud compliance is fundamentally a visibility and accountability problem, not a checkbox problem. The cloud provider can cover infrastructure, but it cannot prove your customer-side IAM, encryption, and logging decisions are fit for ePHI. That is why the compliance burden remains on the organisation that defines access and data placement. Practitioners should treat every cloud service that can touch ePHI as a governed control surface, not a purchased assurance.

Identity scope creep is the hidden compliance failure mode in cloud HIPAA programmes. Once roles, service accounts, and workload permissions expand across accounts and services, the minimum-necessary principle becomes difficult to enforce in practice. This is where access reviews often lag reality. Practitioners should assume that any PHI-bearing environment will drift unless entitlement growth is continuously checked against actual data exposure.

Data discovery is the named concept this topic keeps returning to: ePHI cannot be governed if it cannot be found. Cloud estates make PHI portable, copyable, and easy to strand in secondary systems such as analytics, backups, and test environments. The implication is not just better inventory, but a governance model that assumes hidden copies exist until proven otherwise. Practitioners should build compliance around discoverability, not around assumed placement.

HIPAA’s breach logic makes encryption with key control the decisive line between exposure and reportability. If ePHI is encrypted properly and the keys are governed separately, the organisation may avoid the most damaging notification outcomes after an incident. That does not eliminate operational risk, but it changes the regulatory impact profile materially. Practitioners should therefore make key ownership and key lifecycle part of the compliance model, not a background implementation detail.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• The same study found that 46% of organisations confirmed a non-human identity breach, while 26% only suspected one.
• That pattern points to the next governance problem in cloud HIPAA programmes, which is moving from assumed control coverage to continuously proven control coverage.

What this signals

Data discovery will become the deciding control for cloud compliance programmes. The more ePHI spreads into secondary stores, the less useful annual attestations become. Teams that cannot continuously locate PHI will struggle to defend access, encryption, and logging claims when environments change faster than review cycles can keep up.

The governance gap is widening because cloud identity systems can expand faster than compliance evidence. That means security teams should expect access reviews, not just technical hardening, to become a primary audit pressure point in healthcare cloud estates.

Practical HIPAA maturity now depends on connecting identity, data, and evidence. Organisations that can show who can reach ePHI, where that data lives, and whether the control state is current will have a defensible programme. Those that cannot will keep discovering gaps only after exposure or audit challenge.

For practitioners

• Map ePHI to every cloud service that touches it Build a live inventory of storage, databases, backups, analytics jobs, and logs that can contain ePHI. Reconcile that inventory against your HIPAA control map so every location has an identified owner, encryption state, and logging path.
• Tighten identity scope around PHI-bearing workloads Eliminate shared access, remove wildcard permissions, and review roles and service accounts that can reach PHI data stores. Use access reviews to catch entitlement drift before it becomes a compliance finding.
• Standardise encryption with customer-controlled keys Enable encryption at rest and in transit for every PHI-bearing service, then separate key administration from data access. This matters most for backups, snapshots, and copied datasets that are often overlooked in audits.
• Make audit evidence continuously current Turn on control-plane and data-plane logging, protect logs from tampering, and verify that monitoring is actually reviewing access to ePHI. Stale logs are not evidence of compliance.
• Search for hidden ePHI copies before the audit does Look for PHI in dev, test, file shares, exports, and abandoned cloud storage. If discovery is incomplete, every downstream control is partly blind.

Key takeaways

• HIPAA in the cloud fails most often at the customer configuration layer, not at the provider contract layer.
• Discovery, access scope, and encryption key control are the controls that determine whether ePHI is actually protected.
• Continuous evidence matters because cloud compliance drifts as fast as cloud identities and data copies do.

Key terms

• Electronic Protected Health Information: Electronic protected health information is patient health data stored or transmitted in digital form that HIPAA requires organisations to protect. In cloud environments, ePHI can appear in primary databases, backups, logs, exports, and analytics systems, so governance must follow the data across every copy and service boundary.
• Business Associate Agreement: A Business Associate Agreement is the contract that defines how a cloud provider or other vendor must protect PHI on behalf of a covered entity. It assigns legal responsibility for the provider’s platform obligations, but it does not remove the customer’s duty to configure access, logging, encryption, and monitoring correctly.
• Minimum Necessary Principle: The minimum necessary principle requires access to PHI to be limited to the smallest amount needed for a job or task. In cloud systems, that principle is enforced through IAM design, scoped permissions, and ongoing access review, because over-broad roles quickly become a compliance and exposure problem.
• Shared Responsibility Model: The shared responsibility model divides cloud security between the provider and the customer. For HIPAA, the provider secures the platform and the customer secures the configuration, identity, and data handling layers, which is why compliance can fail even when the provider’s infrastructure is contractually covered.

What's in the full article

Orca Security's full article covers the operational detail this post intentionally leaves for the source:

• Platform-by-platform HIPAA eligibility guidance for AWS, Azure, and Google Cloud services that can store or process ePHI
• Step-by-step cloud compliance checklist covering BAAs, encryption, logging, access controls, and continuous monitoring
• Detailed mapping of HIPAA Security Rule requirements to concrete cloud settings and configuration examples
• Operational guidance on maintaining audit-ready evidence across multi-cloud environments

👉 Orca Security's full article covers cloud-specific controls, checklist steps, and audit evidence guidance for ePHI.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.