You want the same analytics and machine learning as every other team, but your data includes protected health information (PHI). That changes how you build. Safeguards have to sit in the architecture from day one, because adding private networking or access rules to a live platform later means rework and downtime. This checklist walks through what a HIPAA-aligned platform on Azure and Databricks needs, area by area.

This guide is general information, not legal advice. Bring your compliance and legal teams in early and keep them involved as the platform grows.

What does HIPAA require from a data platform?

HIPAA doesn’t name technologies. The Security Rule asks for administrative, physical and technical safeguards that protect the confidentiality, integrity and availability of PHI. For a cloud data platform, that comes down to six areas: contracts, security controls, access, audit, de-identification and written procedures. The checklist follows that order.

Contracts and scope

• Sign a BAA with every provider. Every cloud and software service that stores or processes PHI needs a business associate agreement.

• Use only covered services. A BAA lists specific services. Keep PHI workloads on those and nothing else.

• Cover your partners. Any development or support partner that may see PHI signs a BAA too.

• Map the data flow. Write down where PHI enters, where it’s stored, where it’s transformed and where it leaves.

Security safeguards

• Encrypt data in transit with TLS and at rest, with customer-managed keys where your policy requires them.

• Use private networking and private endpoints so no data service is reachable from the public internet.

• Enforce single sign-on and multi-factor authentication through your identity provider.

• Separate development, test and production. PHI lives in production only.

• Patch and harden compute, and limit who can create or change clusters.

What this looks like in a real build

We built a HIPAA-aligned data intelligence platform on Azure and Databricks for a U.S. nonprofit in human services. When we started, data scientists worked in local environments with no shared, governed place to collaborate. That’s slow, and it’s risky when the data is PHI.

We followed Databricks’ Security Reference Architecture and built a fully private Azure environment: hub-and-spoke networking, private endpoints, private DNS and VPN-only access with no public exposure. Unity Catalog took over governance, lineage and permissions, and Pulumi defined the infrastructure as code so every environment could be rebuilt the same way. The result was a shared, governed workspace for data scientists and engineers, and machine learning models running in production in the cloud.

The lesson we’d pass on: settle the network and identity model before the first pipeline. Once nothing is publicly exposed and every permission runs through one catalog, each new use case starts on safe ground instead of reopening the security discussion.

Access control and minimum necessary

• Grant access by role, through groups, never to individual users.

• Apply row-level and column-level security so people see only the data their job needs.

• Mask or tokenise direct identifiers for analysts who don’t need them.

• Review access on a fixed schedule and remove it as soon as someone changes role or leaves.

Most analytics questions don’t need names or record numbers. Start from that assumption and the group of people with access to identifiable data stays small, and so does the scope of every audit.

Audit and monitoring

• Log every access to PHI, including queries, exports and admin changes.

• Send logs to a central, tamper-resistant store with a defined retention period.

• Alert on unusual activity, such as large exports or access outside working hours.

• Track lineage so you know which reports and models use PHI.

Logs nobody reads don’t protect anything. Name a person who reviews alerts every week, and keep a record that they did.

De-identification for analytics and AI

• Build de-identified datasets for broad analytics, research and model training.

• Use the HIPAA Safe Harbor method or an expert determination, and record which one you used.

• Store re-identification keys separately, with tight control over who can use them.

• Test machine learning and AI outputs to make sure they don’t reveal PHI.

Policies and procedures

• Run and document a security risk assessment, and repeat it regularly and after major changes.

• Keep an incident response and breach notification procedure, and test it.

• Train everyone who works on the platform in handling PHI.

• Document backups, disaster recovery and data retention.

Who is responsible for what?

Azure and Databricks secure the platform. You and your partner secure how it’s configured and used. The provider gives you the tools, and switching them on and checking them is your job.

Moving healthcare data off a legacy system? Pair this list with our data platform migration checklist. If you’re still picking a partner, read how to choose a Databricks consulting partner.

How RUBICON helps with HIPAA-aligned data platforms

We design and build data platforms that handle PHI on Azure and Databricks, from private networking and Unity Catalog governance to MLOps pipelines and training for your team. RUBICON has about 55 people, 40+ of them engineers, and is ISO 27001:2022 certified, a Databricks Partner and a Microsoft Solutions Partner for Cloud & AI Platforms. See our healthcare work and data engineering services.

If you’re planning a platform with health data, our architects can walk through your setup with you.

Frequently asked questions