---
title: "Är Supabase HIPAA-kompatibelt? Vad BAA lämnar åt dig"
description: "Supabase tecknar en BAA på Team-planen med HIPAA-tillägget. Tio skyldigheter är dina, från PITR till anslutningsloggar. Vilka en gratiskontroll kan se."
url: "https://madsalt.tech/sv/blog/is-supabase-hipaa-compliant/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/sv/about/"
language: "sv"
published: 2026-11-03
---

# Är Supabase HIPAA-kompatibelt? Vad BAA lämnar åt dig

Kort sagt

Ja, hostat Supabase kan rymma hälsodata: det tecknar ett Business Associate Agreement (BAA) på Team-planen och uppåt, när HIPAA-tillägget är på. Självhostat Supabase omfattas inte. BAA:t konfigurerar inte ditt projekt. Supabases modell för delat ansvar listar tio skyldigheter som stannar hos dig, bland dem point-in-time recovery, SSL-krav, nätverksbegränsningar och loggning av Postgres-anslutningar. Av de tio flaggar min gratis Supabase-kontroll 3 direkt, 2 bara delvis och kan inte se de övriga 5.

Jag heter Denys och är full-stack- och AI-ingenjör, och de flesta appar jag bygger eller rättar körs på Supabase. När en hälso- eller wellnessapp frågar om den kan använda Supabase har det ärliga svaret två delar: vad Supabase tecknar och vad du själv måste slå på. Den här artikeln tar dem i den ordningen, från Supabases egna dokument, lästa den 29 oktober 2026.

## Är Supabase HIPAA-kompatibelt?

