GDPR för SaaS-företag: Komplett complianceguide
SaaS-företag har unika GDPR-utmaningar: dubbla roller som personuppgiftsansvarig och biträde, underbiträdeskedjor, PUB-avtal och internationella överföringar. En praktisk guide för SaaS-grundare och CTO:er.
Generella GDPR-guider säger att du ska inhämta samtycke och utse ett dataskyddsombud. Det rådet är inte fel, men det missar vad som gör SaaS-compliance genuint svårt. Du samlar inte bara in e-postadresser på en marknadsföringssida. Du behandlar dina kunders data, hanterar dussintals tredjepartsintegrationer, överför personuppgifter över landsgränser och gör allt detta i stor skala i en multi-tenant-arkitektur.
Den här guiden är byggd för SaaS-grundare, CTO:er och teknikledare som behöver förstå vad GDPR faktiskt kräver av deras specifika affärsmodell. Inte teori. Inte checklistor kopierade från en advokatbyrås blogg. Praktiskt, tekniskt och specifikt för hur moderna SaaS-produkter fungerar.
Ansvarig vs biträde: Varför SaaS-företag har dubbla skyldigheter
GDPR tilldelar två primära roller: personuppgiftsansvariga bestämmer varför och hur personuppgifter behandlas, och personuppgiftsbiträden hanterar data på den ansvariges uppdrag. De flesta företag faller prydligt in i en kategori. SaaS-företag gör det inte.
När en kund använder din SaaS-produkt för att hantera sina användare, klienter eller anställda, är du ett personuppgiftsbiträde. Din kund bestämmer vilka data som samlas in och varför. Du tillhandahåller infrastrukturen och mjukvaran som behandlar dem. Kunden är ansvarig; du behandlar enligt deras instruktioner.
Men du är samtidigt personuppgiftsansvarig för andra kategorier av personuppgifter. Din egen kunddatabas, faktureringsuppgifter, marknadsföringslistor, personalinformation, användaranalys, supportärenden som innehåller personuppgifter. För allt detta bestämmer du ändamålen och medlen för behandlingen. Du är den ansvarige.
Praktiskt exempel: En projekthantering-SaaS lagrar uppgiftsbeskrivningar, användarnamn och filbilagor åt sina kunder. För den datan är den ett biträde. Men den spårar också vilka funktioner varje kund använder (analys), lagrar betalkortstoken (fakturering) och samlar in e-postadresser för sitt nyhetsbrev (marknadsföring). För den datan är den ansvarig. Varje kategori har olika juridiska skyldigheter.
Den dubbla rollen har konkreta konsekvenser. Som biträde behöver du personuppgiftsbiträdesavtal (PUB-avtal) med varje kund. Som ansvarig behöver du en rättslig grund för varje behandlingsaktivitet, måste uppfylla registrerades rättigheter direkt och måste föra egna behandlingsregister. Många SaaS-företag bygger sitt complianceprogram kring en roll och glömmer den andra helt.
När du är ansvarig respektive biträde:
- Biträde: Kunddata som lagras i din plattform (deras användare, deras filer, deras register)
- Biträde: Data som behandlas enligt kundinstruktioner via ditt API eller gränssnitt
- Ansvarig: Dina egna kundkonton, faktureringsdata, CRM-register
- Ansvarig: Produktanalys, användningsspårning, funktionstelemetri
- Ansvarig: E-postlistor för marknadsföring, besökardata, cookiedata
- Ansvarig: Anställdas och konsulters personuppgifter
Det finns också ett tredje scenario som överraskar SaaS-företag: gemensamt personuppgiftsansvar. Om din produkts designbeslut avgör vilka data som samlas in eller hur de används, och din kund inte kan åsidosätta dessa beslut, kan tillsynsmyndigheter klassificera dig som gemensamt ansvarig. Social inloggning, obligatorisk analys och AI-funktioner som tränas på kunddata är vanliga utlösare.
Underbiträdesproblemet
Öppna din SaaS-produkts arkitekturdiagram. Räkna varje tredjepartstjänst som berör personuppgifter. AWS eller GCP för hosting. Stripe för betalningar. SendGrid eller Postmark för transaktionella e-postmeddelanden. Intercom eller Zendesk för kundsupport. Segment eller Mixpanel för analys. Sentry för felspårning. Cloudflare för CDN och DDoS-skydd. Var och en av dessa är ett underbiträde enligt GDPR.
Artikel 28(2) i GDPR är tydlig: ett biträde får inte anlita ett annat biträde utan föregående skriftligt godkännande från den ansvarige. De flesta SaaS-företag hanterar detta genom ett generellt skriftligt godkännande i sitt PUB-avtal, kombinerat med en offentligt publicerad lista över underbiträden och en aviseringsmekanism vid ändringar.
Detta skapar fyra konkreta skyldigheter:
- 1. Upprätthåll en underbiträdeslista. Publicera och håll aktuell en lista över varje tredje part som behandlar personuppgifter å dina vägnar. Inkludera namn, ändamål och plats.
- 2. Meddela innan ändringar. Ge kunder förhandsbesked (vanligtvis 30 dagar) innan du lägger till eller byter ut ett underbiträde. Inkludera en invändningsmekanism.
- 3. Vidareför skyldigheter. Varje underbiträdesavtal måste innehålla samma dataskyddsskyldigheter som finns i ditt PUB-avtal med din kund. Om ditt PUB-avtal säger att data ska krypteras i vila, måste ditt underbiträde kryptera i vila.
- 4. Du förblir ansvarig. Om ditt underbiträde orsakar ett dataintrång är du ansvarig gentemot din kund. Du kan vända dig mot underbiträdet separat, men det initiala ansvaret stannar hos dig.
Underbiträdesproblemet blir betydligt mer komplext när USA-baserade tjänster är inblandade. CLOUD Act ger amerikanska myndigheter laglig rätt att tvinga vilket amerikanskt företag som helst att lämna ut data, oavsett var datan fysiskt lagras. Om din SaaS-produkt körs på AWS och skickar e-post genom SendGrid, omfattas två av dina underbiträden av amerikanska myndigheters dataåtkomstbegäran som står i direkt konflikt med GDPR.
De dolda underbiträdena: Många SaaS-företag spårar sina primära infrastrukturleverantörer men missar inbäddade underbiträden. Fångar ditt felspårningsverktyg (Sentry, Bugsnag) användardata i stackspår? Tar din feature flag-tjänst (LaunchDarkly) emot användaridentifierare? Behandlar ditt CDN (Cloudflare) förfrågningshuvuden som innehåller personuppgifter? Var och en av dessa är ett underbiträde du måste redovisa och ha avtal med.
Enterprise-kunder i reglerade branscher granskar underbiträdeslistor allt noggrannare. Banker, vårdgivare och myndigheter kan avvisa din produkt direkt om din underbiträdeskedja inkluderar amerikanska företag utan tillräckliga överföringsmekanismer. Att bygga din stack på EU-baserad infrastruktur från början undviker detta försäljningshinder helt.
Personuppgiftsbiträdesavtal: Vad dina kunder kommer att kräva
Artikel 28 i GDPR kräver att förhållandet mellan en ansvarig och ett biträde regleras av ett bindande avtal: personuppgiftsbiträdesavtalet (PUB-avtalet). För SaaS-företag är PUB-avtal inte frivilligt pappersarbete. De är en försäljningsförutsättning. Varje mellanstor eller stor kund med en juridisk avdelning kommer att begära ditt PUB-avtal innan de tecknar. Om du inte har ett stannar affären.
Ett komplett PUB-avtal måste innehålla specifika element definierade i artikel 28(3). Varje del har praktiska konsekvenser för din SaaS-produkt:
Obligatoriska element enligt artikel 28(3):
- 1. Föremål och varaktighet. Definiera vad din produkt gör med datan och hur länge behandlingen pågår (vanligtvis avtalsperioden plus en raderingsperiod).
- 2. Art och ändamål. Hosting, lagring, beräkning, analys, kommunikationsleverans. Var specifik för din produkt.
- 3. Typer av personuppgifter. Namn, e-postadresser, IP-adresser, användningsdata, filinnehåll, betalningsdata. Lista allt din produkt hanterar.
- 4. Kategorier av registrerade. Din kunds slutanvändare, deras anställda, deras klienter. Definiera vem datan tillhör.
- 5. Den ansvariges skyldigheter och rättigheter. Kundens rätt att granska, instruera och få incidentmeddelanden.
- 6. Tekniska och organisatoriska åtgärder. Kryptering, åtkomstkontroller, incidenthantering, personalutbildning. Hänvisa till din säkerhetsdokumentation.
- 7. Underbiträdesbestämmelser. Listan, aviseringsmekanismen och invändningsförfarandet som beskrevs i föregående avsnitt.
- 8. Radering eller återlämnande av data. Vad som händer när avtalet upphör. Definiera lagringsperioder, exportformat och raderingstidslinjer.
Utöver det juridiska minimikravet förväntar sig enterprise-köpare att ditt PUB-avtal behandlar granskningsrättigheter (hur de kan verifiera din compliance), tidsfrister för incidentmeddelanden (72 timmar är GDPR:s krav till tillsynsmyndigheten, men kunder vill ofta ha snabbare avisering till dem) och mekanismer för gränsöverskridande överföringar (standardavtalsklausuler, adekvansbeslutsgrunder eller bindande företagsregler).
Gör ditt PUB-avtal tillgängligt utan kontakt. Det snabbaste sättet att sluta affärer är att publicera ditt PUB-avtal på din webbplats där prospekt kan granska det utan att behöva fråga. Inkludera en signeringsmekanism (DocuSign, elektroniskt godkännande i dina villkor) så att kunder kan underteckna utan att vänta på din juridiska avdelning. Varje dag som spenderas på att förhandla PUB-villkor är en dag affären inte stängs.
Ett mönster som fungerar bra för SaaS-företag: skapa ett ramavtal (master PUB) som täcker standardfallet, med bilagor för datakategorier, underbiträden och tekniska åtgärder som kan uppdateras utan att omförhandla kärnavtalet. Denna struktur låter dig upprätthålla compliance allt eftersom din produkt och infrastruktur utvecklas.
Internationella överföringar efter Schrems II
Om ditt SaaS-företag har användare i EU och behandlar någon av deras data utanför Europeiska ekonomiska samarbetsområdet gör du en internationell dataöverföring. GDPR kapitel V ställer strikta regler för detta. Schrems II-domen från EU-domstolen 2020 gjorde dessa regler betydligt svårare att uppfylla, och landskapet förblir komplext.
Det finns tre primära mekanismer för lagliga internationella överföringar:
Överföringsmekanismer:
- 1. Adekvansbeslut. EU-kommissionen har beslutat att vissa länder ger tillräckligt dataskydd. Överföringar till dessa länder kräver inga ytterligare skyddsåtgärder. Listan inkluderar Storbritannien, Schweiz, Japan, Sydkorea och sedan 2023 USA (under EU-US Data Privacy Framework). Det amerikanska adekvansbeslutet utmanas i domstol.
- 2. Standardavtalsklausuler (SCC). Förhandsgodkända avtalsvillkor antagna av EU-kommissionen. Sedan juni 2021 krävs nya SCC med modulär struktur. Du måste använda rätt modul: Modul 2 (ansvarig-till-biträde) för de flesta SaaS-kundrelationer, Modul 3 (biträde-till-biträde) för dina underbiträdesrelationer.
- 3. Bindande företagsregler (BCR). Godkända interna regler för multinationella koncerner. Dyrt och tidskrävande att upprätta (12-18 månader för godkännande). Praktiskt bara för stora företag, inte typiska SaaS-bolag.
Schrems II lade till ett kritiskt krav: även med SCC på plats måste du genomföra en Transfer Impact Assessment (TIA) för att utvärdera om lagarna i mottagarlandet ger tillräckligt skydd för den överförda datan. Om de inte gör det måste du implementera kompletterande åtgärder (kryptering, pseudonymisering, delad behandling) för att överbrygga gapet.
För SaaS-företag som överför data till USA måste TIA:n adressera CLOUD Act och amerikanska övervakningsprogram (Section 702 FISA, Executive Order 12333). EU-US Data Privacy Framework försöker lösa detta genom att inrätta en Data Protection Review Court för EU-medborgare, men integritetsförespråkare hävdar att den inte ger likvärdigt skydd som EU-domstolar.
Praktiskt tillvägagångssätt för SaaS-företag: Välj EU-baserad infrastruktur där det är möjligt. Använd Hetzner, OVHcloud eller Scaleway istället för AWS eller GCP. Där amerikanska underbiträden är oundvikliga (Stripe för betalningar, till exempel), säkerställ att SCC finns på plats, genomför din TIA, dokumentera kompletterande åtgärder och var beredd att förklara ditt resonemang för enterprise-kunder som frågar. Den enklaste compliancepositionen är att hålla data i EU och undvika överföringsfrågan helt.
Den praktiska verkligheten: många SaaS-företag upptäcker att de gör internationella överföringar de inte kände till. Ditt CDN distribuerar innehåll globalt. Ditt felspårningsverktyg skickar stackspår till amerikanska servrar. Ditt analysverktyg behandlar data genom amerikansk infrastruktur. En grundlig datakartläggning avslöjar överföringar som är osynliga på applikationsnivå men juridiskt betydelsefulla.
Tekniska åtgärder som faktiskt spelar roll
GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" för att säkerställa en säkerhetsnivå som är lämplig med hänsyn till risken. För SaaS-företag är detta inte ett abstrakt krav. Dina kunder kommer att fråga specifikt vilka åtgärder du har på plats, och dina svar avgör om du vinner eller förlorar enterprise-affärer.
Här är de tekniska åtgärder som spelar störst roll för SaaS GDPR-compliance, rangordnade efter påverkan:
Kryptering
- • Under transport: TLS 1.2+ på alla anslutningar. Inga undantag. Detta inkluderar intern tjänst-till-tjänst-kommunikation, inte bara det publika API:et. Certificate pinning för mobilklienter.
- • I vila: AES-256 för databaser, fillagring och säkerhetskopior. Om du använder hanterade databaser (RDS, Cloud SQL), aktivera kryptering och verifiera att den är aktiv. För känsliga fält (personnummer, hälsodata), överväg applikationsnivåkryptering så att inte ens databasadministratörer kan läsa klartext.
- • Kryptering av säkerhetskopior: Säkerhetskopior måste krypteras med samma noggrannhet som produktionsdata. En okrypterad databasdump i en S3-bucket är ett intrång som väntar på att hända.
Åtkomstkontroller
- • Principen om minsta behörighet. Utvecklare bör inte ha stående åtkomst till produktionsdatabaser. Använd just-in-time-åtkomst med godkännandeflöden och automatisk utgång.
- • Multifaktorautentisering. Obligatoriskt för alla interna system, inte valfritt. Hårdvarunycklar (YubiKey) för infrastrukturåtkomst.
- • Rollbaserad åtkomstkontroll (RBAC). Inom din produkt måste kunder kunna styra vem i deras organisation som kan komma åt vilken data. Detta är både ett compliancekrav och en försäljningsmöjlighet.
Granskningsloggar
- • Vem åtkom vad, när. Logga varje åtkomst till personuppgifter, varje ändring, varje export. Oföränderliga loggar lagrade separat från applikationsdatabasen.
- • Kundvända granskningsloggar. Enterprise-kunder kommer att begära granskningsspår inom din produkt. Ge dem insyn i vem i deras team som åtkom data och vilka ändringar som gjordes.
- • Lagring och integritet. Loggar måste vara manipuleringssäkra och bevaras tillräckligt länge för att stödja incidentutredning (minimum 12 månader, ofta längre för reglerade branscher).
Dataisolering (multi-tenancy)
- • Logisk isolering. Som minimum måste varje databasfråga vara begränsad till klienten. En bugg som läcker data mellan kunder är både ett intrång och en affärsavslutande händelse.
- • Krypteringsnyckelisolering. Överväg per-klient-krypteringsnycklar. Om en klients nyckel komprometteras förblir andra klienters data skyddad.
- • Dedikerad infrastruktur som alternativ. Vissa enterprise-kunder kommer att kräva att deras data fysiskt separeras. Att erbjuda single-tenant-deployment (dedikerad databas, dedikerad beräkningskapacitet) adresserar detta.
Incidentdetektering och respons
- • Realtidsvarning. Anomalidetektering på autentiseringshändelser, dataåtkomstmönster och API-användning. Du kan inte meddela ett intrång inom 72 timmar om du inte upptäcker det på veckor.
- • Incidenthanteringsplan. Ett dokumenterat, testat förfarande för att klassificera, begränsa och rapportera intrång. Inkludera kommunikationsmallar för kunder och tillsynsmyndigheter.
- • Sårbarhetshantering. Regelbundna beroendeuppdateringar, scanning av containerimages och penetrationstester. Dokumentera din patchningskadens och genomsnittlig tid till åtgärd.
Dessa åtgärder är inte bara compliancekryssrutor. De är vad enterprise-upphandlingsteam utvärderar när de beslutar om de kan lita på din produkt med sin data. Företag som investerar i dessa kontroller tidigt stänger enterprise-affärer snabbare och möter färre invändningar under säkerhetsgranskningar.
Bygga ett GDPR-complianceprogram för SaaS
Tekniska åtgärder ensamma utgör inte compliance. GDPR kräver ett strukturerat, dokumenterat complianceprogram som visar ansvarsskyldighet. Artikel 5(2) lägger bevisbördan på dig: du måste kunna visa att du följer reglerna, inte bara påstå det.
Här är ramverket som fungerar för SaaS-företag, från tidigaste prioritet till löpande underhåll:
Steg 1: Datakartläggning
Innan du kan skydda personuppgifter behöver du veta var de finns. En grundlig datakartläggning identifierar varje system, databas och tredjepartstjänst som behandlar personuppgifter. För SaaS-företag måste detta täcka både din egen data (ansvarigssidan) och kunddataflöden (biträdessidan).
Kartlägg varje dataflöde: vilken data som kommer in, var den lagras, vem som kan komma åt den, vart den överförs och när den raderas. Detta blir grunden för varje annan complianceaktivitet.
Steg 2: Behandlingsregister (ROPA)
Artikel 30 kräver att både ansvariga och biträden för register över behandlingsaktiviteter. Som SaaS-företag som verkar i båda rollerna behöver du två uppsättningar register.
Ansvarigs ROPA: dokumentera varje behandlingsaktivitet där du bestämmer ändamålet (marknadsföring, analys, fakturering, HR). Inkludera den rättsliga grunden, datakategorier, lagringsperioder och överföringsmekanismer. Biträdes ROPA: dokumentera de kategorier av behandling du utför på uppdrag av varje kund, vilka underbiträden som är inblandade och de internationella överföringarna.
Steg 3: Konsekvensbedömning (DPIA)
Artikel 35 kräver en konsekvensbedömning avseende dataskydd (DPIA) när behandling "sannolikt leder till hög risk" för enskilda. För SaaS-företag gäller detta vanligtvis när du lanserar funktioner som involverar profilering, automatiserat beslutsfattande, storskalig behandling av känsliga uppgifter eller systematisk övervakning av offentliga platser.
Praktiska utlösare för SaaS: lägga till AI/ML-funktioner som behandlar personuppgifter, bygga analyspaneler som profilerar användarbeteende, introducera biometrisk autentisering, eller expandera till hälso- eller finansdatabehandling. Bygg in DPIA i din produktutvecklingsprocess så att den sker före lansering, inte efter.
Steg 4: Incidentmeddelanden
Artikel 33 kräver anmälan till tillsynsmyndigheten inom 72 timmar efter att man blivit medveten om en personuppgiftsincident. Artikel 34 kräver meddelande till berörda individer när intrånget sannolikt medför hög risk för deras rättigheter.
Som SaaS-biträde har du också skyldigheter enligt artikel 28 att meddela dina kunder (de ansvariga) utan onödigt dröjsmål. Ditt PUB-avtal anger vanligtvis en tidsram. Bygg in detta i din incidenthantering: vem fattar beslutet, vilken information inkluderas, vilken tillsynsmyndighet som ska kontaktas och hur du kommunicerar med berörda kunder.
Steg 5: Dataskyddsombud
Artikel 37 kräver ett dataskyddsombud (DPO) när din kärnverksamhet involverar regelbunden och systematisk övervakning av registrerade i stor skala, eller storskalig behandling av särskilda kategorier av uppgifter. Många SaaS-företag faller i den första kategorin.
Om du inte är juridiskt skyldig att utse ett DPO, överväg om en utsedd integritetsansvarig uppnår samma mål. Enterprise-kunder kommer att fråga vem som ansvarar för dataskydd. Att ha en namngiven person med tydlig befogenhet gör compliance påtagligt och ger kunder en kontaktpunkt för dataskyddsfrågor.
För en bredare bild av hur GDPR-compliance samverkar med andra EU-krav som NIS2, se vår GDPR- och NIS2-complianceguide.
Vad enterprise-kunder kommer att fråga (och hur du svarar)
Enterprise-upphandling är där GDPR-compliance blir en intäktsdrivare eller en affärsdödare. Säkerhets- och compliancegranskningar är standard för varje SaaS-leverantör som säljer till medelstora och stora kunder. Att veta vad de kommer att fråga, och ha svaren redo, är skillnaden mellan en stängning på två veckor och ett sex månader långt dödläge.
Räkna med dessa:
Säkerhetsfrågeformulär
De flesta enterprise-köpare använder standardiserade frågeformulär: CAIQ (Consensus Assessment Initiative Questionnaire), SIG (Standard Information Gathering) eller sina egna interna mallar. Dessa frågeformulär innehåller 200-400 frågor som täcker kryptering, åtkomstkontroller, incidenthantering, affärskontinuitet, leverantörshantering och regulatorisk compliance.
Förbered ett mastersvardokument och håll det aktuellt. Att förifylla en CAIQ eller SIG Lite och publicera den på din trust-sida sparar veckor per affär. Inkludera hänvisningar till dina policyer, certifieringar och teknisk dokumentation.
SOC 2 vs ISO 27001
SOC 2 är standarden för USA-fokuserad enterprise-försäljning. Den utvärderar kontroller mot fem Trust Service Criteria (säkerhet, tillgänglighet, behandlingsintegritet, konfidentialitet, integritet). En SOC 2 Type II-rapport täcker en 6-12 månaders observationsperiod och är vad de flesta amerikanska enterprise-köpare förväntar sig.
ISO 27001 är den internationella standarden för ledningssystem för informationssäkerhet. Den är mer erkänd i Europa och ger ett bredare ramverk. Certifiering innebär en extern granskning och årliga övervakningsgranskningar.
För SaaS-företag som säljer till europeiska enterprise-kunder väger ISO 27001 tyngre. För amerikanska kunder förväntas SOC 2. Om du bara kan investera i en, välj baserat på din primärmarknad. Endera certifieringen minskar friktionen i säkerhetsgranskningar dramatiskt.
Compliancedokumentation checklista
Bygg ett trust center (en publik eller gated sida på din webbplats) med dessa dokument redo:
- • Personuppgiftsbiträdesavtal (PUB) med förifyllda bilagor
- • Underbiträdeslista med uppdateringshistorik
- • Tekniska och organisatoriska åtgärder (TOM)-dokument
- • Integritetspolicy och cookiepolicy
- • Sammanfattning av penetrationstest (inte fullständig rapport)
- • SOC 2-rapport eller ISO 27001-certifikat
- • Översikt av affärskontinuitet och katastrofåterställning
- • Sammanfattning av incidenthanteringspolicy
- • Policy för datalagring och radering
- • Ifylld CAIQ eller SIG Lite-frågeformulär
Compliance som säljverktyg: Varje dokument i ditt trust center är ett säljverktyg. När en prospekts säkerhetsteam laddar ner ditt PUB-avtal och SOC 2-rapport utan att involvera ditt säljteam har du eliminerat veckor från säljcykeln. Företag som behandlar compliancedokumentation som en produkt, inte en börda, stänger enterprise-affärer snabbare.
Frågorna kommer att fortsätta i takt med att det regulatoriska landskapet utvecklas. NIS2, EU AI Act, DORA för finansiella tjänster. Positionera ditt complianceprogram som ett levande system som anpassar sig, inte ett engångsprojekt som samlar damm. Dina kunder är under ökande regulatoriskt tryck själva, och de behöver leverantörer som gör compliance enklare, inte svårare.
Vanliga frågor
Är ett SaaS-företag personuppgiftsansvarig eller personuppgiftsbiträde enligt GDPR?
De flesta SaaS-företag är båda. Du är personuppgiftsbiträde när du hanterar dina kunders data på deras uppdrag, och personuppgiftsansvarig för din egen affärsdata (fakturering, marknadsföring, analys, personalregister). Denna dubbla roll innebär att du måste följa båda uppsättningarna av skyldigheter: biträdesavtal med kunder, och ansvarig-nivå compliance (rättslig grund, registrerades rättigheter, behandlingsregister) för din egen behandlingsverksamhet.
Vad är ett underbiträde och varför spelar det roll för GDPR?
Ett underbiträde är en tredjepartstjänst som behandlar personuppgifter å dina vägnar. För ett typiskt SaaS-företag inkluderar detta molnhostingleverantörer (AWS, Hetzner), betalningsförmedlare (Stripe), e-postleveranstjänster (SendGrid), analysverktyg (Mixpanel) och kundsupportplattformar (Zendesk). GDPR kräver att du upprätthåller en offentlig lista över underbiträden, meddelar kunder innan ändringar, säkerställer att varje underbiträde har tillräckliga skydd och förblir ansvarig för deras agerande.
Behöver SaaS-företag ett personuppgiftsbiträdesavtal?
Ja. Artikel 28 i GDPR kräver ett bindande avtal mellan varje ansvarig och biträde. Som SaaS-företag behöver du PUB-avtal i två riktningar: med dina kunder (som är ansvariga för sin data) och med dina underbiträden (som behandlar data å dina vägnar). Utan PUB-avtal bryter du direkt mot GDPR, och enterprise-kunder kommer inte att teckna avtal med dig.
Kan ett SaaS-företag använda amerikanska molnleverantörer och fortfarande följa GDPR?
Tekniskt ja, men med betydande juridisk risk. EU-US Data Privacy Framework ger för närvarande en rättslig grund för överföringar, men det utmanas i domstol precis som sina föregångare (Safe Harbor, Privacy Shield). Amerikanska leverantörer omfattas dessutom av CLOUD Act. Du behöver standardavtalsklausuler, en Transfer Impact Assessment och kompletterande tekniska åtgärder. Många europeiska enterprise-kunder kräver nu EU-baserad infrastruktur som upphandlingskrav, vilket gör amerikanska molnleverantörer till en kommersiell nackdel även när det är juridiskt tillåtet.
Utvärdera din SaaS-compliance
Vår automatiserade SVAR-skanning kontrollerar din webbplats och infrastruktur mot 16 säkerhets- och compliancedimensioner. Se var du står på 2 minuter.