HIPAA Compliance for Cloud Storage

Key Takeaways:

• HIPAA’s Security Rule defines five technical safeguard families at 45 CFR 164.312; encryption and audit controls are the two that auditors test most often, and both are configuration work the customer owns, not the provider.
• Hardware-based controls (Trusted Execution Environments, confidential computing, HSMs) address the one data state software encryption cannot reach: data in use while a processor reads it.
• A signed Business Associate Agreement is a prerequisite, not a compliance outcome. AWS, Azure, and GCP all offer BAAs self-service, but each covers only a defined list of eligible services.
• HHS’s proposed 2026 Security Rule update would eliminate the “addressable” distinction, mandate MFA and encryption, require biannual vulnerability scans and annual penetration testing, and add a 72-hour restoration standard.
• Most audit findings come from missing evidence that a control operated, not from a missing control.

The healthcare sector recorded more than 700 data breach incidents in 2024, exposing over 275 million patient records, according to BleepingComputer. That is more incidents than any other industry, including finance. The breaches that drive those numbers mostly did not defeat encryption. They exploited configuration: an over-permissive identity role, an unencrypted backup, a storage bucket left public.

That distinction is the whole argument for treating cloud HIPAA compliance as an engineering problem rather than a documentation exercise. This guide maps the Security Rule’s technical safeguard requirements to concrete cloud controls, covers the hardware-based options that protect data while it is being processed, and lays out what audit preparation actually looks like.

What the HIPAA Security Rule Requires in Cloud Environments

The HIPAA Security Rule requires covered entities and their business associates to protect the confidentiality, integrity, and availability of electronic protected health information using administrative, physical, and technical controls, as AWS describes on its HIPAA compliance page. The rule predates cloud computing by years, so the work is translation: mapping each requirement to a service configuration you can show.

There is no HIPAA certification for a cloud service provider. AWS states this directly, noting that it aligns its HIPAA risk management program with FedRAMP and NIST 800-53 because those are higher standards that map to the Security Rule. NIST published SP 800-66 as a resource guide documenting how NIST 800-53 controls align to HIPAA, which is why most cloud compliance programs start from a NIST baseline and map outward.

Historically, the rule split implementation specifications into “required” and “addressable.” Addressable did not mean optional, but in practice many organizations documented why a control was not reasonable and moved on. HHS proposed eliminating that distinction in December 2024, and the proposed rule would also add concrete timelines: vulnerability scanning at least every six months, penetration testing at least once every 12 months, mandatory MFA, mandatory network segmentation, and annual written verification that business associates have implemented required safeguards, as TechTarget reported. HHS estimated first-year compliance costs across the sector at approximately $9 billion, with $6 billion per year in years two through five.

The proposed rule’s status remains unsettled. It was issued near the end of the Biden administration, and the final rule has been moved to HHS’s long-term agenda. The practical guidance from attorneys quoted in that coverage is to comply with the rule as currently written while building toward the proposed requirements, because data mapping and asset inventories produce value whether or not the rule is finalized.

Mapping HIPAA Technical Safeguards to Cloud Controls

The Security Rule’s technical safeguards live at 45 CFR 164.312 and break into five families. Each one translates into a specific cloud configuration, and each produces specific evidence an auditor will request.

Two of these deserve emphasis because they fail most often. Access control fails when MFA is enforced for human administrators but not for service accounts, or when a debugging role is broadened and never reverted. Transmission security fails when external APIs are encrypted but database connections and service-to-service traffic inside the VPC are not, on the assumption that internal networks are trusted. In a multi-tenant cloud, that assumption does not hold.

Encryption at rest sits at 164.312(a)(2)(iv) and encryption in transit at 164.312(e)(2)(ii). Both were addressable specifications under the original rule, which is why the proposed update making them mandatory matters. Our guide to data encryption best practices covers the algorithm selection and key management mechanics that sit underneath these two requirements.

Hardware-Based Security: TEEs and Confidential Computing

Encryption at rest protects stored data. Encryption in transit protects data moving across a network. Neither protects data while a processor reads it, because the application must decrypt before it can compute. That gap is where confidential computing applies.

