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

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.

Business Associate Agreements for cloud providers

Before any ePHI enters a cloud account, a covered entity or business associate must execute a HIPAA-compliant BAA 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 compliant BAA must contain, 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.

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, 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.

Reference architecture for a HIPAA-compliant health SaaS

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 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.

This page summarizes the mapping; for the implementation-level detail, use our 45 CFR 164.312 technical safeguards checklist. Teams pursuing multiple frameworks at once can map HIPAA controls to SOC 2 and 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.

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.

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 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: 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.