# HIPAA for SaaS and Cloud-Hosted Health Apps: Architecture, BAAs, and ePHI Controls

> cloud architecture for HIPAA safeguards: why AWS, Azure & GCP are business associates even in no-view setups, the conduit exception, BAAs, and ePHI controls under 45 CFR 164.312.

- Canonical: https://auditsuisse.com/hipaa-for-saas-and-cloud-hosted-health-apps
- Language: en
- Author: Sébastien Ruosch, CPA — Director of Audits
- Published: 2026-02-22
- Updated: 2026-10-18

HIPAA

A CPA firm's guide to cloud architecture for HIPAA safeguards — when your cloud provider becomes a business associate, why the conduit and “no-view” myths fail, and how to map ePHI controls to 45 CFR 164.312.

 The short answer

Any cloud provider — AWS, Microsoft Azure, or Google Cloud — that **creates, receives, maintains, or transmits electronic protected health information (ePHI)** on your behalf is a HIPAA **business associate** and must sign a Business Associate Agreement (BAA). Per **HHS OCR Guidance on HIPAA & Cloud Computing (2016)** and FAQ 2075, this is true *even in a “no-view” arrangement* where the provider only holds encrypted ePHI and has no decryption key. Encryption reduces breach risk; it does not remove the BAA obligation.

## Key takeaways

- **No-view is still a business associate.** Holding only encrypted ePHI with no key does not exempt a cloud provider — OCR is explicit that a no-view CSP is a business associate and needs a BAA.
- **The conduit exception does not cover storage.** It applies only to pure transmission (ISP, postal carrier) with transient, incidental storage — any CSP that *maintains* ePHI is a business associate.
- **A signed BAA is necessary but not sufficient.** Under the shared responsibility model, you still own IAM, encryption configuration, logging, and application-layer ePHI handling.
- **Encryption is not an exemption from HIPAA.** Encryption at rest (AES-256) and in transit (TLS 1.2+) is an *addressable* Security Rule specification today and the basis of the separate breach safe harbor — but the December 2024 NPRM proposes making it mandatory (proposed, not finalized as of July 2026).

## When does HIPAA apply to a cloud SaaS? Covered entity vs business associate

HIPAA reaches two kinds of organizations. A **covered entity** is a health plan, healthcare clearinghouse, or a healthcare provider that transmits health information electronically. A **business associate** is any person or entity that creates, receives, maintains, or transmits protected health information on a covered entity's behalf — the definition lives at **45 CFR 160.103**. Most healthtech SaaS companies are business associates; the cloud providers beneath them are business associates too (technically subcontractors, which HIPAA also treats as business associates).

The trigger is **electronic protected health information (ePHI)**: individually identifiable health information in electronic form. If your application stores, processes, or moves ePHI — patient records, claims, lab results, appointment data tied to an identifiable person — HIPAA's Privacy Rule, Security Rule, and Breach Notification Rule apply to you, and the infrastructure you build on inherits obligations through the chain of BAAs.

### The “no-view” myth — why encryption without the key does not exempt a cloud provider

The single most decisive fact for this topic, and the one buyers and engineers most often get wrong: **a cloud service provider that stores or processes ePHI is a business associate even when it cannot view the data** because the data is encrypted and the provider holds no decryption key. HHS OCR states plainly in its *Guidance on HIPAA & Cloud Computing* that “lacking an encryption key does not exempt a CSP from business associate status.” A no-view provider still maintains ePHI, so a BAA is required and the CSP carries HIPAA obligations for the data it holds.

### The conduit exception, precisely

The **conduit exception** is real but narrow. It applies only to entities whose *sole* function is transmitting ePHI, where any storage is transient and incident to the transmission — the classic examples OCR gives are the US Postal Service, courier services, and internet service providers. OCR addresses this directly in FAQ 2077 (“Can a CSP be considered a conduit like the postal service?”) and in the 2013 Omnibus Rule preamble (78 FR 5566). A cloud provider that *maintains* (stores) ePHI — even briefly for processing — is a business associate, not a conduit.

