HIPAA-Compliant Data Storage for Analytics Workloads

A signed business associate agreement (BAA) and a HIPAA-eligible warehouse settle less than most analytics teams assume. They cover the platform, while the protected health information (PHI) exposure OCR actually finds lives in the copies around it: connector caches, error payloads, CDC offsets, stale snapshots, and control-plane metadata. HIPAA-compliant storage for analytics is an inventory problem. You pass when you can show where every copy of a field value sits, what controls limit it, and how you verify that control over time.

TL;DR

• A BAA and a HIPAA-eligible platform set the contractual baseline; your risk analysis still has to prove the controls around them reduce risk.
• The current Security Rule treats encryption as Addressable and does not mandate multi-factor authentication (MFA); the January 2025 proposed rule would change both, but HHS has moved it to its long-term agenda.
• Snowflake gates PHI behind Business Critical, the Databricks compliance security profile cannot be removed, and Delta Lake time travel can keep pre-masking PHI in old snapshots.
• Dynamic masking and reversible tokens are access controls, so the underlying data remains PHI.
• Connector caches, error payloads, CDC offsets, and control-plane metadata can all hold PHI; inventory them as storage and keep them in-boundary or under BAA coverage.

Try Airbyte Flex

What Does HIPAA Actually Require of Your Analytics Storage?

HIPAA splits Security Rule specifications into Required and Addressable, and that split decides what you must build. Under § 164.306(d), you must assess whether each Addressable specification is reasonable for your environment, implement it when it is, and otherwise document why not and adopt an equivalent alternative where reasonable. Encryption sits on the Addressable side, and HHS confirms in its encryption guidance for covered entities that the current rule does not mandate it. Those decisions sit inside your broader data privacy compliance obligations.

Audit controls have no Addressable path. Section 164.312(b) is a standard with no implementation specifications beneath it, so the Security Rule's specification matrix lists it as Required. Every system holding electronic PHI (ePHI) must record activity, and § 164.308(a)(1)(ii)(D) requires you to review it.

HHS published the proposed Security Rule update, 90 FR 898, on January 6, 2025. It would make encryption at rest and in transit mandatory, require MFA, add an annual technology asset inventory, and remove the Required/Addressable distinction. HHS's latest regulatory agenda moved the proposal to long-term actions with July 2027 as the anticipated final action, so none of it is enforceable today. Build encryption and MFA anyway: attackers entered Change Healthcare through a Citrix portal that had no MFA.

The following table maps the current designations to the analytics storage controls they govern.

The designations tell you what to build. Where a vendor's responsibility ends and yours begins depends on the platform, and each one draws the line in a different place.

Which Analytics Platforms Are HIPAA-Eligible and What Do They Gate?

Every HIPAA-eligible analytics platform layers a configuration gate on top of its BAA and leaves specific items to your risk analysis. Your workload data-plane placement decides where the shared-responsibility line falls, because a SaaS warehouse and an in-boundary lakehouse draw it differently. Document that line before PHI enters the platform.

Snowflake requires a signed BAA before storing any PHI and supports PHI only on Business Critical Edition or higher. Data sharing does not carry that coverage with it: accounts that share HIPAA or Health Information Trust Alliance (HITRUST) data are responsible for signing BAAs with each other. Snowflake's documentation also does not say which regions support Business Critical accounts or whether replicating PHI needs extra contractual controls, which puts replication under your own data residency governance.

Databricks requires its compliance security profile for HIPAA workloads. On Amazon Web Services (AWS), the profile adds monitoring agents, a hardened compute image, and limits on which preview features may touch regulated data, and you need the AWS BAA alongside the Databricks BAA. On Azure, the profile has been required for HIPAA data since September 1, 2026. The change is permanent: a workspace that has processed regulated data cannot drop the profile, and reverting means deleting the workspace and building a new one. On Google Cloud, Databricks may store or process customer-defined fields such as workspace, compute, tag, job, and credential names outside the compliance boundary, so a job named after a patient cohort puts that name outside the perimeter you built.

