HIPAA in the Cloud: CSP Rules, BAAs, Shared Responsibility

Yes. OCR's guidance addresses this exact scenario: a CSP maintaining encrypted ePHI without the decryption key is still a business associate, because it maintains the data, and encryption does not remove its obligations to safeguard availability and integrity (ransomware and deletion threaten encrypted data too). The 'no-view' posture matters commercially, it can narrow the CSP's Privacy Rule exposure, but it does not eliminate business associate status or the BAA requirement. The conduit exception stays confined to pure transmission services. Any storage or compute vendor claiming it does not need a BAA because 'we cannot read the data' is wrong on the guidance's plain text.

Each hyperscaler signs a standard BAA covering a specific service list: AWS publishes HIPAA-eligible services (most core compute, storage, database, and networking services qualify); Microsoft covers in-scope Azure and Microsoft 365 services through its Business Associate provisions in the Product Terms/DPA; Google Cloud maintains a covered-services list for its BAA. Two operational rules follow: ePHI may only touch services on the list, so architecture review must check every component (including logging, queuing, and AI services) against it; and eligibility is not compliance, an eligible service misconfigured with public access is a breach in an approved wrapper. Keep the signed BAA and the service list snapshot with your vendor file.

The CSP is responsible for the security of the cloud: physical facilities, hypervisor, host infrastructure, and the services' own engineering, and its BAA covers breach reporting for incidents on its side. The customer is responsible for security in the cloud, which maps to most of the Security Rule: access management and MFA, network segmentation, encryption configuration and key management, audit logging and review, backup and contingency, workforce access, and integrations. In practice nearly every cloud ePHI breach, unsecured S3 buckets, exposed Elasticsearch and MongoDB instances, over-broad service accounts, sits on the customer side of the line. Write the split into your risk analysis so responsibilities have owners.

You need it contractually, and the standard BAAs provide it in different depths. Access, amendment, and accounting requests remain the covered entity's duty; the BAA obliges the CSP to make ePHI available, which practically means your architecture, not a support ticket, must be able to retrieve and export a patient's records. For audits, OCR can examine business associates directly, and your own diligence file should hold the CSP's third-party attestations (SOC 2 Type II, ISO 27001, HITRUST) since hyperscalers do not accept individual customer audits. Where PHI leaves the platform through marketplace add-ons or SaaS layered on IaaS, each additional vendor needs its own BAA, the chain does not stop at the infrastructure layer.

Asset inventory of every cloud account, region, and service touching ePHI; the eligible-services check; configuration baseline against CIS benchmarks or the provider's HIPAA reference architectures; IAM review (least privilege, MFA, no shared root); encryption at rest and in transit with key ownership documented; logging (CloudTrail/Azure Monitor/Cloud Audit Logs) enabled, retained, and actually reviewed per 164.308(a)(1)(ii)(D); backup and disaster recovery tested against the contingency plan standard; and misconfiguration monitoring (CSPM tooling or provider-native posture services). OCR's investigations after cloud breaches ask for exactly these artifacts, and the absence of logging review is a recurring aggravator.