Conduit exception vs business associate — when a BAA is needed

| Service type | Example | Stores ePHI? | Conduit exception applies? | BAA needed? |
| --- | --- | --- | --- | --- |
| Pure transmission | ISP, postal/courier carrier | Transient only | Yes | No |
| Cloud storage (object/block) | Amazon S3, Azure Blob, Google Cloud Storage | Yes | No | Yes |
| Managed database / compute | Amazon RDS, Azure SQL, GCE/Compute | Yes | No | Yes |
| No-view encrypted storage | Provider holds ciphertext, no key | Yes | No | Yes |
| De-identified data only | Data meeting 45 CFR 164.514(b) | Not ePHI | N/A | No |

## Business Associate Agreements for cloud providers

Before any ePHI enters a cloud account, a covered entity or business associate must execute a BAA addressing HIPAA requirements with the provider. The required *content* of that contract is set primarily by **45 CFR 164.504(e)** (the Privacy Rule business-associate contract provisions) and **45 CFR 164.314(a)** (the Security Rule contract requirements). A related but distinct citation, **45 CFR 164.308(b)**, is the *standard* requiring you to have such a contract in place; the specific clauses that must appear live in 164.314(a)(2) and 164.504(e)(2). Conflating the two is a common mistake.

The chain does not stop at your direct provider. Any subcontractor that handles ePHI on the CSP's behalf must be bound by a downstream (subcontractor) BAA, and your own subprocessors need one from you. For the full clause-by-clause breakdown of [what a BAA must contain under HIPAA](https://auditsuisse.com/hipaa-business-associate-agreements-explained), including permitted uses, breach reporting, subcontractor flow-down, and return-or-destroy obligations, see our dedicated BAA guide — this page keeps the focus on architecture rather than duplicating that contract detail.

## Choosing a HIPAA-eligible cloud: AWS vs Azure vs Google Cloud

All three major hyperscalers will sign a BAA and support HIPAA workloads — but a BAA with a major cloud provider is **account-wide yet only covers designated HIPAA-eligible services**. ePHI must never be placed in a non-eligible service, and eligibility has to be validated at the **service, feature, and region level**. Vendor eligibility lists drift constantly, so treat the tables below as a routing guide and always confirm against the live vendor page before you deploy.

AWS vs Azure vs Google Cloud for HIPAA (verify service lists against live vendor pages; as of July 2026)

| Provider | Signs a BAA? | How the BAA is executed | Scope model | Example eligible services | Audit-log service |
| --- | --- | --- | --- | --- | --- |
| AWS | Yes | Self-service BAA accepted via AWS Artifact; account-wide | Only designated HIPAA-eligible services (large, frequently updated list) | EC2, S3, RDS, EKS, Lambda, KMS | AWS CloudTrail |
| Microsoft Azure | Yes | BAA/HITRUST terms via the Microsoft Online Services Terms / DPA | Broad set of in-scope services listed in the Microsoft Trust Center | Virtual Machines, Blob Storage, Azure SQL, AKS, Key Vault | Azure Monitor / Activity Log |
| Google Cloud | Yes | Accept the Google Cloud BAA in the admin console; covers a defined Covered Products list | Only Covered Products enumerated by Google | Compute Engine, Cloud Storage, Cloud SQL, GKE, Cloud KMS | Cloud Audit Logs |

Counts of eligible services (AWS, for instance, lists a large and growing set) change often, so this guide deliberately does not hardcode a number — consult the [AWS HIPAA Eligible Services Reference](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/), Google's Covered Products list, and the Microsoft Trust Center at the moment you architect. Common traps sit in serverless and managed-data tiers: some preview features, edge/consumer services, and specific AI or analytics features are explicitly excluded even when the parent service is eligible. Confirm that every Lambda/Cloud Function, managed database, and queue in your ePHI path is in scope before it touches patient data.

## The shared responsibility model — who is responsible for what

