HIPAA on Databricks and Snowflake: how to run protected health data on a cloud platform

Healthcare organisations move to Databricks and Snowflake for the same reasons as everyone else: scale, cost and AI. The difference is protected health information (PHI). Under HIPAA, the platform holding it, and the way you configure that platform, become part of your compliance posture.

Not legal advice. Confirm your obligations with your privacy and compliance team.

What the Security Rule asks of a data platform

The HIPAA Security Rule’s technical safeguards map directly onto platform configuration:

Safeguard	What it means on a data platform
Access control	Unique user IDs (no shared logins), least-privilege roles, emergency access procedure, automatic session timeout, encryption
Audit controls	Logs of who accessed which PHI and when, retained and reviewed
Integrity	Protection against improper change or deletion: versioned tables, backups, change controls
Person or entity authentication	Single sign-on with multi-factor authentication for people, managed credentials for services
Transmission security	TLS for data in transit, private connectivity where possible

The administrative and physical safeguards (risk analysis, workforce training, facility controls) still apply; the cloud provider covers some physical controls, and the BAA defines who does what.

HHS proposed significant updates to the Security Rule in January 2025, including making more safeguards explicitly required. Check the current status before designing to it.

Before you load PHI: platform requirements

Databricks

• Sign a business associate agreement with Databricks.
• Enable the compliance security profile on every workspace that processes PHI. It turns on hardened compute images, enhanced monitoring and other controls, and restricts you to supported compute types and regions.
• Use Unity Catalog for permissions, row filters and column masks, so access rules are defined once and apply across SQL, notebooks and AI tools.

Snowflake

• Use Business Critical edition or higher, which Snowflake requires for PHI, and sign a BAA.
• Apply masking policies to identifier columns and row access policies where access depends on facility, region or care team.
• Restrict access with network policies and private connectivity, and use access history for audit.

On both, encrypt with keys you manage if your policy requires it, and keep audit logs in a place the platform administrators cannot alter.

De-identify for analytics and AI

Most analytics, BI and AI use cases do not need to know who the patient is. HIPAA offers two de-identification methods:

• Safe Harbor: remove all 18 listed identifier types (names, most geographic detail below state level, dates other than year, contact details, record numbers and so on), with no actual knowledge that the rest could identify someone.
• Expert Determination: a qualified expert applies statistical methods and documents that the risk of re-identification is very small. This can keep more analytic value, for example dates shifted rather than removed.

Build the de-identified zone as a pipeline output with its own tests, then point analysts, dashboards and AI tools at it. The identified zone stays small, with few users, which makes it much easier to protect and audit. For AI assistants, also make sure they query with the user’s identity, as covered in AI agents on governed data.

A checklist for healthcare data teams

1. Sign BAAs with the data platform and every other vendor that touches PHI.
2. Enable the platform’s HIPAA configuration: compliance security profile on Databricks, Business Critical edition on Snowflake.
3. Classify PHI columns and apply masking before users get access.
4. Use SSO with MFA and unique identities; no shared accounts.
5. Separate identified and de-identified zones; send analytics and AI to the de-identified one.
6. Log every PHI access and review the logs.
7. Test backups and restores, and document your risk analysis.

The short version

HIPAA on Databricks or Snowflake starts with a BAA and the platform’s HIPAA configuration, then depends on how you set up access, masking, audit and encryption. De-identify for analytics and AI so the identified PHI zone stays small. Our data quality and governance service helps healthcare teams put this in place.

Related: Databricks vs Snowflake for healthcare, RAG on enterprise data: keeping permissions intact, PCI DSS for data platforms and our healthcare and life sciences page.

Sources

• The Security Rule, U.S. Department of Health and Human Services
• Guidance on de-identification of protected health information, HHS
• HIPAA Security Rule notice of proposed rulemaking: fact sheet, HHS
• HIPAA on Databricks and compliance security profile, Databricks documentation
• Snowflake editions, Snowflake documentation

Further reading from other practitioners

• Databricks HIPAA compliance, Bacancy
• HIPAA compliance checklist, Relevant Software
• HIPAA compliance checklist for healthcare software development, MindInventory