GDPR for SaaS: 14 tekniske krav du skal have styr på

GDPR for SaaS handler i praksis om 14 tekniske krav: du skal vide hvilke persondata du har, holde kunderne adskilt, kunne eksportere og slette data, logge adgang, styre dine underdatabehandlere og opdage et brud i tide. De fleste krav er billige at bygge ind fra start og dyre at eftermontere, når den første store kunde sender et sikkerhedsspørgeskema.

Jeg er udvikler, ikke jurist. Tjeklisten dækker den tekniske side og er ikke juridisk rådgivning, så lad en advokat eller GDPR-rådgiver se på aftaler og privatlivspolitik.

Den korte version: 14 krav

Krav 6-8 kræver mest arbejde at tilføje bagefter, så planlæg dem tidligt. Planlægger du hele produktet, så start med min guide til at bygge en SaaS, og brug listen som teknisk bilag.

Er du databehandler eller dataansvarlig?

Når dine kunder lægger oplysninger om deres medarbejdere eller kunder ind i din SaaS, er de dataansvarlige, og du er databehandler, der kun må bruge data efter deres instruks. Datatilsynet forklarer forskellen på dataansvarlig og databehandler. For dine egne kunders brugerkonti og fakturering er du selv dataansvarlig.

Som databehandler skal du have en databehandleraftale med hver kunde efter artikel 28 i databeskyttelsesforordningen. Datatilsynet har en standardskabelon til databehandleraftaler. Aftalen lover typisk sikkerhed, hjælp med de registreredes rettigheder, sletning ved ophør og underretning ved brud. Tjeklisten sikrer at koden kan holde de løfter.

Data og adgang: krav 1-5

1. Du ved hvilke data der ligger hvor

Lav et datakort over tabeller og felter med persondata, uploadede filer og de tjenester der får en kopi, fx fejlrapportering og søgeindeks. Som databehandler skal du også føre en fortegnelse over de behandlinger du udfører for dine kunder (artikel 30, stk. 2). Uden kortet kan du hverken eksportere eller slette ordentligt.

2. Kunderne er adskilt i koden

Den alvorligste fejl i en SaaS er at kunde A kan se kunde B's data. I en fælles database skal hver forespørgsel filtreres på kunde-id, helst automatisk. Modellerne gennemgår jeg i min forklaring af multi-tenant-arkitektur. Skriv tests der prøver at hente en anden kundes data, og kør dem ved hver ændring.

3. Kun den adgang der er nødvendig

I produktet betyder det roller, og her kan du se hvordan du designer brugerroller og rettigheder. Bag produktet betyder det tofaktorgodkendelse på hosting, database og kodearkiv, personlige konti og adgang der lukkes samme dag en udvikler stopper. Skal supporten se en kundes konto, så byg en "log ind som"-funktion der logges.

4. Kryptering i transit og i hvile

HTTPS er standard. Tjek at database, filer og backups også er krypteret, hvilket de fleste større hostingudbydere tilbyder. Særligt følsomme felter, fx CPR-numre eller kundens API-nøgler, bør krypteres i applikationen. I Laravel klarer den indbyggede encrypted-cast det.

5. Audit-log over adgang og ændringer

En audit-log registrerer hvem der gjorde hvad og hvornår: login, eksport, sletning, ændrede rettigheder og supportens adgang til kunders konti. Med den kan du svare, når en kunde spørger om nogen har set deres data. Hold den adskilt fra de almindelige logfiler, som aldrig må indeholde adgangskoder eller tokens.

Eksport og sletning: krav 6-9

6. Eksport til brugeren og kunden

De registrerede har ret til indsigt (artikel 15) og til at få deres data udleveret i "et struktureret, almindeligt anvendt og maskinlæsbart format" (artikel 20), og du skal hjælpe din kunde med at opfylde det. Byg eksport af én bruger og af hele kundens konto, fx JSON eller CSV i en zip-fil. Den dataansvarlige har som udgangspunkt en måned til at svare (artikel 12, stk. 3), så en beskrevet manuel proces kan holde i starten.

7. Sletning af en bruger

Sletningen skal ramme database, filer, søgeindeks, cache og tredjeparter som mail- og supportsystemer. Soft delete, hvor rækken kun markeres som slettet, er ikke nok alene. Brug en kort fortrydelsesperiode og derefter et job der sletter permanent eller anonymiserer. Skal noget gemmes af lovkrav, fx bogføringsmateriale, så dokumentér hvorfor.

8. Sletning når en kunde stopper

Når aftalen ophører, skal du slette eller udlevere kundens data efter kundens valg (artikel 28, stk. 3, litra g). Det kræver eksport, en aftalt frist og et job der sletter hele kontoen. Backups er det svære punkt: lad dem udløbe efter en fast periode, fx 30 dage, sørg for at slettede data ikke vender tilbage ved en gendannelse, og skriv perioden ind i aftalen.

9. Faste opbevaringsperioder