A signed BAA is the beginning, not the end. Under the **shared responsibility model**, the provider is responsible for security *of* the cloud — physical facilities, host hardware, and the hypervisor — while you are responsible for security *in* the cloud: identity, encryption configuration, network controls, logging, and how your application handles ePHI. The most common HIPAA failure in cloud SaaS is assuming the BAA transfers those customer-side duties. It does not.

Shared responsibility split for a HIPAA cloud workload

| Layer | Cloud provider responsibility | Customer responsibility | Common failure |
| --- | --- | --- | --- |
| Physical / facility | Data-center security, power, media destruction | None | Assuming physical evidence is the customer's to produce |
| Host / hypervisor | Patching host, isolating tenants at the hardware layer | Patching guest OS and runtime | Unpatched guest images running ePHI workloads |
| Network | Backbone, DDoS protection at the edge | VPC/subnet design, security groups, TLS enforcement | Open security groups exposing ePHI endpoints |
| IAM | Identity platform availability | Least-privilege roles, MFA, key rotation | Over-broad admin roles and shared credentials |
| Encryption | KMS/HSM availability, encryption primitives | Enabling encryption, managing keys, scoping access | ePHI buckets or volumes left unencrypted |
| Application / ePHI handling | None | Access logic, minimum-necessary use, PHI in logs | ePHI written to application or debug logs |

## Reference architecture for a health SaaS designed around HIPAA safeguards

A defensible cloud architecture for ePHI is built from a handful of non-negotiable control domains. None of them is exotic — the discipline is in configuring them consistently across every in-scope service and proving it with evidence.

### Tenant isolation and multi-tenancy for ePHI

Multi-tenant SaaS must guarantee that one customer's ePHI can never be reached by another tenant. Whether you isolate by separate accounts/projects, by dedicated databases, or by row-level security with strictly scoped keys, the isolation boundary must be explicit, tested, and documented. Cross-tenant data leakage is treated as a reportable breach, so isolation is both a design and an evidence obligation.

### Encryption at rest and in transit

Encrypt ePHI at rest with **AES-256** and in transit with **TLS 1.2 or higher**, and manage keys through the provider's KMS/HSM (AWS KMS, Azure Key Vault, Google Cloud KMS) with rotation and tightly scoped grants. Encryption maps to the addressable specifications at 45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii), and — separately — underpins the breach-notification safe harbor discussed below.

### IAM, least privilege, and authentication (MFA)

Access to ePHI should follow least privilege and the HIPAA **minimum necessary standard**. Use role-based IAM, enforce **MFA** for all human access, eliminate long-lived shared credentials, and gate privileged operations behind just-in-time elevation. This satisfies the access-control and authentication requirements at 45 CFR 164.312(a)(1) and 164.312(d).

### Audit logging and monitoring