Confidential computing creates secure enclaves using hardware-based Trusted Execution Environments. Inside an enclave, data is encrypted while being accessed, processed, or modified, and it is isolated from the operating system, the hypervisor, the cloud provider’s staff, and other tenants on the same physical host, as TechTarget’s overview of confidential computing use cases explains. Common TEE implementations include Intel SGX, AMD SEV, and Arm TrustZone.

The HIPAA relevance is direct. When a covered entity moves ePHI into a public cloud, it relies on the provider’s assurances about hypervisor and firmware security without verifiable guarantees. A TEE converts that reliance into something the customer can attest to cryptographically. Google Cloud’s Confidential VMs are one implementation, and Intel and Google Cloud announced general availability of confidential computing instances based on 4th Gen Intel Xeon processors across multiple service regions, as SiliconAngle reported.

The trade-offs are real and should shape where you deploy this. Enclave memory is limited, which makes TEEs better suited to bounded workloads such as key operations, authentication, and specific inference tasks than to large-scale analytics. Confidential computing also adds attestation and orchestration overhead. Treat it as a control for the highest-sensitivity processing paths rather than a blanket replacement for encryption at rest and in transit.

Hardware security modules are the second hardware control, and they matter more for HIPAA compliance than TEEs do today. An HSM provides a tamper-resistant root of trust where key material cannot be extracted, which is what makes a claim of “encrypted at rest” defensible when the threat model includes the cloud provider itself. Our enterprise key management guide covers the HSM deployment patterns and the cost gap between software-backed and hardware-backed key custody.

Encryption Standards and Key Management

AES-256 is the accepted standard for ePHI at rest, and the proposed 2026 rule language names AES-256 or equivalent explicitly. All three major cloud providers support AES-256 at rest and TLS 1.2 or higher in transit across their HIPAA-eligible services, according to PlatOps’ provider comparison. The compliance risk is rarely the algorithm. It is whether encryption is enabled on every environment, including backups and non-production systems.

Key management is the part that determines whether encryption holds up. The recurring failure is storing keys alongside the data they protect, which makes the encryption irrelevant to an attacker who compromises the system. Keys belong in a dedicated key management service or HSM, separated from data by account boundaries and access policies.

Three patterns cover most deployments. Provider-managed keys with no customer hardware are cheapest and fastest but weakest on custody. A custom key store routes the provider’s KMS API through your own HSM cluster, preserving the managed control plane while moving the root of trust. A fully external configuration keeps key material outside the provider entirely and exposes only cryptographic operations, which is the strongest model and the most operationally demanding because you now own the availability of every decrypt operation.

Cloud Provider HIPAA Offerings: AWS, Azure, and GCP

All three major providers offer BAAs to any customer without negotiation, and the process is self-service in each case. AWS BAA acceptance happens through AWS Artifact in the management console. Google Cloud’s BAA is available through its console. Microsoft’s BAA is embedded in its Online Services Terms and managed through the Microsoft Service Trust Portal.

Source: PlatOps’ AWS vs GCP vs Azure HIPAA comparison.

The eligible-service list is where the differences bite. If a service is not on a provider’s covered list, it cannot be used to process or store PHI, and there is no configuration change that fixes that. AWS’s notable gaps include Amazon Connect for contact centers, which matters for telehealth deployments, and AWS Amplify public hosting. Google Workspace is covered under a separate BAA from GCP infrastructure. Azure OpenAI Service falls under separate enterprise agreement terms rather than the standard BAA.

Azure’s built-in HIPAA compliance dashboard in Defender for Cloud is a genuine operational advantage for teams that need continuous posture visibility, because AWS and GCP require more configuration to reach equivalent monitoring. Google Cloud leads on healthcare data interoperability through its Cloud Healthcare API, which handles FHIR, HL7v2, and DICOM natively within a HIPAA-eligible managed service. AWS has the deepest overall service catalog and the largest pool of engineers who already know the platform.

BAA Requirements and the 2026 Rule Changes

A Business Associate Agreement is a contract defining how a cloud provider may create, receive, maintain, or transmit ePHI on behalf of a covered entity. It sets permitted uses and disclosures, establishes safeguard commitments, mandates breach notification, cascades obligations to subcontractors, and defines data return and destruction on termination, as Accountable HQ’s cloud BAA checklist outlines.

