--- title: "Er Supabase HIPAA-kompatibelt? Hva BAA-en overlater til deg" description: "Supabase signerer en BAA på Team-planen med HIPAA-tillegget. Ti plikter blir dine, fra PITR til tilkoblingslogg. Hvilke en gratis sjekk kan se." url: "https://madsalt.tech/no/blog/is-supabase-hipaa-compliant/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/no/about/" language: "no" published: 2026-11-03 --- # Er Supabase HIPAA-kompatibelt? Hva BAA-en overlater til deg TL;DR Ja, driftet Supabase kan romme helsedata: det signerer en Business Associate Agreement (BAA) på Team-planen og oppover, når HIPAA-tillegget er slått på. Selvhostet Supabase er ikke dekket. BAA-en konfigurerer ikke prosjektet ditt. Supabases modell for delt ansvar lister ti plikter som blir hos deg, blant dem point-in-time recovery, krav om SSL, nettverksbegrensninger og logging av Postgres-tilkoblinger. Av de ti flagger den gratis Supabase-sjekken min 3 direkte, 2 bare delvis, og kan ikke se de 5 andre. Jeg er Denys, fullstack- og AI-ingeniør, og de fleste appene jeg bygger eller retter, kjører på Supabase. Når en helse- eller wellness-app spør om den kan bruke Supabase, har det ærlige svaret to deler: hva Supabase signerer, og hva du selv må slå på. Denne artikkelen tar dem i den rekkefølgen, fra Supabases egne dokumenter, lest 29. oktober 2026. ## Er Supabase HIPAA-kompatibelt? Den driftede plattformen er det. Supabases [HIPAA-guide](https://supabase.com/docs/guides/security/hipaa-compliance) sier at Supabase opptrer som business associate for kunder som håndterer Protected Health Information (PHI), har signert BAA-er med sine egne leverandører som kan nå disse dataene, som AWS, og får HIPAA-kontrollene sine revidert hvert år i samme revisjonsperiode som SOC 2. HIPAA-prosjekter får også alle SOC 2-kontrollene resten av plattformen har. To begrensninger står i samme guide. Selvhostet Supabase får ikke disse kontrollene ut av boksen, og HIPAA-samsvar er der en sak mellom deg og revisoren din. Og BAA-en dekker bare Supabases del: guiden lister ansvaret ditt som å følge HIPAAs Privacy-, Security- og Breach Notification-regler, å signere BAA-en og å konfigurere HIPAA-prosjektene dine slik Security Advisor sier. ## Hva trenger du før du lagrer PHI? Fra [siden om HIPAA-prosjekter](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øyere.** BAA-en er ikke tilgjengelig under den. 2. **HIPAA-tillegget og en signert BAA.** Du ber Supabase om begge; tillegget aktiveres på organisasjonen. 3. **High Compliance på hvert prosjekt.** Med tillegget på kan et prosjekt merkes som High Compliance i General Project Settings. Fra da av kjører Supabase ekstra kontroller på prosjektet fortløpende, og en innstilling som ikke samsvarer, dukker opp som en advarsel i Security Advisor. Security Advisor advarer; den fikser ikke. Supabases guide er rett fram om det: ansvaret for å ta i bruk de anbefalte kontrollene ligger hos kunden. ## Hvilke innstillinger trenger et HIPAA-prosjekt? Her er hele listen fra modellen for delt ansvar, med hvor hver enkelt bor og om den gratis [Supabase sikkerhetssjekken](https://madsalt.tech/no/tools/supabase-security-check/) kan se den. Sjekken leser et prosjekt gjennom Supabases Management API etter at du har logget inn med Supabase, så den ser innstillinger, ikke kontrakter. | Din plikt under BAA-en | Hvor den bor | Gratis sjekk | | ------------------------------------------------- | ---------------------------------------------------- | --------------------------------------------------------------------- | | Signer BAA-en, Team-planen eller høyere | Kontrakt med Supabase | Kan ikke se den | | Merk prosjekter som HIPAA, fiks advisor-advarsler | General Project Settings, Security Advisor | Delvis: viser hver Security Advisor-lint den mottar | | MFA på hver Supabase-konto, påkrevd | Organisasjonsinnstillinger | Kan ikke se den | | Point-in-time recovery (PITR) | Database → Backups, krever et lite compute-tillegg | Delvis: består med daglige sikkerhetskopier alene | | Krav om SSL | Database Settings → SSL Configuration | Flagger den: "SSL not enforced on database connections" | | Nettverksbegrensninger | Database Settings → Network Restrictions | Flagger den: "Database open to every IP address" | | Logging av Postgres-tilkoblinger på | `log_connections`, av som standard på nye prosjekter | Kan ikke se den | | Kryptering etter HIPAA Security Rule | Supabase krypterer i hvile og under overføring | Kan ikke se den; kryptering på applikasjonsnivå er ditt valg | | Ingen PHI i offentlige Storage-buckets | Storage → bucket-innstillinger | Flagger hver offentlige bucket; om den rommer PHI, må du selv avgjøre | | Ingen overføring til en ikke-HIPAA-organisasjon | Prosjektoverføring | Kan ikke se den | ![Supabases 10 HIPAA-plikter: hva en gratis sjekk ser. Plikter fra Supabases modell for delt ansvar. Flagget av en sjekkregel: 3; Bare delvis sett: 2; Ikke synlig for sjekken: 5.](https://madsalt.tech/charts/no/is-supabase-hipaa-compliant.svg) *Figur 1. Supabases modell for delt ansvar, lest 29. oktober 2026, mot reglene i den gratis Supabase-sjekken min.* ## Hva overser den gratis sjekken? Tre hull er verdt å si høyt, fordi et grønt resultat kan leses som mer enn det er. **Daglige sikkerhetskopier er ikke PITR.** Sjekkens regel for sikkerhetskopier består når prosjektet har point-in-time recovery eller minst én sikkerhetskopi. Et betalt prosjekt med daglige sikkerhetskopier og uten PITR består den. HIPAA-prosjekter trenger nettopp PITR, så se selv på Database → Backups; PITR krever minst det lille compute-tillegget. Hva hver plan beholder, og en restore-test, står i Supabase backups. **To ulike MFA-innstillinger.** Sjekkens "No multi-factor method enabled" gjelder brukerne i appen din: om Supabase Auth tilbyr dem en andre faktor. HIPAA-plikten gjelder de som kan åpne Supabase-dashbordet ditt: MFA på hver konto i organisasjonen, håndhevet som krav. Du vil ha begge, og de slås på forskjellige steder. **Tilkoblingslogg.** Supabase setter `log_connections` til av på nye prosjekter, og HIPAA-prosjekter bør ha den på for revisjonssporet. Sjekken har ingen regel som leser den. I SQL-editoren svarer `show log_connections;` på det i én linje, og Security Advisor advarer om det på et High Compliance-prosjekt. Sjekken viser hver lint Security Advisor returnerer, både feil og advarsler. Jeg har ikke kjørt den på et High Compliance-prosjekt, så jeg kan ikke bekrefte at HIPAA-advarslene kommer i samme liste. Les dem i dashbordet uansett. ## Hva HIPAA-innstillinger ikke dekker Ingen av de ti pliktene nevner Row Level Security. Et HIPAA-prosjekt med alle innstillingene over på plass kan fortsatt servere en pasienttabell til alle som har den offentlige nøkkelen, hvis tabellen har RLS av eller en policy som slipper gjennom hver rad. Det er den delen sjekken leser i sin helhet: tilganger, policyer, funksjoner som omgår RLS og sensitivt utseende kolonner som anonyme besøkende kan lese. Forskjellen på de to nøklene står i [Supabase anon key vs service role key](https://madsalt.tech/no/blog/supabase-anon-key-vs-service-role-key/), og hvordan jeg beviser hver tilgang mot API-et står i [slik tester du Supabase RLS](https://madsalt.tech/no/blog/how-to-test-supabase-rls/). Det samme gjelder alt utenfor Supabase. Modellen for delt ansvar legger tredjepartstjenester på deg: SMTP- og SMS-leverandører, OAuth-innlogging og ethvert eksternt API en Edge Function eller en database-trigger kaller. Hvis en av dem mottar PHI, er den en del av HIPAA-bildet ditt, ikke Supabases, så sjekk om hver leverandør signerer en BAA før data når den. ## Hvordan sjekker du prosjektet ditt? 1. Bekreft i dashbordet at organisasjonen har HIPAA-tillegget og at prosjektet er merket High Compliance. Åpne deretter Security Advisor og gå gjennom hver advarsel. 2. Åpne Database → Backups og bekreft at PITR er på, ikke bare daglige sikkerhetskopier. 3. Kjør `show log_connections;` i SQL-editoren. Den skal returnere `on`. 4. Bekreft i organisasjonsinnstillingene at hvert medlem har MFA og at MFA er påkrevd. 5. Kjør den gratis [Supabase sikkerhetssjekken](https://madsalt.tech/no/tools/supabase-security-check/) for SSL, nettverksbegrensninger, offentlige buckets og tilgangsreglene over. Notatet mitt om offentlige buckets viser hvordan du flytter filer til signerte URL-er. For det bredere spørsmålet om hva plattformen garanterer og ikke garanterer, se [er Supabase trygt?](https://madsalt.tech/no/blog/is-supabase-secure/). Denne artikkelen er ikke juridisk rådgivning; compliance-ansvarlig eller revisor avgjør hva BAA-en og HIPAA-programmet ditt krever. Bygger du en helseapp på Supabase? Jeg ser gjerne på prosjektinnstillingene dine og utveksler erfaringer. Ingen salgstale. [Ta kontakt](https://madsalt.tech/no/#contact)