# Data lakehouse compliance guide for regulated industries: HIPAA, FedRAMP and GDPR

> An engineering review guide for regulated lakehouses, separating HIPAA, FedRAMP and GDPR responsibilities and evidence.

Source: https://hyperlake.cloud/blog/data-lakehouse-compliance-guide-for-regulated-industries-hipaa-fedramp-and-gdpr
By Hyperlake Team · Hyperlake

No storage format or platform logo makes a data lakehouse compliant. Data lakehouse compliance comes from controls, contracts and operating evidence that fit the data and your organisation's obligations. Map the whole workload, work out which requirements apply and give each control an owner before you treat the system as ready for regulated use.

HIPAA, FedRAMP and GDPR cover different scopes and put responsibility in different places. Treat this guide as a way to organise an engineering review. It doesn't certify a deployment, and it can't stand in for a qualified assessment of the requirements that apply to you.

![A data lakehouse protected by three shields labelled HIPAA, FedRAMP and GDPR, with access, audit and encryption controls.](https://hyperlake.cloud/blog/img/production/3f506915093449a1c5cbb746d080db8f5a2e7688-1200x840.png?w=1600&fit=max&auto=format)

## What belongs in a lakehouse compliance review?

More than people expect. Ingestion, object storage, catalogs, query engines, notebooks, exports, backups and admin interfaces all go in. Running AI on top? Add embeddings, retrieval stores, prompts, outputs, model services and traces.

For each component, write down which data it touches and who can reach it. Even a component that holds only metadata can leak something sensitive, or weaken the security of the whole system.

The unusual paths count as much as normal use. Support access, incident response, recovery and that "temporary" debugging export never show up on a clean production diagram, and every one of them moves data.

## How do HIPAA, FedRAMP and GDPR differ?

| Framework | Starting question | Evidence the technical team should prepare |
| --- | --- | --- |
| HIPAA | Does the organisation and processing involve applicable HIPAA responsibilities? | ePHI flows, service relationships, risk analysis inputs and safeguards |
| FedRAMP | Is the agency's cloud-service use in scope, and what offering is being used? | Exact service, configuration, relevant assessment material and agency responsibilities |
| GDPR | What personal-data processing and roles are involved? | Purpose, data categories, access, retention, rights and transfer arrangements |

One technical control can support several obligations at once. Keep the legal reasoning and the approval process for each explicit all the same, because meeting one framework doesn't mean you've met the others.

## What should a HIPAA review examine?

[HHS guidance on cloud computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html) explains that cloud providers handling ePHI on behalf of a covered entity or business associate can have business-associate responsibilities, including where the provider lacks a decryption key. The relevant agreements and a risk analysis are still on you.

What the lakehouse team owes is a precise account of where ePHI is created, received, stored and transmitted, with the service providers named and each party's responsibilities spelled out. Encryption helps. It doesn't cover availability, administrative safeguards or the full risk picture on its own.

Sit down with your privacy, security and legal teams and go through the real service configuration. "This provider supports healthcare customers" is a sales line, not an assessment of the workload you're deploying.

## What should a FedRAMP review examine?

[FedRAMP's scope guidance](https://www.fedramp.gov/2026/scope/) puts the agency's use case at the centre of the scope decision. Its [guidance on using a certified cloud service](https://www.fedramp.gov/2026/agencies/use/) separates reusable service evidence from the agency's authorisation of its own system.

Pin down the exact cloud service offering and its configuration. Coverage can't be read off a provider's other products or a loosely worded marketing page. Confirm which integrations and customer-operated controls are part of the intended use.

Next, prepare the architecture and responsibility map the agency needs in order to decide. Does someone want to add an external model endpoint, a monitoring service or a support tool? That's a reason to review the arrangement again, not a harmless convenience.

## What should a GDPR review examine?

Start from the [official GDPR text](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) and your organisation's legal assessment, which tell you what applies to your processing. Engineering should be able to explain purpose, data categories, parties, retention and access without hunting for it.

Build for the individual-rights processes that apply. When a record is corrected or removed, which derived tables, indexes and other copies need the same treatment? Keep that process in line with approved retention and legal requirements.

The [EDPB's transfer guidance](https://www.edpb.europa.eu/documents/guideline/guidelines-052021-on-the-interplay-between-the-application-of-article-3-and-the_en) is a useful reference for cross-border arrangements. Look at recipients and access paths, not just where data sits; a bucket in the right region doesn't settle the review by itself.

## What should an access-control review cover?

Begin with ordinary users, service accounts and administrators. Who can query data, change permissions, export records or alter audit collection? Look at direct access as well as access through applications.

Aim for least privilege that fits the job, and give temporary access a process: who approves it, when it expires and how its use gets reviewed. It has to hold up during an incident, because that's exactly when people want to skip the normal controls.

Then check the evidence the system really produces. An audit record helps only if it captures the relevant event, is kept for the right period and ties back to an identity and an action.

## What does open-table storage change?

A table format like [Apache Iceberg](https://iceberg.apache.org/docs/latest/) can be part of the architecture, but it isn't a compliance programme. Several engines plus historical data states raise operational questions that you have to answer on purpose.

Take access first. How is it enforced across every engine that can read the data? A restriction applied in one query service may do nothing for a user with direct object-storage access.

Then deletion. Define what retention and deletion mean for data files, metadata, snapshots and backups, follow the approved policy, and be ready to show exactly what a deletion or correction changes.

## How should you evaluate platform claims?

Databricks, Snowflake, Microsoft Fabric, AWS, Google Cloud, Cloudera and IBM watsonx.data may all come up in regulated-industry platform discussions. Each product family includes different services and deployment options, so ask for evidence about the exact offering and configuration you'd use.

Separate provider controls from customer controls. The provider may run the infrastructure while you define access, classify data and approve AI integrations. Our view is that the gaps tend to sit in shared responsibilities that have no named customer owner.

HyperLake supports modular data and AI in customer environments with integrated access-policy components, which can support a control design. We're not claiming any blanket HIPAA, FedRAMP or GDPR certification here. Your deployment and operating practices need their own assessment.

## What should you rehearse before production?

Run through an access denial, a restore, a correction or deletion request, and an incident involving a failed or misconfigured component. Rehearsals flush out fuzzy responsibilities and data copies nobody documented.

Test the AI path on its own. A query restriction means little if the retrieval service uses a broader service account and hands restricted content back through a model response.

Write down what happened and what's still open. A failed rehearsal is useful evidence for fixing the design, so don't bury it under a statement that the platform has security features.

## How do you keep a lakehouse compliant over time?

Treat changes to data sources, engines, model endpoints and operator access as review triggers. A system can drift a long way from its approved design while the product name stays the same.

For each requirement, keep a control owner, an evidence location and a review process. Records should be usable enough that an operator can find the right procedure mid-incident.

The target is controls you can explain and demonstrate year after year, which takes ongoing operation and review. A procurement questionnaire that went well is only the start.

## Frequently asked questions

### Is a lakehouse automatically compliant if its cloud provider is?

No. The exact service scope, configuration, customer responsibilities and application behaviour all count. You have to review the whole workload against the obligations that apply.

### Does encryption remove HIPAA business-associate questions?

It doesn't. HHS guidance explains that handling encrypted ePHI can still create business-associate responsibilities, so the parties and services still need a proper assessment and agreements.

### Does FedRAMP status replace agency authorisation?

No. FedRAMP service evidence feeds the agency's decision, but the agency is still responsible for authorising its own system and intended use.

### What's a common lakehouse control gap?

Policy enforced on one query path while another path stays wider than intended. Direct object-storage access and AI retrieval accounts are the usual culprits, which is why every access route needs reviewing.

## Related reading

- [Sovereign AI requirements](https://hyperlake.cloud/answers/what-is-sovereign-ai)
- [Open lakehouse components](https://hyperlake.cloud/answers/open-source-data-lakehouse-stack)