---
title: "Er Supabase HIPAA-kompatibelt? Hvad en BAA overlader til dig"
description: "Supabase underskriver en BAA på Team-planen med HIPAA-tilkøbet. Ti pligter forbliver dine, fra PITR til forbindelseslog. Hvilke et gratis tjek kan se."
url: "https://madsalt.tech/da/blog/is-supabase-hipaa-compliant/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/da/about/"
language: "da"
published: 2026-11-03
---

# Er Supabase HIPAA-kompatibelt? Hvad en BAA overlader til dig

TL;DR

Ja, hostet Supabase kan rumme sundhedsdata: det underskriver en Business Associate Agreement (BAA) på Team-planen og opefter, når HIPAA-tilkøbet er slået til. Selvhostet Supabase er ikke dækket. BAA'en konfigurerer ikke dit projekt. Supabases model for delt ansvar angiver ti pligter, der forbliver dine, blandt andet point-in-time recovery, krav om SSL, netværksbegrænsninger og logning af Postgres-forbindelser. Af de ti markerer mit gratis Supabase-tjek 3 direkte, 2 kun delvist og kan ikke se de øvrige 5.

Jeg er Denys, fullstack- og AI-ingeniør, og de fleste apps, jeg bygger eller retter, kører på Supabase. Når en sundheds- eller wellness-app spørger, om den kan bruge Supabase, har det ærlige svar to dele: hvad Supabase underskriver, og hvad du selv skal slå til. Denne artikel tager dem i den rækkefølge, ud fra Supabases egne dokumenter, læst 29. oktober 2026.

## Er Supabase HIPAA-kompatibelt?

