Foto til artiklen Vurder exit og GDPR-dataportabilitet hos cloudleverandører
Foto af ferarcosn på Pixabay

Cloud og hosting

Vurder exit og GDPR-dataportabilitet hos cloudleverandører

Artikel 20 i databeskyttelsesforordningen giver den registrerede ret til en kopi af de personoplysninger, vedkommende selv har afgivet til en dataansvarlig.

Dette er et redaktionelt pseudonym for udgivelsen, ikke en påstand om en uafhængigt verificeret personlig identitet. Oprindelig redaktionel kreditering: Redaktion Infrastruktur.

Afgræns dataportabilitet fra den samlede exit-forpligtelse

Artikel 20 i databeskyttelsesforordningen giver den registrerede ret til en kopi af de personoplysninger, vedkommende selv har afgivet til en dataansvarlig. Kopien skal leveres i et almindeligt anvendt og maskinlæsbart format. Den registrerede kan også kræve oplysningerne overført direkte til en anden dataansvarlig uden hindring, hvis det er teknisk muligt.

Retten kræver to ting: oplysningerne behandles automatisk på grundlag af samtykke eller kontrakt, og den registrerede har selv aktivt afgivet dem. Data, som leverandøren selv genererer — logninger, afledte beregninger, driftsmetadata — og data, der behandles på et andet grundlag, falder uden for retten.

Exit-forpligtelsen er større og kontraktlig. Den skal dække hele kundens datamængde, herunder metadata, konfiguration, historik og integrationer, og forhandles ind i aftalen med leverandøren.

Forskellen betyder noget i praksis: den registrerede kan håndhæve artikel 20 over for den dataansvarlige. Den dataansvarlige kan ikke bruge artikel 20 som hjemmel til at kræve hele virksomhedens opsætning udleveret. Planlæg derfor to spor — ét til de registreredes rettigheder og ét til virksomhedens egen drift ved et leverandørskifte.

Retten har også et markedsformål: ved at lette skift mellem platforme modvirker den lock-in og konkurrenceforvridning. Overholdelse kan derfor være en konkurrenceparameter i sig selv.

Forskelle mellem artikel 20 og virksomhedens exit-forpligtelse

  • Ret til dataportabilitet (Artikel 20)Kun personoplysninger, der er afgivet af den registrerede, og som behandles automatisk på grundlag af samtykke eller kontrakt.
  • Exit-forpligtelse for virksomhedDækker hele kundens datamængde: metadata, konfiguration, logs, backup, integrationer og historik.

Kortlæg data, integrationer og afhængigheder før opsigelse