The table below summarizes each platform's BAA path, gating condition, and what its vendor documentation leaves to you.

Each entry in the last column becomes a line in your risk analysis. The biggest open question on any of these platforms is what happens to PHI after it lands, which starts with where you de-identify it.

Where Should You De-Identify PHI in Your Pipeline?

De-identify at the processing layer with Safe Harbor or Expert Determination, and tokenize joinable keys at ingestion. Safe Harbor strips 18 identifiers by rule, which can remove month-level dates and sub-state geography that longitudinal analysis needs. Expert Determination preserves more useful fields in exchange for a formal disclosure-risk assessment, so choose by intended use, recipient, population, and documented re-identification risk rather than by habit.

Assess that risk against the population, not only the sample. El Emam and colleagues show that sample-level risk metrics can understate real risk when far fewer people in the population share the same quasi-identifiers. Apply differential privacy only to released aggregates, with composition accounting; NIST's final guidelines for evaluating differential privacy, published as SP 800-226 in March 2025, give you an evaluation framework.

Three techniques look like de-identification while leaving PHI in place, and each needs its own control.

Reversible Tokens Keep a Dataset in PHI Scope

Tokenize medical record numbers and member IDs at ingestion so joins work without exposing identifiers. Tokens your organization can reverse keep the dataset identifiable, so it remains PHI with Security Rule controls and breach notification attached. The re-identification code allowance in § 164.514(c) applies only when the code is not derived from the individual's information, and the mechanism is not disclosed. The vault holding the token map maintains PHI on your behalf, which makes a vendor running it a likely business associate, so scope it explicitly and decide whether it needs BAA coverage separate from the warehouse.

Dynamic Masking Controls Access Without De-Identifying

Dynamic data masking (DDM) is query-time access control, and the underlying storage still holds PHI. Masking does not stop a user with direct database access from running exhaustive queries that reconstruct pieces of the masked values. Record DDM as an access control in your risk analysis and keep the masked tables inside every Security Rule control.

Historical Snapshots Can Retain Pre-Masking Values

Test whether historical snapshots on Bronze tables retain pre-masking values after a Silver step removes them. Set VACUUM intervals and snapshot retention from that assessment, and evaluate Iceberg and Hudi snapshot retention separately. Your unified logging and lineage evidence needs to show where masking occurred.

Every one of these copies sits downstream of ingestion, and the ingestion layer creates PHI copies of its own before any masking runs.

How Do You Keep Your Ingestion Layer Inside the Compliance Perimeter?

Treat the ingestion tool as storage, because connector state can create another PHI copy. Any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate, so request the BAA on the first day of vendor evaluation. The same logic drives HIPAA hybrid deployment decisions about where processing runs.

Load design matters as much as vendor scope. In an Epic environment, the Clarity reporting database is populated by a nightly extract from the Chronicles production database, so choose full-refresh or CDC loads per table based on size and change volume. Three pipeline artifacts belong in the PHI inventory alongside the destination tables.

Transient Pipeline State Is Still a PHI Copy

Transient staging, error logs, connector caches, and vendor support access can each create or expose a copy, even when it exists only during pipeline execution. Add all four to the PHI inventory for every ETL pipeline, and define in your BAA how long PHI may persist in a connector cache, in line with your hybrid compliance practices.

CDC Offsets and Watermarks Can Carry Key Values

Inspect CDC offset and watermark storage as part of the same inventory. Test whether log positions and change buffers carry key values, and classify them as PHI-bearing when they do. A primary key that is a medical record number turns a cursor into a PHI field.

Control-Plane Metadata Needs Its Own Boundary Decision

Separating the control plane from the data plane lets orchestration, scheduling, and monitoring run outside the PHI environment while processing runs inside the boundary. Data-plane placement does not settle network transit or metadata, so treat each as a separate boundary decision. Classify every field sent to the control plane yourself, including credentials, job names, schema details, rejected values, and support access, and keep error payloads carrying rejected-row field values under BAA coverage or in-boundary.