Data må ikke gemmes længere end nødvendigt (artikel 5, stk. 1, litra e). Byg det som planlagte job: slet ubekræftede konti, ryd op i prøveperioder der aldrig blev til kunder, og slet logfiler efter en fast periode. Skriv reglerne ned ét sted, så de kan stå i databehandleraftale og privatlivspolitik.

Leverandører, backup og beredskab: krav 10-14

10. En liste over underdatabehandlere

Hosting, filopbevaring, mailudsendelse, fejlrapportering, supportsystem, statistik og AI-tjenester er typisk alle underdatabehandlere. Din kunde skal have godkendt dem, og ved en generel godkendelse skal du varsle ændringer, så kunden kan gøre indsigelse (artikel 28, stk. 2). Lav en liste med navn, formål og placering. Sender du data til en sprogmodel, så læs om GDPR og AI.

11. Dataplacering og overførsler

GDPR kræver ikke at data bliver i EU, men en overførsel til fx USA skal have et grundlag. EU-Kommissionen vedtog 10. juli 2023 en afgørelse om EU-US Data Privacy Framework for amerikanske virksomheder der deltager i ordningen. Ellers bruges typisk standardkontrakter. Nogle erhvervskunder kræver at data ligger i EU, og mulighederne sammenligner jeg i min oversigt over hosting af SaaS.

12. Backup der er testet

Artikel 32 nævner evnen til rettidigt at genoprette adgangen til data efter en hændelse. Det kræver automatiske, krypterede backups, opbevaret adskilt fra produktionen. Datatilsynet anbefaler i sit katalog over sikkerhedsforanstaltninger at teste at data kan genindlæses og bruges. Skriv ned hvor lang tid en gendannelse tager, for det spørger større kunder ofte om.

13. Opdag brud, og underret hurtigt

Som databehandler skal du underrette kunden uden unødig forsinkelse (artikel 33, stk. 2), fordi kunden om muligt skal anmelde bruddet til Datatilsynet inden 72 timer (artikel 33, stk. 1). Det kræver fejlrapportering, alarmer ved usædvanlig aktivitet som masseeksport, og en kort plan for hvem der kontakter hvem.

14. Testmiljøer uden rigtige data

En kopi af produktionsdatabasen på en udviklers computer er en nem måde at miste kontrollen over persondata på. Brug seed-data og factories med opdigtede data. Skal en fejl genskabes med rigtige data, så gør det i et miljø med samme adgangskontrol som produktion, og slet kopien bagefter.

Hvornår du ikke skal bruge penge på det hele endnu

Tester du en idé med få pilotkunder, så fokusér på adskillelse, adgang, kryptering og backup. Eksport og sletning kan starte som en beskrevet manuel proces. Men sæt kunde-id på alle tabeller med kundedata fra første dag, for det er dyrt at rette senere.

Har dit team allerede styr på kravene, behøver du ikke en udvikler som mig. Og er dit spørgsmål juridisk, er det en advokat eller GDPR-rådgiver du skal tale med.

Næste skridt

1. Lav datakortet fra krav 1. Det viser hvor hullerne er.
2. Markér hvert krav som på plads, delvist på plads eller mangler.
3. Prioritér adskillelse, adgang og backup, og planlæg eksport og sletning før din første større kunde.

Vil du have hjælp til en SaaS hvor kravene er tænkt ind fra start, så se hvordan jeg arbejder med SaaS-udvikling. Du taler direkte med mig og ejer koden fra dag ét.

Ofte stillede spørgsmål

Gælder GDPR, hvis min SaaS kun har erhvervskunder?+

Ja. En erhvervs-SaaS indeholder næsten altid persondata, fx medarbejdernes navne og e-mails, kontaktpersoner og IP-adresser i logfiler. Det er nok til at forordningen gælder. Oplysninger om selve selskabet, fx CVR-nummer og adresse, er ikke persondata, men oplysninger om de personer der arbejder der, er.

Skal en SaaS-virksomhed have en databeskyttelsesrådgiver (DPO)?+

Kun i bestemte tilfælde. Efter artikel 37 kræves en DPO, når kerneaktiviteten er regelmæssig og systematisk overvågning af personer i stort omfang, eller behandling af følsomme oplysninger i stort omfang. De fleste små erhvervs-SaaS falder uden for, men tjek det med en rådgiver, hvis du håndterer fx helbredsdata.

Kræver større kunder en ISO 27001-certificering?+

GDPR kræver ingen certificering, men nogle større kunder og offentlige udbud spørger efter ISO 27001, en SOC 2-rapport eller et sikkerhedsspørgeskema. For en ny SaaS er en certificering sjældent pengene værd. Start med datakort, liste over underdatabehandlere, en beskrivelse af dine sikkerhedsforanstaltninger og din plan ved brud.

Skal min SaaS have et cookiebanner?+

Kun hvis du bruger cookies eller lignende teknologier, som ikke er strengt nødvendige. En sessionscookie til login kræver ikke samtykke. Statistik, session replay og markedsføringspixels kræver det som udgangspunkt, også bag et login. Vælg cookiefri statistik, eller spørg om samtykke før værktøjerne indlæses.