Cloud og databehandling: Sådan vurderer du leverandører efter GDPR og DPA-krav

Start med behandlingen, ikke leverandøren

Inden du sammenligner leverandører, skal du kunne redegøre for den behandling, der flyttes til skyen: hvilke kategorier af personoplysninger (almindelige, følsomme, CPR-numre), hvilke grupper af registrerede, formålet, retsgrundlaget, opbevaringsperioden, hvor oplysningerne ligger fysisk og logisk, og hvem der kan få adgang. Datatilsynets vejledning om cloud fra marts 2022 sætter rammen med overskrifterne »Kend dine services« og »Kend dine leverandører«. Kendskab til tjenesten og leverandørens rolle er en forudsætning for vurderingen – en underskrevet aftale erstatter den ikke.

Kortlægningen skal følge dataene ind i tjenesten, ikke stoppe ved aftalen. En SaaS-tjeneste kan samtidig behandle flere spor for dig: data brugerne selv lægger ind, metadata og logninger, supportbilag du sender til leverandøren, og telemetri fra klienter og apps. Hvert spor skal med, fordi formål, opbevaring og adgang typisk er forskellige.

At kendskabet til den konkrete behandling er afgørende, viser Chromebook-/Helsingør-sagen: Datatilsynet afventede tilfredsstillende svar fra Helsingør og Google på præcis, hvilke data Google behandler, og hvordan. Sagen fortsatte med en suspension af det oprindelige forbud mod at bruge Chromebooks i skolerne. Uden et præcist svar på, hvad leverandøren gør ved oplysningerne, kan hverken risikovurdering eller aftale lande.

SaaS, PaaS eller IaaS: Hvad ændrer ansvaret?

SaaS (Software as a Service) kender de fleste: Microsoft 365, Google Workspace, Dinero, e-conomic og lignende. Leverandøren står for alt fra infrastruktur til applikationen; du logger ind og bruger den. Udbyderen er ansvarlig for, at platformen er sikker; du er ansvarlig for, hvem der har adgang, og hvordan tjenesten bruges. For langt de fleste danske små og mellemstore virksomheder giver modellen den bedste sikkerhedsprofil for pengene – men den flytter ansvaret, den fjerner det ikke.

PaaS (Platform as a Service) er relevant, når I selv bygger software eller digitale services. Leverandøren stiller infrastruktur og udviklingsplatform til rådighed, mens din kode og dine data er dit ansvar. IaaS (Infrastructure as a Service) er mest fleksibel og mest krævende: du lejer virtuelle servere hos for eksempel Amazon Web Services, Microsoft Azure eller Google Cloud, leverandøren sikrer den fysiske infrastruktur, og alt derover – operativsystem, netværkskonfiguration, adgangsstyring og patchning – er dit.

For leverandørvurderingen betyder det, at spørgsmålene skal målrettes mod modellen. I SaaS ligger hovedparten af spørgsmålene om platformens sikkerhed hos leverandøren, og dine egne handler om konfiguration, rettigheder og brug. I IaaS ligger patchning, netværkssegmentering, kryptering og logning hos dig, og leverandøren kan ikke svare på dine vegne. Samme leverandør kan derfor være tilstrækkeligt dokumenteret for én tjeneste og ikke for en anden i sin portefølje.

Delt ansvar: dataansvarlig, databehandler og dine egne pligter

Rollefordelingen er udgangspunktet: virksomheden er dataansvarlig, og cloudleverandøren er som udgangspunkt databehandler, der behandler personoplysninger efter instruks. Alle de store udbydere beskriver den delte ansvarsmodel eksplicit i deres dokumentation: leverandøren tager sikkerheden i skyen, kunden tager sikkerheden i sit brug af skyen.

Leverandøren sikrer fysisk datacenteradgang, netværksinfrastruktur, hypervisor-laget og den grundlæggende platform. Du står for det, der oftest går galt: hvem der har adgang, hvilke rettigheder de har, om filer og links deles bredere end nødvendigt, om der logges nok til at efterprøve hændelser, og om supportadgang er styret. Delt ansvar er ikke en ansvarsfraskrivelse i aftalen, men en arbejdsdeling, du skal kunne påvise at I løfter.

