Teknologiadoption

Databehandleraftaler ved cloudkøb: Hvilke punkter bør danske indkøbere kontrollere?

Begynd med jeres eget kendskab til løsningen.

Forstå cloud-løsningen og dataflowet først

Begynd med jeres eget kendskab til løsningen. Datatilsynet har udgivet en vejledning om cloud, og et af de første punkter er, at cloud ikke bare er cloud: Leverancemodellen afgør, hvor meget af sikkerheden og behandlingen I selv konfigurerer, og hvor meget udbyderen står for. Ved infrastruktur som service (IaaS) får I adgang til infrastruktur og styrer selv en stor del; standardprodukter som Google Drev eller OneDrive er i højere grad færdige tjenester, hvor I køber et produkt, mange andre også bruger.

Lav en dataflowkortlægning, før I læser aftalen. Hvilke kategorier af personoplysninger behandles – almindelige oplysninger, følsomme oplysninger, CPR-numre? Til hvilke formål? Hvor opbevares og behandles data geografisk? Hvilke parter og systemer indgår? Og hvorfra kan leverandørens personale tilgå data ved support, drift og fejlretning? Kortlægningen er den målestok, I bagefter holder databehandleraftalen op imod.

Medregn samspillet mellem flere tjenester. Kombinerer I fx skylagring med et SaaS-system og et backupværktøj, kan de samme personoplysninger ligge hos flere udbydere med hver sit aftalegrundlag og hver sin kæde af underleverandører. Det giver flere steder, hvor behandlingsgrundlag, adgang og sletning skal være styr på.

Cloud-leverancemodeller: IaaS vs. SaaS – sikkerhed og ansvar

  • Infrastruktur som Service (IaaS)
  • Software som Service (SaaS)fx Google Drev, OneDrive

Kontroller at databehandleraftalen foreligger og dækker cloud-leverancen

Kravet om en databehandleraftale følger af databeskyttelsesforordningens artikel 28, stk. 3. Cloud-løsninger behandler typisk personoplysninger for jer og er derfor databehandlere, så der skal indgås en databehandleraftale. Kontroller først, at aftalen faktisk foreligger – eller at leverandørens standardvilkår er accepteret på en måde, I kan dokumentere med dato og version. Lav en intern oversigt over, hvilke leverandører der har en databehandleraftale, og hvilke der mangler.

Hold aftalen op mod jeres kortlægning. Den skal beskrive behandlingens formål og varighed, arten af behandlingen, typerne af personoplysninger, kategorierne af registrerede samt leverandørens forpligtelser og jeres instrukser. Er aftalen kun en generel standardtekst uden at nævne den konkrete cloud-løsning eller de konkrete behandlinger, I har købt, er det uafklaret, om den reelt dækker behandlingen.

Datatilsynets cloud-vejledning peger på fem områder, du som dataansvarlig skal have styr på: kendskab til cloud-løsningen, indgåelse af databehandleraftalen, tilsyn med cloud-leverandøren, risikovurderingen og overførsler til tredjelande. Brug dem som tjekliste, og verificér hvert punkt mod den faktiske leverance.

Tjekliste til databehandleraftaler ved cloudkøb

  • Aftalen foreligger og er dokumenteret med dato og version
  • Aftalen beskriver behandlingens formål, varighed og art
  • Aftalen nævner konkrete personoplysninger og kategorier af registrerede
  • Aftalen specificerer leverandørens forpligtelser og jeres instrukser
  • Aftalen dækker den specifikke cloud-løsning og behandlinger købt

Gennemgå underdatabehandlere og kæden af parter

Store cloud-udbydere bruger typisk en række underdatabehandlere, ofte i tredjelande, så overførsel af data må forventes. Spørg derfor ikke kun, om der bruges underdatabehandlere, men hvem de er, hvad de udfører, og hvor de behandler data – herunder support, overvågning, sikkerhedstjenester og den infrastruktur, løsningen kører på.

Aftalepunkter, der bør stå i kontrakten: en liste over de aktuelle underdatabehandlere, en procedure for hvordan ændringer i listen varsles (kanal og frist), jeres ret til at gøre indsigelse mod en ny underdatabehandler, og hvad der sker, hvis I gør indsigelse. Kontroller også, at leverandøren viderefører de samme forpligtelser til sine underdatabehandlere, så kæden ikke knækker et led længere nede.