Del løsningen i mindst seks kategorier og behandl dem hver for sig. Det gælder personoplysninger afgivet af de registrerede; metadata og afledte data; konfiguration (roller, felter, workflows, skabeloner); logs og revisionsspor; backup; og integrationer (API'er, webhooks, enkelt-sign-on, identitetsstyring). For hver kategori skal du notere, om den er omfattet af artikel 20, om den kan eksporteres, om den kan genskabes i et nyt miljø, eller om den reelt ikke kan flyttes.

Afhængighederne blokerer typisk skiftet: integrationer til andre systemer, proprietære formater, objektlagring med leverandørspecifikke referencer, brugeridentiteter bundet til leverandørens domæne samt licens- og volumenbindinger. Byg et register, hvor hver datakategori har en intern ejer, et anslået volumen, en opbevaringsfrist og en konkret exit-metode. Registret skal du senere bruge til at dokumentere både migreringen og sletningen.

Kortlægning af datakategorier og afhængigheder før opsigelse

  • Personoplysninger afgivet af registreredeOmfattet af artikel 20? Ja/Nej
  • Metadata og afledte dataKan eksporteres? Kan genskabes i nyt miljø?
  • Konfiguration (roller, workflows, skabeloner)Er det teknisk muligt at migrere?
  • Logs og revisionssporHvordan håndteres sletning og arkivering?
  • BackupHvor ligger de, og hvordan sikres overførsel?
  • Integrationer (API'er, SSO, webhooks)Er de afhængige af leverandørens domæne?

Vurder eksportformat og muligheden for direkte overførsel

Artikel 20 kræver et almindeligt anvendt og maskinlæsbart format. CSV og XML er eksempler på sådanne formater; vælg en eksport, hvor strukturen bevares, frem for PDF, regneark med ødelagt struktur eller skærmbilleder.

Test eksporten på fire punkter: Kan feltmapping til modtagerens skema laves uden manuel omskrivning? Følger vedhæftninger og binære filer med? Bevares historik og versionsspor? Hænger relationer mellem poster — fx kunde, sag og dokument — stadig sammen efter import?

Kontrollér desuden tegnsæt, dato- og talformater og feltlængder. Kør altid en prøveeksport på et repræsentativt udsnit før opsigelsen.

Hold testen af direkte overførsel adskilt fra virksomhedens samlede migrering: Artikel 20 giver den registrerede ret til overførsel til en anden dataansvarlig uden hindring, hvis det er teknisk muligt.

Afklar derfor i aftalen, om leverandøren stiller API-baseret overførsel til rådighed eller kun fileksport, hvem der etablerer forbindelsen til det nye miljø, og hvordan fejlede poster håndteres.

Hvis eksporten kun kan bruges efter manuel omskrivning, er den reelt ikke portabel. Dokumentér det som en exit-risiko med tal for, hvor mange poster der fejler import, og hvad den manuelle efterbehandling kræver i tid.

Fordele og udfordringer ved direkte overførsel via API vs. file-eksport

  • Direkte overførsel via APIPro: Automatisk, struktureret, mindre manuel efterbehandling. Con: Kræver teknisk forbindelse og koordinering med ny leverandør.
  • File-eksport (CSV/XML)Pro: Enkel at implementere. Con: Høj risiko for mangler i feltmapping, historik og relationer; ofte kræver manuel omskrivning.

Afklar tredjelandsoverførsler og underleverandørkæden

Datatilsynet læser forordningens artikel 44 som en forpligtelse for både den dataansvarlige og databehandleren. Begge skal sikre, at overførslen sker i overensstemmelse med databeskyttelsesreglerne.

Begrebet »dataeksportør« er ikke defineret i forordningen, men i EU-Kommissionens standardkontrakt. Her betyder det »den dataansvarlige eller databehandleren, der overfører personoplysningerne til et tredjeland«.

Den konstruktion, der især har skabt tvivl, er en europæisk dataansvarlig, der bruger databehandlere i EU/EØS, men hvor en eller flere af disses underdatabehandlere ligger uden for EU/EØS.

Kortlæg derfor fire ting: hvor data primært hostes, hvorfra support og drift kan tilgå dem, hvor backup ligger, og hvilke underdatabehandlere der indgår.

Datatilsynets cloudvejledning blev offentliggjort den 9. marts 2022 med et afsnit om Schrems II-dommen af 16. juli 2020 og en gennemgang af overførsler til USA.

Efter tilsynets egne ord beskriver vejledningen både faldgruber, muligheder og forpligtelser. Tilsynet nedsatte samtidig en ekspertgruppe, der skal undersøge mulige tiltag for at gøre brug af cloudløsninger lovlig.

Under en exit er kæden særligt sårbar: migrationsværktøjer, supportadgang, testkopier og midlertidig parallel drift kan skabe nye overførsler, netop som leverandørkæden er under forandring. Medtag derfor også den nye leverandørs underdatabehandlere i kortlægningen, ikke kun den hidtidiges.

Test overførselsgrundlaget mod den konkrete leverandørkæde

Tre hovedveje fører data ud af EØS: en tilstrækkelighedsbeslutning, standardkontraktbestemmelser eller bindende virksomhedsregler.

Standardkontrakterne, opdateret i juni 2021, er den mest udbredte mekanisme. EU-US Data Privacy Framework erstattede det ugyldiggjorte Privacy Shield. Organisationsstatus bør følges løbende, fordi grundlaget kan falde bort.

Standardkontrakten er modulopbygget til forskellige overførselsscenarier. En databehandler i EU kan efter instruks fra sin dataansvarlige indgå den direkte med underdatabehandlere i tredjelande.

I så fald er det databehandleren, der betegnes som dataeksportør, og som sammen med underdatabehandleren er direkte forpligtet af standardkontraktbestemmelserne.

En underskrevet standardkontrakt er ikke nok. De anbefalinger fra Det Europæiske Databeskyttelsesråd, der blev omtalt i november 2020, fastslog, at den dataansvarlige også skal sikre, at overførslen lever op til EU's databeskyttelseskrav. Ellers skal der gennemføres supplerende foranstaltninger.

Rådet kunne i den forbindelse ikke se, hvordan den dataansvarlige kan gøre tilstrækkeligt ekstra for at beskytte data, der sendes til et usikkert tredjeland som USA eller Indien.

Testen skal gennemføres mod den konkrete kæde, ikke kun i den daglige drift.

Gennemgå, hvilket modul og hvilke parter der er dækket. Kontrollér, om supplerende foranstaltninger er beskrevet og operationelle: kryptering, nøglehåndtering, adgangsstyring og logning af supportadgang. Kontrollér også, om grundlaget holder i exit-fasen — under hjemtagning til eget miljø, under overførsel til den nye leverandørs miljø og under en periode med parallel drift.

Hvis grundlaget ikke kan opretholdes for en underdatabehandler i tredjeland, er det en exit-blokering, der skal løses før opsigelsen, ikke efter.

Læs exit-vilkår, assistance og tidsfrister i aftalen

Gennemgå aftalen på disse punkter: forpligtelse til at eksportere i et specificeret format inden for en nærmere angivet frist; varigheden og prisen på en overgangsperiode; muligheden for parallel drift i begge miljøer.

Kontrollér også, om teknisk bistand er inkluderet eller faktureres efter medgået tid; pris og kvote for API-adgang og bulk-eksport; sletning efter perioden; samt hvad der sker med data, der ikke kan eksporteres, fx proprietære objekter og leverandørafhængig historik.

Forrester beskriver konkrete vilkår at kontrollere: AWS annoncerede planer om at fjerne egress-gebyrer ved migrering til en anden cloududbyder eller on-premises, men kræver 60 dages exit og fuld fjernelse af data og workloads. Google Clouds egress-kreditter gælder én flytning og kræver fuld exit og lukning af kontoen inden for en 60-dages migreringsperiode; Microsoft Azure annoncerede fjernelse af dataoverførselsgebyrer ved annullering eller sletning af et Azure-abonnement (Forrester). Brug oplysningerne som kontrolspørgsmål mod vilkårene i den konkrete aftale.

Afklar desuden, hvilken serviceforpligtelse der gælder for selve eksporten, og hvor hurtigt fejl rettes.

Skeln skarpt mellem de to sæt vilkår. Rettighederne efter artikel 20 dækker kun personoplysninger, som den registrerede selv har afgivet, og som behandles automatisk på grundlag af samtykke eller kontrakt.

Metadata, konfiguration, logs, backup og integrationshistorik er ikke omfattet og er derfor rene kommercielle exit-vilkår.

Er aftalen tavs om dem, har I ingen håndhævelig ret til et bestemt format eller til bistand. Netop de dele afgør ofte, om et skift kan gennemføres i praksis.

Adskil migrering fra sletning, og dokumentér begge spor

Dataportabilitet udløser ikke sletning. Oplysningerne slettes ikke automatisk hos den første dataansvarlige, og organisationen kan fortsat opbevare dem, medmindre den registrerede udtrykkeligt anmoder om retten til sletning.

Selv uden en sådan anmodning må den første dataansvarlige ikke opbevare oplysningerne længere end nødvendigt og kun til legitime formål. Sletning skal derfor håndteres som en selvstændig aktivitet i exit-planen.

Før to spor med hver sin dokumentation. Migreringssporet: kvittering for modtagne data, antal poster og filer, kontrolsummer, resultat af importtest og skriftlig accept fra forretningsejeren af de enkelte datakategorier.

Sletningssporet: hvad der er slettet, hvornår og hvordan, hos leverandøren og dennes underdatabehandlere, hvordan backup og arkivbånd håndteres, og hvilke opbevaringsperioder der fortsat gælder.

Uden dokumentationen risikerer data at blive liggende efter exit uden et formål eller grundlag, der kan redegøres for.

Saml vurderingen i en exit-beslutningsmatrix

Sæt fundene ind i én matrix med en række pr. datakategori og komponent: personoplysninger afgivet af de registrerede, metadata og afledte data, konfiguration, logs, backup og integrationer.

Kolonnerne bør være: omfattet af artikel 20 (ja/nej), eksportformat, kan migreres direkte (ja/nej/delvist), ansvarlig part (leverandør, underdatabehandler, os selv), overførselsgrundlag for den konkrete overførsel, tidsfrist, omkostning og fallback.

Matricen samler, hvad der kan flyttes, hvad der ikke kan, og hvem der hæfter for hvad.

Omsæt matrixen til beslutningsregler. Kan eksporten kun bruges efter manuel omskrivning, så forhandl et alternativ frem eller planlæg en længere overgangsperiode med parallel drift.

Kan overførselsgrundlaget ikke opretholdes for underdatabehandlere uden for EU/EØS, må I enten hjemtage dataene eller vælge en leverandør, hvor behandlingen kan dokumenteres inden for EU/EØS.

Kan sletning ikke verificeres og dokumenteres, skal der indhentes skriftlig bekræftelse før endelig accept af exit.

Mangler aftalen forpligtelser til format, frist og bistand, er det et forhandlingspunkt, der skal lukkes, før opsigelsen sendes.

Fallback-mulighederne er en forlænget overgangsperiode, manuel eksport af de kritiske datakategorier i god tid før opsigelse, eller at skiftet udskydes, indtil blokeringerne er løst.

Mere fra Cloud og hosting