Grænsen mellem rollerne er ikke statisk. Behandler leverandøren oplysningerne til egne formål – produktudvikling, analyse eller telemetri, der ikke er nødvendig for at levere tjenesten til dig – er leverandøren ikke uden videre kun databehandler. Det var præcis den uafklarethed, Datatilsynet efterspurgte svar på i Helsingør-/Google-sagen: hvilke data behandles, og hvordan.

Databehandleraftalen: fra standardtekst til reel vurdering

Databehandleraftalen er omdrejningspunktet. Datatilsynets vejledning peger på indgåelse af en databehandleraftale som et område, den dataansvarlige skal have styr på, og cloudkunderne har det primære ansvar for, at aftalen matcher den behandling, virksomheden faktisk udfører.

Vurderingen har to led. Først om aftalen dækker din behandling: formål og instruks, underdatabehandlere og procedurer for ændringer i dem, sletning eller tilbagelevering ved aftalens ophør, bistand til de registreredes rettigheder, sikkerhedsforanstaltninger, underretning om brud på persondatasikkerheden og revisions- eller kontrolmuligheder. Dernæst om praksis hænger sammen med aftalen: Når aftalen forudsætter indsigt eller revision, skal du vide hvordan og i hvilket format; når sletning er aftalt, skal du kunne se, at den sker, også i backup og hos underdatabehandlere.

En standardaftale, der er skrevet til leverandørens produkt for alle kunder på én gang, kan sjældent stå alene. Læs den som et tilbud, ikke en konklusion: Hvilke valg har I reelt, hvad er leverandørens forbehold, og hvilke af dine pligter som dataansvarlig – fortegnelse, oplysningspligt, konsekvensanalyse ved høj risiko – dækker aftalen ikke, men henviser tilbage til dig?

Adgang fra tredjelande og overførsler ud af EU/EØS

Overførsel til tredjelande er et selvstændigt punkt i Datatilsynets vejledning; myndigheden har desuden en særskilt vejledning om 3.landsoverførsler, en temaside og spørgsmål og svar om cloud. Overførsler skal derfor kortlægges for sig: hvor ligger datacentrene, hvilke underleverandører indgår i driften, er der support- eller driftsadgang fra lande uden for EU/EØS, og hvordan får du besked, når leverandøren ændrer sit setup?

Kortlægningen skal skelne mellem lagring og adgang. Det er ikke nok, at data lagres i EU, hvis en supportfunktion i et tredjeland kan tilgå dem, eller hvis en underleverandør behandler dem som led i overvågning, backup eller fejlfinding. Både planlagte overførsler og den adgang, der følger af driftsmodellen, skal med, og vurderingen skal gentages, når leverandøren ændrer datacenterplacering, underleverandører eller supportorganisation.

Overførselsgrundlagets betydning er understreget af sagen, hvor Max Schrems klagede over Facebook/Meta, og det irske datatilsyn suspenderede alle overførsler til USA og gav en bøde på omkring 9 milliarder danske kroner. En lang række afgørelser og vejledninger om forholdet mellem EU's persondataregler og cloudbranchen går efterhånden mere end 10 år tilbage. For den enkelte virksomhed betyder det, at overførselsgrundlaget ikke kan behandles som en formalitet i aftalen, men skal kunne dokumenteres konkret for den tjeneste, du tager i brug – og for de underleverandører, der reelt får adgang.

Risikovurdering og løbende tilsyn

Datatilsynets vejledning beskriver, hvilke momenter der bør indgå i vurderingen af, hvordan og hvor hyppigt du fører tilsyn med leverandører – herunder et afsnit om intensitet. Tilsyn er ikke at gøre det samme hver gang, men at kalibrere efter risiko.