Praktisk: bed om listen som et dokument med dato – ikke kun et link til en hjemmeside, der kan ændres uden varsel – og noter, hvornår I sidst har fået den bekræftet. Underdatabehandlere i tredjelande udløser krav om overførselsgrundlag, så listen er samtidig indgangen til næste kontrolpunkt.

Gennemgang af underdatabehandlere og overførsler til tredjelande

  1. Bed om liste over aktuelle underdatabehandlere med dato
  2. Kontroller procedure for ændring i listen (varsling, frist, indsigelsesret)
  3. Sørg for at leverandøren viderefører forpligtelser til underdatabehandlere
  4. Overførsler til tredjelande kræver gyldigt overførselsgrundlag

Afstem overførselsgrundlag ved tredjelandsoverførsler

Overførsel af personoplysninger til tredjelande kræver et gyldigt overførselsgrundlag, fx en af Kommissionen truffet afgørelse om sikkerhedsniveauet eller Kommissionens standardkontrakter. Det er jer som dataansvarlige, der skal sikre, at grundlaget foreligger; opgaven kan ikke overlades til leverandøren.

Bed om dokumentation frem for forsikringer: hvilke lande data overføres til, hvilken mekanisme der anvendes for hver enkelt overførsel, hvilke enheder der er parter i standardkontrakterne, og hvordan I får besked, hvis overførslerne ændrer sig.

Retsstillingen omkring tredjelandsoverførsler har været præget af usikkerhed. Regelforum har i en dansk anbefaling om udfordringer ved cloud-tjenester peget på, at sager ved EU-Domstolen rejste tvivl om gyldigheden af eksisterende overførselsgrundlag og om omfanget af den risikovurdering, der påhviler den dataansvarlige. Konsekvensen er, at overførselsgrundlaget skal kontrolleres løbende – ikke kun ved kontraktindgåelsen.

Tag stilling til standardvilkår, når individuel forhandling ikke er mulig

Mange cloud-tjenester udbydes af store internationale, ofte amerikanske, virksomheder som Microsoft og Amazon. Regelforum beskriver, at det er yderst vanskeligt at forhandle individuelle kontrakter med disse selskaber, og at det samtidig kan være svært at få adgang til kontrol af deres databehandling, selv om den anses for at være i overensstemmelse med reglerne.

Del kravene op i tre grupper, før I går i forhandling: krav I ikke kan fravige (fx at der foreligger en databehandleraftale, og at der er et overførselsgrundlag, hvis data forlader EU), krav der kan opfyldes teknisk eller organisatorisk på anden måde (fx opbevaring inden for EU, kundestyret adgang, logning og dataminimering), og krav I kan opgive mod andre foranstaltninger. Opdelingen gør det tydeligt, hvornår en leverandør skal afvises, og hvornår I kan gå videre med kompenserende tiltag.

Afviser leverandøren en ændring, så dokumentér afvisningen og den kompenserende foranstaltning i en intern note med dato. Det er den dokumentation, I kan fremlægge, hvis Datatilsynet spørger, hvordan I har håndteret risikoen. Bemærk samtidig, at mindre udbydere ikke automatisk er lettere: Regelforum peger på, at også brugen af mindre udbydere af cloud-tjenester kan indebære databeskyttelsesretlige udfordringer.

Fastlæg tilsyn, kontroladgang og dokumentation

Datatilsynets cloud-vejledning formulerer det direkte: Jo mere der kan gå galt ved behandlingen hos databehandleren – jo større risiko – jo større krav stilles der til dit tilsyn. Tilsynet er ikke en frivillig gestus; det skal føres for at sikre, at databehandleren efterlever både de aftalte krav i databehandleraftalen og kravene i databeskyttelsesretten.

Aftal, hvordan tilsynet kan udføres i praksis: hvilken dokumentation leverandøren stiller til rådighed (fx uafhængige revisionserklæringer og certificeringer), om I kan få indsigt i behandlingen gennem spørgeskemaer eller rapporter, om der er adgang til revision med et nærmere aftalt varsel, og hvilke dele af behandlingen der eventuelt er undtaget.