Cloud providers almost always qualify as business associates when they store or process ePHI, even if the content is encrypted and the provider never views it. The narrow “conduit” exception rarely applies to cloud platforms because data is typically retained, processed, or logged. This is why the BAA is a prerequisite rather than a formality.

The most common misunderstanding is what a signed BAA accomplishes. It makes the provider a compliant business associate. It does not make your application compliant. A BAA does not make your storage buckets private, enable encryption on your databases, or implement access logging. Those remain customer configuration tasks.

The proposed 2026 rule would tighten BAA content requirements specifically. Generic safeguard language would no longer suffice; contracts would need to detail MFA for ePHI system access, biannual vulnerability scans with documented remediation, annual penetration testing with tracked fixes, 72-hour recovery capability for critical operations, 24-hour incident notification to covered entities, and annual written verification of implemented safeguards. Covered entities would also need to actively verify business associate compliance rather than relying on the signature, a “trust but verify” model that places ongoing oversight responsibility on the practice.

Audit Preparation Timeline and Common Findings

Audits fail in the evidence room. The most common finding is not a missing control but missing proof that a control operated during the audit period. A team that rotated keys on schedule but cannot produce rotation logs fails the same way as a team that never rotated.

A realistic preparation sequence for a mid-sized organization with two cloud environments runs about 18 weeks:

• Weeks 1-3, inventory and data mapping. Enumerate every system that creates, receives, maintains, or transmits ePHI. Build the asset inventory and network map the proposed rule would require. Effort: 40-60 analyst hours.
• Weeks 3-6, gap assessment. Map current configurations against the five technical safeguard families at 164.312. Output a control matrix with pass, fail, and partial status for each specification.
• Weeks 6-12, remediation. Enable encryption on every environment including backups and non-production. Enforce MFA on all administrative and service access. Tighten IAM policies to least privilege. Turn on audit logging in every region and ship logs to write-protected storage. This phase consumes the most engineering time.
• Weeks 10-14, evidence collection. Gather configuration screenshots, log samples, access review records, and policy documents organized by control ID rather than by date. This phase is consistently underestimated and routinely consumes 60-100 hours.
• Weeks 14-18, readiness review. Have someone outside the compliance team walk the control matrix and challenge each piece of evidence. A dry-run surfaces the gaps an auditor will find anyway, but on your timeline.

Two habits separate teams that pass cleanly from teams that scramble. The first is continuous evidence collection: capturing configuration exports and access logs monthly rather than in a 30-day crunch before the audit. The second is treating the BAA as an entry point into vendor oversight rather than the end of it. Request current SOC 2 Type II reports and HIPAA attestations from each provider on a defined cadence, track their service advisories, and verify that any subcontractor touching ePHI has equivalent controls in place.

For the broader control-mapping work that lets one evidence set satisfy multiple frameworks, see our guide to enterprise compliance standards, which crosswalks HIPAA citations against SOC 2, ISO 27001, and NIST CSF. The segmentation controls that reduce HIPAA audit scope are covered in our analysis of network segmentation, and the cloud misconfiguration patterns that drive most breach incidents are detailed in our review of cloud security posture management.

The through-line across all of it is that HIPAA compliance in the cloud is a configuration and evidence discipline. The frameworks tell you what to build. The provider gives you the hardware, the eligible services, and the BAA. What remains, and what auditors actually examine, is whether you turned the controls on, kept them on, and can prove it.

Related Reading

More in-depth coverage from this blog on closely related topics:

• What is Zero Trust Network Access
• Best Practices for Data Encryption in 2026
• Enterprise Compliance Standards
• Enterprise Key Management Strategies

Sources and References

Sources cited while researching and writing this article:

• 275M patient records breached, How to meet HIPAA password manager requirements
• HIPAA Compliance – Amazon Web Services (AWS)
• 3 things to know about proposed HIPAA Security Rule updates
• 6 confidential computing use cases that secure data in use
• Intel and Google Cloud launch confidential computing instances powered by 4th Gen Xeon processors
• AWS vs GCP vs Azure: Which is Best for HIPAA? | PlatOps
• Cloud BAA Requirements: HIPAA Checklist for Cloud Service Providers