Den hostede platform er. Supabases [HIPAA-guide](https://supabase.com/docs/guides/security/hipaa-compliance) siger, at Supabase optræder som business associate for kunder, der håndterer Protected Health Information (PHI), har indgået BAA'er med sine egne leverandører, der kan nå disse data, som AWS, og får sine HIPAA-kontroller auditeret hvert år i samme auditperiode som SOC 2. HIPAA-projekter får også alle de SOC 2-kontroller, resten af platformen har.

Guiden nævner to begrænsninger. Selvhostet Supabase får ikke disse kontroller ud af boksen, og HIPAA-compliance er dér en sag mellem dig og din auditor. Og BAA'en dækker kun Supabases del: guiden angiver dit ansvar som at følge HIPAA's Privacy-, Security- og Breach Notification-regler, at underskrive BAA'en og at konfigurere dine HIPAA-projekter, som Security Advisor anviser.

## Hvad skal du have på plads, før du gemmer PHI?

Fra [siden om HIPAA-projekter](https://supabase.com/docs/guides/platform/hipaa-projects) og [modellen for delt ansvar](https://supabase.com/docs/guides/deployment/shared-responsibility-model):

1. **Team-planen eller højere.** BAA'en findes ikke under den.
2. **HIPAA-tilkøbet og en underskrevet BAA.** Du anmoder Supabase om begge; tilkøbet aktiveres på organisationen.
3. **High Compliance på hvert projekt.** Når tilkøbet er slået til, kan et projekt markeres som High Compliance i General Project Settings. Derefter kører Supabase løbende ekstra kontroller på projektet, og en ikke-kompatibel indstilling vises som en advarsel i Security Advisor.

Security Advisor advarer; den retter ikke. Supabases guide er ligefrem om det: ansvaret for at anvende de anbefalede kontroller ligger hos kunden.

## Hvilke indstillinger kræver et HIPAA-projekt?

Her er hele listen fra modellen for delt ansvar, med hvor hver enkelt bor, og om det gratis [Supabase sikkerhedstjek](https://madsalt.tech/da/tools/supabase-security-check/) kan se den. Tjekket læser et projekt gennem Supabases Management API, efter du har logget ind med Supabase, så det ser indstillinger, ikke kontrakter.

| Din pligt under BAA'en                            | Hvor den bor                                               | Gratis tjek                                                          |
| ------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------- |
| Underskriv BAA'en, Team-planen eller højere       | Kontrakt med Supabase                                      | Kan ikke se den                                                      |
| Marker projekter som HIPAA, ret advisor-advarsler | General Project Settings, Security Advisor                 | Delvist: viser hver Security Advisor-lint, det modtager              |
| MFA på hver Supabase-konto, gennemtvunget         | Organisationsindstillinger                                 | Kan ikke se den                                                      |
| Point-in-time recovery (PITR)                     | Database → Backups, kræver et lille compute-tilkøb         | Delvist: består med daglige backups alene                            |
| Krav om SSL                                       | Database Settings → SSL Configuration                      | Markerer den: "SSL not enforced on database connections"             |
| Netværksbegrænsninger                             | Database Settings → Network Restrictions                   | Markerer den: "Database open to every IP address"                    |
| Logning af Postgres-forbindelser slået til        | `log_connections`, som standard slået fra på nye projekter | Kan ikke se den                                                      |
| Kryptering efter HIPAA Security Rule              | Supabase krypterer i hvile og under transport              | Kan ikke se den; kryptering på applikationsniveau er dit valg        |
| Ingen PHI i offentlige Storage-buckets            | Storage → bucket-indstillinger                             | Markerer hver offentlig bucket; om den rummer PHI, må du selv afgøre |
| Ingen overførsel til en ikke-HIPAA-organisation   | Projektoverførsel                                          | Kan ikke se den                                                      |

![Supabases 10 HIPAA-pligter: hvad et gratis tjek ser. Pligter fra Supabases model for delt ansvar. Markeret af en tjekregel: 3; Kun delvist set: 2; Ikke synligt for tjekket: 5.](https://madsalt.tech/charts/da/is-supabase-hipaa-compliant.svg)

*Figur 1. Supabases model for delt ansvar, læst 29. oktober 2026, holdt op mod reglerne i mit gratis Supabase-tjek.*

## Hvad overser det gratis tjek?

Tre huller er værd at sige højt, fordi et grønt resultat kan læses som mere, end det er.

**Daglige backups er ikke PITR.** Tjekkets backup-regel består, når projektet har point-in-time recovery eller mindst én backup. Et betalt projekt med daglige backups og uden PITR består den. HIPAA-projekter kræver netop PITR, så se selv på Database → Backups; PITR kræver mindst det lille compute-tilkøb. Hvad hver plan gemmer, og en gendannelsestest, står i Supabase backups.

**To forskellige MFA-indstillinger.** Tjekkets "No multi-factor method enabled" handler om din apps brugere: om Supabase Auth tilbyder dem en anden faktor. HIPAA-pligten handler om dem, der kan åbne dit Supabase-dashboard: MFA på hver konto i organisationen, gennemtvunget som krav. Du vil have begge, og de slås til forskellige steder.

**Forbindelseslog.** Supabase sætter `log_connections` til slået fra på nye projekter, og HIPAA-projekter bør holde den slået til af hensyn til revisionssporet. Tjekket har ingen regel, der læser den. I SQL-editoren besvarer `show log_connections;` det på én linje, og Security Advisor advarer om det på et High Compliance-projekt.

Tjekket viser hver lint, Security Advisor returnerer, både fejl og advarsler. Jeg har ikke kørt det på et High Compliance-projekt, så jeg kan ikke bekræfte, at HIPAA-advarslerne kommer i samme liste. Læs dem i dashboardet under alle omstændigheder.

## Hvad HIPAA-indstillinger ikke dækker

Ingen af de ti pligter nævner Row Level Security. Et HIPAA-projekt med alle indstillingerne ovenfor på plads kan stadig udlevere en patienttabel til enhver med den offentlige nøgle, hvis tabellen har RLS slået fra eller en policy, der tillader hver række. Det er den del, tjekket læser fuldt ud: rettigheder, policies, funktioner der omgår RLS og følsomt udseende kolonner, der kan læses af anonyme besøgende. Forskellen på de to nøgler står i [Supabase anon key vs service role key](https://madsalt.tech/da/blog/supabase-anon-key-vs-service-role-key/), og hvordan jeg beviser hver enkelt rettighed mod API'et står i [sådan tester du Supabase RLS](https://madsalt.tech/da/blog/how-to-test-supabase-rls/).

Det samme gælder alt uden for Supabase. Modellen for delt ansvar lægger tredjepartstjenester på dig: SMTP- og SMS-udbydere, OAuth-login og enhver ekstern API, som en Edge Function eller en database-trigger kalder. Hvis en af dem modtager PHI, er den en del af dit HIPAA-billede, ikke Supabases, så tjek, om hver udbyder underskriver en BAA, før data når den.

## Hvordan tjekker du dit projekt?

1. Bekræft i dashboardet, at organisationen har HIPAA-tilkøbet, og at projektet er markeret som High Compliance. Åbn derefter Security Advisor og gå hver advarsel igennem.
2. Åbn Database → Backups og bekræft, at PITR er slået til, ikke kun daglige backups.
3. Kør `show log_connections;` i SQL-editoren. Den skal returnere `on`.
4. Bekræft i organisationsindstillingerne, at hvert medlem har MFA, og at MFA er et krav.
5. Kør det gratis [Supabase sikkerhedstjek](https://madsalt.tech/da/tools/supabase-security-check/) for SSL, netværksbegrænsninger, offentlige buckets og adgangsreglerne ovenfor. Min note om offentlige buckets viser, hvordan du flytter filer til signerede URL'er.

For det bredere spørgsmål om, hvad platformen garanterer, og hvad den ikke gør, se [er Supabase sikkert?](https://madsalt.tech/da/blog/is-supabase-secure/). Denne artikel er ikke juridisk rådgivning; din compliance-ansvarlige eller auditor afgør, hvad din BAA og dit HIPAA-program kræver.

Bygger du en sundhedsapp på Supabase?

Jeg kigger gerne på dine projektindstillinger og udveksler erfaringer. Ingen salgstale.

[Kontakt mig](https://madsalt.tech/da/#contact)