Fastlæg internt, hvem der følger op, hvor ofte det skal ske, og hvordan tilsynet dokumenteres, så I kan vise, at det er ført. Lad frekvensen følge risikoen: hyppigere og mere indgående kontrol af behandlinger med mange eller følsomme oplysninger, sjældnere for behandlinger med lav risiko.

Risikovurdering og kontrolfrekvens efter datatypen

  • Høj risiko (følsomme oplysninger, CPR-numre)
  • Middel risiko (almindelige oplysninger)
  • Lav risiko (non-sensitive data)

Aftal leverandørens bistand til risikovurdering og DPIA

Databehandleren eller leverandøren skal bistå med oplysninger og dokumentation til jeres risikovurdering, herunder til en konsekvensanalyse (DPIA). Samtidig er det den dataansvarlige, der skal udarbejde risikovurderingen i forhold til de registreredes rettigheder – den opgave kan ikke skubbes over til leverandøren.

Skriv bistanden ind i aftalen: hvad leverandøren skal levere (beskrivelse af behandlingen, tekniske og organisatoriske sikkerhedsforanstaltninger, oplysninger om overførsler og underdatabehandlere, procedure ved sikkerhedsbrud), hvor hurtigt leverandøren skal svare, og i hvilket format. Uden svarfrister ender vurderingen med at stå stille i afventen på leverandørens dokumentation.

Er restrisikoen efter jeres vurdering fortsat høj, er Datatilsynet modtager – I skal altså kunne dokumentere, hvad der er gjort, og hvori den resterende risiko består.

Kontroller backup, sletning og adgangsstyring i cloudmiljøet

Kravene til persondata omfatter opbevaring, adgangsstyring og mulighed for sletning, og de skal håndteres i backup-setuppet – ikke kun i produktionssystemerne.

Backup-arkitekturen bør afspejle, hvad I skal kunne gendanne. 3-2-1-reglen – 3 kopier, 2 forskellige medier, 1 offsite – er et anerkendt minimum, og nyere anbefalinger udvider den til 3-2-1-1-0 med en uforanderlig (immutable) kopi og nultolerance for fejl ved testgendannelse; en uforanderlig kopi kan ikke krypteres eller slettes af en angriber. To forhold går igen i praksis: En backup, der ikke testes, er ikke en plan, og synkronisering – fx OneDrive eller Dropbox – er ikke en sikkerhedskopi, fordi ransomware krypterer alle spejlede kopier med det samme. Ansvaret for data i Microsoft 365 ligger hos jer selv: Platformen drives af Microsoft, men Exchange, Teams og SharePoint skal I selv sørge for backup af.

Sæt RPO og RTO efter behovet, ikke efter softwarens standardindstillinger – for mange SMV'er er daglig backup (RPO 24 timer) og en gendannelsestid på 4-8 timer et realistisk udgangspunkt. Aftal desuden, hvem hos leverandøren der kan tilgå jeres data, at adgangen logges, og hvordan personoplysninger slettes eller tilbageleveres ved aftalens ophør. Er det et krav i jeres setup, at data holdes inden for EU, skal det fremgå af aftalen – sammen med en databehandleraftale er det et af de punkter, I bør stille som krav, når I vælger cloud-leverandør.

Trin for trin til sikker backup og sletning i cloud

  1. Implementér 3-2-1-1-0-princip (inkl. uforanderlig kopi)
  2. Test gendannelsesplan løbendeingen test = ingen plan
  3. Undgå synkronisering som sikkerhedskopi (OneDrive/Dropbox)
  4. Aftal RPO og RTO baseret på virksomhedens behov
  5. Sørg for logning af adgang og sletning af data ved aftalens ophør

Mere fra Teknologiadoption

Prisudvikling

Totalomkostninger ved nye teknologier: Hvilke poster bør danske virksomheder regne med?

Totalomkostninger omfatter hele teknologiens levetid, ikke kun indkøbsprisen.

Teknologiadoption

Teknologiadoption i danske virksomheder: Behov, risiko og modenhed

Teknologiadoption er efterhånden et grundvilkår i danske virksomheder.