Enable immutable, tamper-evident logging of access to ePHI and administrative actions using **AWS CloudTrail**, **Google Cloud Audit Logs**, or **Azure Monitor**, forward logs to a protected, retention-controlled store, and alert on anomalous access. This is the technical basis for the audit-controls standard at 45 CFR 164.312(b). Independent [penetration testing to validate ePHI safeguards](https://auditsuisse.com/penetration-testing) supports the periodic technical evaluation expected under 45 CFR 164.308(a)(8).

### Backup, availability, and integrity controls

Maintain encrypted, tested backups and a documented recovery capability to meet the contingency-planning expectations of the administrative safeguards (45 CFR 164.308(a)(7)), and protect ePHI against improper alteration or destruction — checksums, versioning, and write-once storage — to satisfy the integrity standard at 45 CFR 164.312(c).

## Mapping HIPAA Security Rule technical safeguards (45 CFR 164.312) to cloud controls

The Security Rule technical safeguards at **45 CFR 164.312** are technology-neutral by design. The table below translates each standard into the concrete cloud service that implements it and the evidence an auditor will request. Note which specifications are **required** versus **addressable** — addressable does not mean optional; you must implement it or document why a reasonable equivalent alternative is appropriate.

45 CFR 164.312 technical safeguards mapped to cloud controls

| CFR citation | Safeguard (standard) | Required / Addressable | AWS | Azure | GCP | Evidence artifact |
| --- | --- | --- | --- | --- | --- | --- |
| 164.312(a)(1) | Access control | Required (standard) | IAM roles | Entra ID / RBAC | Cloud IAM | Role/permission export, access reviews |
| 164.312(a)(2)(iv) | Encryption & decryption | Addressable | KMS + S3/EBS encryption | Key Vault + SSE | Cloud KMS + CMEK | Encryption config, key policy |
| 164.312(b) | Audit controls | Required | CloudTrail | Azure Monitor | Cloud Audit Logs | Log samples, retention settings |
| 164.312(c) | Integrity | Required (with addressable spec) | S3 versioning / Object Lock | Immutable Blob storage | Object versioning / retention | Version history, checksum policy |
| 164.312(d) | Person/entity authentication | Required | IAM + MFA | Entra ID MFA | Cloud Identity MFA | MFA enforcement report |
| 164.312(e)(1) | Transmission security | Required | TLS 1.2+ / ACM | TLS 1.2+ / App Gateway | TLS 1.2+ / Load Balancing | TLS config, cipher policy |

This page summarizes the mapping; for the implementation-level detail, use our [45 CFR 164.312 technical safeguards checklist](https://auditsuisse.com/hipaa-technical-safeguards-checklist). Teams pursuing multiple frameworks at once can [map HIPAA controls to SOC 2 and GDPR](https://auditsuisse.com/multi-framework-control-mapping-soc2-hipaa-gdpr) to avoid duplicating evidence collection.

## What's changing: the December 2024 HIPAA Security Rule NPRM

On December 27, 2024, HHS OCR published a Notice of Proposed Rulemaking, “HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information” (Federal Register, January 6, 2025; comment period closed March 7, 2025). Its headline proposal is to **remove the “required” versus “addressable” distinction** and make measures such as encryption of ePHI at rest and in transit and multi-factor authentication effectively mandatory, with limited exceptions.

**Important status note: as of July 1, 2026, this NPRM is proposed, not finalized.** No final rule has been published. If and when a final rule issues, it may differ materially from the proposal, and OCR has signaled a compliance window (roughly 240 days after a final rule's effective date) rather than immediate enforcement. Architect toward the proposed baseline — encryption and MFA everywhere — because it is good practice today, but do not represent the NPRM's requirements as current law.

Encryption & access obligations: today vs the December 2024 NPRM (proposed)

| Control | Current Security Rule status | Dec 2024 NPRM proposed status | Practical action for SaaS teams |
| --- | --- | --- | --- |
| Encryption at rest (164.312(a)(2)(iv)) | Addressable | Effectively mandatory (limited exceptions) | Encrypt all ePHI stores with AES-256 now |
| Encryption in transit (164.312(e)(2)(ii)) | Addressable | Effectively mandatory | Enforce TLS 1.2+ end to end |
| Multi-factor authentication | Not explicitly required | Proposed as required | Enforce MFA on all human access today |
| Written risk analysis & asset inventory | Required (analysis); inventory implied | More prescriptive, explicit inventory/mapping | Maintain a current ePHI asset and data-flow inventory |

## Breach notification and the encryption safe harbor

Encryption plays a second, distinct role beyond the Security Rule. Under the **Breach Notification Rule (45 CFR 164.400–414)**, an impermissible use or disclosure of ePHI is presumed to be a reportable breach — *unless* the ePHI was “unsecured.” If ePHI is encrypted to the standard set out in the HHS *Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable* (tied to the definition of unsecured PHI at 45 CFR 164.402), the incident may fall within the **encryption safe harbor** and notification may not be required.

Two distinctions matter and are frequently conflated. First, the breach safe-harbor encryption (governed by 164.402 and the HHS guidance) is *not* the same as the Security Rule's addressable encryption specification (164.312(a)(2)(iv) / (e)(2)(ii)) — different rules, different purposes. Second, the encryption safe harbor is not **de-identification**; de-identified data under 45 CFR 164.514(b) is no longer PHI at all, whereas encrypted PHI is still PHI that simply may be exempt from breach notification.

A practical consequence for “no-view” cloud providers: a no-view CSP must still formally comply with the Breach Notification Rule, but if the affected ePHI is encrypted to the HHS standard, the incident may fall within the safe harbor and the CSP may not be required to report it to its customer. That does not change the CSP's business-associate status or its BAA. For how to operationalize detection and reporting, see our guide to [breach notification and incident response](https://auditsuisse.com/hipaa-incident-response-requirements).

## State law and HITRUST: what enterprise health buyers actually ask for

HIPAA is a floor, not a ceiling. Modern healthtech buyers increasingly face a stack of state statutes on top of it: **Texas HB 300** (a broader definition of “covered entity” and stricter training requirements than federal HIPAA), **Washington's My Health My Data Act** (consumer health data beyond HIPAA's scope, with a private right of action), and **California's CMIA**, among others. If your app serves users in these states, your risk analysis and contracts must account for the strictest applicable standard, not HIPAA alone.

On the framework side, the question hospital systems and payers actually ask in procurement is often “are you HITRUST certified?” The **HITRUST CSF** maps HIPAA, NIST, and state-law requirements into one assessable certification, and a HITRUST r2 certification has become a de-facto enterprise-procurement demand in healthcare. Positioned simply: HIPAA is the legal obligation, a [SOC 2 report for healthtech](https://auditsuisse.com/soc-2) proves your control environment to security teams, and HITRUST packages HIPAA-plus-more into a single certifiable assessment that large health enterprises recognize. Many teams run compliance-automation tooling for continuous monitoring — useful, but automation surfaces control status; it is not an independent opinion. An independent CPA audit is the validation layer above the tooling.

For the risk-analysis obligation itself (45 CFR 164.308(a)(1)(ii)(A)), the canonical free artifact is the joint ONC/OCR **Security Risk Assessment (SRA) Tool**, a wizard-based questionnaire, used alongside the HHS *Guidance on Risk Analysis*. Global health SaaS should also note the contrast in [GDPR data-residency vs HIPAA](https://auditsuisse.com/gdpr): GDPR constrains where EU personal data may go, while HIPAA imposes no residency mandate.

## Common architecture and compliance pitfalls in cloud health apps

The recurring failures we see in cloud health SaaS are rarely exotic zero-days; they are configuration and process gaps that surface fast under audit or after an incident.

- **ePHI in logs.** Debug, application, or access logs that capture patient identifiers turn a logging pipeline into an uncontrolled ePHI store. Scrub or tokenize before logging.
- **Non-eligible services.** Routing ePHI through a service or feature not on the provider's HIPAA-eligible list voids BAA coverage for that data path.
- **Missing subcontractor BAAs.** Subprocessors (email, analytics, error tracking, AI APIs) that see ePHI without a downstream BAA break the chain required by 45 CFR 164.308(b).
- **Over-broad IAM.** Wildcard admin roles and shared credentials defeat least privilege and make access reviews meaningless.
- **Unencrypted dev/staging data.** Copying production ePHI into unencrypted or open test environments is one of the most common breach sources.
- **No documented risk analysis.** The absence of a current 164.308(a)(1)(ii)(A) risk analysis is among the most frequently cited findings in OCR enforcement — and one of the most preventable.

These are not theoretical. OCR has repeatedly entered resolution agreements — carrying six- and seven-figure settlements — where the root cause was a missing or inadequate risk analysis or unencrypted ePHI, underscoring that documentation and encryption are enforcement realities, not paperwork.

## HIPAA cloud readiness checklist: evidence an auditor will request

- Executed BAA with each CSP, plus a register of subcontractor/downstream BAAs.
- Inventory confirming every ePHI-touching service, feature, and region is HIPAA-eligible.
- Encryption configuration for data at rest (AES-256) and in transit (TLS 1.2+), plus KMS key policies.
- IAM role/permission exports, MFA enforcement report, and dated access reviews.
- Audit-log samples (CloudTrail / Cloud Audit Logs / Azure Monitor) with retention settings.
- Current written risk analysis (164.308(a)(1)(ii)(A)) and risk-management plan.
- Tested backup/recovery evidence and integrity controls (versioning, object lock).
- Documentation of state-law overlays (e.g., TX HB 300, WA MHMDA) where applicable.

## Frequently asked questions

### Is a cloud provider like AWS, Azure, or Google Cloud a HIPAA business associate?

Yes. Under HHS OCR guidance, any cloud provider that creates, receives, maintains, or transmits electronic PHI on your behalf is a HIPAA business associate and must sign a Business Associate Agreement. This holds even in no-view setups where the provider only holds encrypted data and has no decryption key.

### Does encrypting ePHI mean my cloud vendor doesn't need a BAA?

No. OCR is explicit that lacking an encryption key does not exempt a cloud service provider from business associate status. Encryption can reduce breach-notification risk through the safe harbor, but it does not remove the vendor's HIPAA obligations, so a signed BAA is still required.

### Does the HIPAA conduit exception apply to cloud storage?

No. The conduit exception is narrow and covers only pure transmission with transient, incidental storage, like an ISP or postal carrier (OCR FAQ 2077). A cloud provider that maintains or stores ePHI is a business associate, not a conduit, and a BAA is required.

### Do I need a BAA with AWS, Azure, or GCP, and does it cover every service?

You must execute the provider's BAA before putting PHI in the cloud. The BAA is account-wide but only covers each vendor's designated HIPAA-eligible services; PHI must never touch non-eligible services, so validate eligibility at the service, feature, and region level.

### What does the shared responsibility model mean for HIPAA?

The cloud provider secures the infrastructure — physical, host, hypervisor — while you remain responsible for security in the cloud: IAM least privilege, encryption configuration, network controls, audit logging, and application-layer ePHI handling. A BAA alone does not establish that your app meets HIPAA requirements.

### What are the HIPAA technical safeguards for ePHI in the cloud?

Under 45 CFR 164.312 you must implement access control, audit controls, integrity, person or entity authentication, and transmission security. In practice that maps to IAM least privilege, encryption at rest and in transit (AES-256, TLS 1.2+), immutable audit logs, and MFA across in-scope cloud services.

### Can I store ePHI outside the United States under HIPAA?

HIPAA imposes no data-residency requirement, so offshore storage is permitted, but OCR advises that cross-border storage can raise risks you must document in your risk analysis and mitigate. Unlike GDPR, HIPAA does not restrict location, though customer contracts often do.

## Sources & further reading

1. HHS OCR — [Guidance on HIPAA & Cloud Computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html) (business associate status, no-view services, conduit exception; FAQ 2075 & 2077).
2. eCFR — [45 CFR 164.312, Technical safeguards](https://www.ecfr.gov/current/title-45/section-164.312); and [45 CFR Part 164](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164) (164.504(e), 164.314(a), 164.402, 164.514(b)).
3. Federal Register — [HIPAA Security Rule NPRM (Dec 2024 / Jan 6 2025)](https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information) — proposed, not finalized as of July 2026.
4. AWS — [HIPAA Eligible Services Reference](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) (verify service/feature/region eligibility at deployment time).

 Continue Reading

## Related Resources

 [### HIPAA BAAs Explained When you need a Business Associate Agreement and what it must contain. Read More →](https://auditsuisse.com/hipaa-business-associate-agreements-explained) [### HIPAA Technical Safeguards Checklist A practical checklist for implementing HIPAA technical safeguard requirements. Read More →](https://auditsuisse.com/hipaa-technical-safeguards-checklist) [### Multi-Framework Control Mapping Map controls across SOC 2, HIPAA, and GDPR to reduce duplicate effort. Read More →](https://auditsuisse.com/multi-framework-control-mapping-soc2-hipaa-gdpr)

---
Source: https://auditsuisse.com/hipaa-for-saas-and-cloud-hosted-health-apps · This Markdown edition is generated from the same content as the HTML page.