Once the inventory is complete, the remaining work is proving it holds over time, which is what audit and lifecycle controls are for.

How Do You Prove Compliance Through Audit and Lifecycle Controls?

You prove compliance with continuous, behavior-based log review, six-year retention of required documentation, risk-based log retention, and documented key custody. Ad hoc review is a documented OCR violation pattern. In the Montefiore Medical Center case, OCR found the hospital failed to regularly review information system activity and did not record and examine activity across all systems containing ePHI.

At warehouse scale, use behavioral detection with alerts on bulk exports, off-hours access, and queries against patients outside a user's care team. Those alerts make routine review operational instead of an occasional manual exercise.

Attribution requires service-principal isolation controls so each audit row maps to one person or one single-purpose account. For keys, document custody, separate custodians from data owners, and log cryptographic operations and key-state changes.

Retain required compliance documentation for at least six years under the Security Rule, and set log-retention periods through your risk analysis and other applicable requirements. The rule does not require immutable log storage, though it remains a sound implementation choice. Together, these controls are your evidence that you reduced identified risks to a reasonable and appropriate level,as the standard § 164.308(a)(1)(ii)(B) sets.

How Does Airbyte Flex Keep PHI Inside Your Boundary?

Airbyte Flex runs as a hybrid control plane. Airbyte operates the control plane while the data plane, along with your records, credentials, keys, and compute, runs in your environment, though some metadata such as cursor and primary-key values sits in the control plane. For HIPAA workloads, that metadata belongs in the same classification exercise described above: where a primary key is a medical record number, treat it as PHI-bearing in your BAA review.

Flex runs the same 700+ connectors as every Airbyte deployment, on a platform that moves 26 billion records daily. It adds role-based access control (RBAC) and organization-level audit logging on supported paid tiers, for events such as connection, permission, and source changes. Those logs cover pipeline configuration, so query-level audit on the warehouse remains its own control.

Teams building healthcare data pipelines can inspect the open-source foundation behind the connectors and data movement engine, then validate connector behavior, access controls, and operating procedures for their own environment. The same replicated records are what an in-boundary retrieval stack indexes, so agent reads inherit the boundary and access controls the pipeline already enforces.

Where Should You Start?

Start your risk analysis at the first connector and walk downstream, classifying every artifact that holds a field value, including the error queue and the Bronze snapshot nobody vacuumed. The BAA covers the platform, and the inventory is what you show an auditor.

Airbyte supports that in-boundary approach through Airbyte Flex, which keeps the data plane, credentials, and compute in your environment with RBAC and audit logging for pipeline changes.

Get a demo to see how Flex fits your HIPAA analytics architecture.

Frequently Asked Questions

Can You Treat a Limited Data Set as De-Identified?

No. A limited data set removes direct identifiers but retains dates and general geography, so it remains PHI under the Privacy Rule. Disclosure requires a compliant data use agreement, and Security Rule controls still apply.

When Do You Need HSM-Backed Keys Instead of Software KMS?

No HIPAA rule requires hardware-backed keys. Choose hardware security module (HSM) custody when a contract or policy mandates it. Otherwise, document the software key management service (KMS) decision in the risk analysis, including custody separation and operation logging.

Does the Conduit Exception Cover Your ETL Vendor?

Usually not. The conduit exception covers transmission-only services, and most data integration platforms process, modify, or temporarily hold PHI during pipeline execution. Assume your ETL vendor is a business associate unless your legal and compliance review establishes otherwise.

Do You Need a BAA for a Vendor That Holds Only De-Identified Data?

No. A cloud service provider is not a business associate if it receives and maintains only information de-identified according to the Privacy Rule. De-identify before handoff so a downstream tool that never sees PHI does not need a BAA.