Kalibrer intensiteten efter: hvilke kategorier af personoplysninger der behandles, hvor mange registrerede det drejer sig om, hvor kritisk tjenesten er for driften, hvor lang og uigennemsigtig underleverandørkæden er, og hvor ofte leverandøren ændrer sit setup. En tjeneste med følsomme oplysninger eller mange registrerede bør følges tættere end en tjeneste uden personoplysninger; et system, der hyppigt skifter underleverandører eller infrastruktur, oftere end et stabilt.

Tilsynet bør bestå af konkrete handlinger med fast kadence og en navngiven ansvarlig: gennemgang af hændelsesrapporter og ændringsnotifikationer, opfølgning på leverandørens sikkerhedsdokumentation, egne kontroller af rettigheder, deling og logging i tjenesten samt en periodisk prøve af, om I faktisk kan trække data ud og komme ud af aftalen. Datatilsynet har et spørgeskema ved tilsyn med cloud, som kan strukturere gennemgangen, så den bliver sammenlignelig fra gang til gang.

Dokumentation og spørgsmål til leverandøren

Når vurderingen skal omsættes til handling, skal leverandøren levere dokumentation – ikke henvisninger. Bed om en beskrivelse af dataflowet for den konkrete tjeneste: hvilke oplysninger behandles, til hvilke formål, hvor lagres de, hvilke underleverandører er involveret, og hvorfra kan der opnås adgang. Bed om en opdateret liste over underdatabehandlere med placering, og om hvordan I varsles, før listen ændres.

Bed også om dokumentation for sikkerheden i den del af den delte model, leverandøren står for: kryptering, adgangsstyring på leverandørens side, logning, hændelseshåndtering, patch- og ændringsrutiner samt sletning og tilbagelevering, herunder i backup. Spørg konkret til, hvordan sletning kan dokumenteres over for dig, og hvordan brud på persondatasikkerheden rapporteres til dig, så du kan opfylde din egen underretningspligt.

Brug Datatilsynets spørgeskema ved tilsyn med cloud som udgangspunkt for forespørgslen, så spørgsmålene er de samme for alle leverandører og kan sammenlignes. Svarene – eller manglen på svar – er beslutningsgrundlaget: Hvert ubesvaret punkt er en risiko, du selv bærer som dataansvarlig, og din dokumentation bør vise, hvad der er afklaret, og hvad der ikke er.

Fra tjekliste til beslutning

Saml vurderingen i fire kriterier, der vejes mod virksomhedens behov: om tjenesten er egnet til den behandling, du skal bruge den til (leverancemodel, konfigurationsmuligheder, hvor oplysningerne ligger), hvilke risici der er identificeret, om leverandøren kan dokumentere det, de påstår – herunder overførselsgrundlag, sletterutiner og sikkerhed – og hvilke exitmuligheder du reelt har. Hvert kriterium bør ende i et af tre udfald: accept, accept med supplerende foranstaltninger på din side eller afvisning.

Exitmuligheden er et selvstændigt kriterium, ikke en eftertanke: Kan I trække jeres data ud i et anvendeligt format, inden for hvilken frist, og hvilke dele af konfigurationen og historikken følger med? Kan I ikke svare på det, bør det trække ned i vurderingen af selv en i øvrigt velfungerende tjeneste, fordi manglende udtræksmulighed binder jer til leverandørens vilkår på lang sigt.

Beslutningen skal dokumenteres, så den kan genbesøges. Notér i jeres fortegnelse, hvilken tjeneste der er vurderet, hvilket grundlag vurderingen bygger på, hvilke foranstaltninger I selv har påtaget jer i den delte model, hvornår næste tilsyn skal gennemføres, og hvad der ville udløse en ny vurdering – for eksempel ændringer i datacenterplacering, underleverandører eller supportadgang. Afvisning er også et resultat, der skal begrundes: Kan leverandøren ikke dokumentere overførselsgrundlag, adgangsforhold eller sletterutiner for den konkrete tjeneste, skal du kunne redegøre for det over for de registrerede og tilsynsmyndigheden.