Den hostade plattformen är det. Supabases [HIPAA-guide](https://supabase.com/docs/guides/security/hipaa-compliance) säger att Supabase agerar som business associate för kunder som hanterar Protected Health Information (PHI), har tecknat BAA:n med sina egna leverantörer som kan nå de uppgifterna, som AWS, och får sina HIPAA-kontroller granskade varje år i samma granskningsperiod som SOC 2. HIPAA-projekt får också alla SOC 2-kontroller som resten av plattformen har.

Två begränsningar står i samma guide. Självhostat Supabase får inte de här kontrollerna direkt, och HIPAA-efterlevnad är där en sak mellan dig och din revisor. Och BAA:t täcker bara Supabases del: guiden listar ditt ansvar som att följa HIPAA:s Privacy-, Security- och Breach Notification-regler, att teckna BAA:t och att konfigurera dina HIPAA-projekt som Security Advisor anger.

## Vad behöver du innan du lagrar PHI?

Från [sidan om HIPAA-projekt](https://supabase.com/docs/guides/platform/hipaa-projects) och [modellen för delat ansvar](https://supabase.com/docs/guides/deployment/shared-responsibility-model):

1. **Team-planen eller högre.** BAA:t finns inte under den.
2. **HIPAA-tillägget och ett undertecknat BAA.** Du begär båda av Supabase; tillägget aktiveras på organisationen.
3. **High Compliance på varje projekt.** Med tillägget på kan ett projekt markeras som High Compliance i General Project Settings. Därefter kör Supabase extra kontroller på projektet löpande, och en inställning som inte stämmer visas som en varning i Security Advisor.

Security Advisor varnar; den rättar inte. Supabases guide är rak på den punkten: ansvaret för att tillämpa de rekommenderade kontrollerna ligger hos kunden.

## Vilka inställningar behöver ett HIPAA-projekt?

Här är hela listan från modellen för delat ansvar, med var varje punkt finns och om den gratis [Supabase säkerhetskontrollen](https://madsalt.tech/sv/tools/supabase-security-check/) kan se den. Kontrollen läser ett projekt via Supabases Management API efter att du loggat in med Supabase, så den ser inställningar, inte avtal.

| Din skyldighet enligt BAA:t                          | Var den finns                                        | Gratiskontroll                                                |
| ---------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------- |
| Teckna BAA:t, Team-planen eller högre                | Avtal med Supabase                                   | Kan inte se den                                               |
| Markera projekt som HIPAA, åtgärda advisor-varningar | General Project Settings, Security Advisor           | Delvis: visar varje Security Advisor-lint den får             |
| MFA på varje Supabase-konto, påtvingat               | Organisationsinställningar                           | Kan inte se den                                               |
| Point-in-time recovery (PITR)                        | Database → Backups, kräver ett litet compute-tillägg | Delvis: godkänns med dagliga säkerhetskopior ensamma          |
| SSL-krav                                             | Database Settings → SSL Configuration                | Flaggar den: "SSL not enforced on database connections"       |
| Nätverksbegränsningar                                | Database Settings → Network Restrictions             | Flaggar den: "Database open to every IP address"              |
| Loggning av Postgres-anslutningar på                 | `log_connections`, av som standard på nya projekt    | Kan inte se den                                               |
| Kryptering enligt HIPAA Security Rule                | Supabase krypterar i vila och under överföring       | Kan inte se den; kryptering på applikationsnivå är ditt val   |
| Ingen PHI i publika Storage-buckets                  | Storage → bucket-inställningar                       | Flaggar varje publik bucket; om den rymmer PHI avgör du själv |
| Ingen överföring till en icke-HIPAA-organisation     | Projektöverföring                                    | Kan inte se den                                               |

![Supabases 10 HIPAA-skyldigheter: vad en gratiskontroll ser. Skyldigheter ur Supabases modell för delat ansvar. Flaggas av en kontrollregel: 3; Ses bara delvis: 2; Syns inte för kontrollen: 5.](https://madsalt.tech/charts/sv/is-supabase-hipaa-compliant.svg)

*Figur 1. Supabases modell för delat ansvar, läst den 29 oktober 2026, mot reglerna i min gratis Supabase-kontroll.*

## Vad missar gratiskontrollen?

Tre luckor är värda att säga högt, eftersom ett grönt resultat kan läsas som mer än det är.

**Dagliga säkerhetskopior är inte PITR.** Kontrollens regel för säkerhetskopior godkänns när projektet har point-in-time recovery eller minst en säkerhetskopia. Ett betalt projekt med dagliga säkerhetskopior och utan PITR godkänns. HIPAA-projekt behöver just PITR, så titta själv under Database → Backups; PITR kräver minst det lilla compute-tillägget. Vad varje plan sparar, och ett återställningstest, finns i Supabase backups.

**Två olika MFA-inställningar.** Kontrollens "No multi-factor method enabled" gäller din apps användare: om Supabase Auth erbjuder dem en andra faktor. HIPAA-skyldigheten gäller de som kan öppna din Supabase-dashboard: MFA på varje konto i organisationen, påtvingat som krav. Du vill ha båda, och de slås på på olika ställen.

**Anslutningslogg.** Supabase sätter `log_connections` till av på nya projekt, och HIPAA-projekt bör ha den på för revisionsspåret. Kontrollen har ingen regel som läser den. I SQL-editorn svarar `show log_connections;` på det på en rad, och Security Advisor varnar för det på ett High Compliance-projekt.

Kontrollen visar varje lint som Security Advisor returnerar, både fel och varningar. Jag har inte kört den på ett High Compliance-projekt, så jag kan inte bekräfta att HIPAA-varningarna kommer i samma lista. Läs dem i dashboarden i alla fall.

## Vad HIPAA-inställningar inte täcker

Ingen av de tio skyldigheterna nämner Row Level Security. Ett HIPAA-projekt med alla inställningarna ovan på plats kan ändå servera en patienttabell till vem som helst som har den publika nyckeln, om tabellen har RLS av eller en policy som släpper igenom varje rad. Det är den del kontrollen läser fullt ut: behörigheter, policyer, funktioner som kringgår RLS och känsligt utseende kolumner som anonyma besökare kan läsa. Skillnaden mellan de två nycklarna står i [Supabase anon key vs service role key](https://madsalt.tech/sv/blog/supabase-anon-key-vs-service-role-key/), och hur jag bevisar varje behörighet mot API:et står i [så testar du Supabase RLS](https://madsalt.tech/sv/blog/how-to-test-supabase-rls/).

Detsamma gäller allt utanför Supabase. Modellen för delat ansvar lägger tredjepartstjänster på dig: SMTP- och SMS-leverantörer, OAuth-inloggning och alla externa API:er som en Edge Function eller en databastrigger anropar. Om en av dem tar emot PHI är den en del av din HIPAA-bild, inte Supabases, så kontrollera om varje leverantör tecknar ett BAA innan data når den.

## Hur kontrollerar du ditt projekt?

1. Bekräfta i dashboarden att organisationen har HIPAA-tillägget och att projektet är markerat som High Compliance. Öppna sedan Security Advisor och gå igenom varje varning.
2. Öppna Database → Backups och bekräfta att PITR är på, inte bara dagliga säkerhetskopior.
3. Kör `show log_connections;` i SQL-editorn. Den ska returnera `on`.
4. Bekräfta i organisationsinställningarna att varje medlem har MFA och att MFA är ett krav.
5. Kör den gratis [Supabase säkerhetskontrollen](https://madsalt.tech/sv/tools/supabase-security-check/) för SSL, nätverksbegränsningar, publika buckets och åtkomstreglerna ovan. Min anteckning om publika buckets visar hur du flyttar filer till signerade URL:er.

För den bredare frågan om vad plattformen garanterar och inte garanterar, se [är Supabase säkert?](https://madsalt.tech/sv/blog/is-supabase-secure/). Den här artikeln är inte juridisk rådgivning; din compliance-ansvarige eller revisor avgör vad ditt BAA och ditt HIPAA-program kräver.

Bygger du en hälsoapp på Supabase?

Jag tittar gärna på dina projektinställningar och utbyter erfarenheter. Ingen säljpitch.

[Hör av dig](https://madsalt.tech/sv/#contact)
