En overføringsvurdering, ofte kalt TIA, skal undersøke om den konkrete overføringen av personopplysninger har nødvendig beskyttelse. Den må bygge på hvem som mottar opplysningene, hvilke lover og hvilken praksis som kan påvirke dem, og om tiltakene faktisk virker i den aktuelle dataflyten. Et generelt notat om et land er sjelden tilstrekkelig som eneste grunnlag.
Datatilsynets veiledning om tilleggskrav til overføringsgrunnlag understreker at vurderingen må omfatte involverte aktører, infrastruktur og omstendighetene ved overføringen. EDPBs endelige anbefalinger 01/2020 beskriver arbeidet med supplerende tiltak. Arbeidsopplegget nedenfor hjelper dere å samle faktagrunnlaget og dokumentere en beslutning uten å utstede en generell godkjenning av et land eller en leverandør.
Avklar om overføringsreglene kommer inn
Kartlegg eksportør, importør, roller og hvor opplysningene er tilgjengelige. Fjerntilgang kan være relevant selv om serveren står i EØS. Identifiser hvilke juridiske enheter som utfører support, drift og andre oppgaver. Et konsernnavn er ikke presist nok når forskjellige selskaper har ulike roller og etableringssteder.
Start med oversikten over overføring til tredjeland for valg av riktig regelspor. Vurder om en relevant tilstrekkelighetsbeslutning dekker den aktuelle mottakeren og behandlingen, eller om et annet grunnlag er nødvendig. Denne artikkelen fastsetter ikke en aktuell landliste; status og omfang må kontrolleres i gjeldende primærkilder når beslutningen tas.
Beskriv overføringen før dere fyller ut risikofelter
Registrer hvilke opplysninger som overføres, hvilke grupper personer de gjelder og hvorfor overføringen er nødvendig. Angi om tilgang skjer løpende, ved konkrete supportsaker eller gjennom periodiske eksporter. Beskriv varighet, lagring, videreoverføring og om dataene foreligger i klartekst. Detaljene kan være avgjørende for hvilke lover og tiltak som er relevante.
Koble beskrivelsen til systemkartet. Ta med underdatabehandlere og tekniske forbindelser som ikke er synlige for vanlige brukere. En avtalepåstand om lagring i Europa må sammenholdes med support, sikkerhetsanalyse, feillogger og kopier. Skill bekreftede opplysninger fra spørsmål leverandøren ennå ikke har besvart.
Identifiser overføringsgrunnlaget presist
Hvis standard personvernbestemmelser brukes, må riktig avtale og modul identifiseres. Kontroller partene, databeskrivelsen og relevante bilag. Et signert dokument med feil mottaker eller et tomt sikkerhetsvedlegg beskriver ikke nødvendigvis den faktiske overføringen. Bruk arbeidsarket for SCC-bilag til den konkrete avtaleutfyllingen.
Skill overføringsgrunnlaget fra det alminnelige behandlingsgrunnlaget. Virksomheten må også kunne forklare hvorfor personopplysningene behandles og hvilke øvrige GDPR-krav som gjelder. En gyldig overføringsmekanisme gjør ikke unødvendig innsamling eller mangelfull informasjon til registrerte lovlig. Hold disse vurderingene sammen gjennom referanser, men unngå å blande konklusjonene.
Skaff et etterprøvbart land- og mottakergrunnlag
Undersøk hvilke lover og hvilken praksis som kan påvirke importørens mulighet til å følge sine forpliktelser. Knytt analysen til mottakerens sektor, type opplysninger og faktiske behandling. Oppgi kilder, dato og hvem som har vurdert dem. Et notat som bare sier at landet har personvernlovgivning, besvarer ikke spørsmålet om den relevante tilgangen eller beskyttelsen.
Bruk kompetanse som passer den rettslige analysen, og dokumenter usikkerhet. Leverandørens egen vurdering kan være et nyttig bidrag, men eksportøren må forstå hva den bygger på og om den dekker deres overføring. Spør hvilke forutsetninger som gjelder, hvilke forhold som er utelatt og hvordan nyere endringer blir fanget opp. Mangel på dokumenterte hendelser er ikke alene et bevis på at ingen relevante rettslige problemer finnes.
Arbeidsark for TIA-dokumentasjonen
| Del | Innhold og forventet underlag |
|---|---|
| Omfang | Dataflyt, parter, roller og miljøer |
| Opplysninger | Kategorier, registrerte, format og mengde |
| Grunnlag | Aktuell mekanisme og avtaledokumentasjon |
| Rettslig analyse | Relevante regler og praksis med kildehenvisning |
| Tilgang | Hvem som kan få klartekst eller nøkler |
| Tiltak | Teknisk, organisatorisk og kontraktsmessig beskyttelse |
| Effekt | Hvordan tiltakene svarer på identifiserte problemer |
| Beslutning | Gjennomføre, endre, begrense eller stanse |
| Oppfølging | Eier, endringstriggere og nødvendige kontroller |
Arbeidsarket er en disposisjon, ikke en automatisk beregning av lovlighet. Et tall for «lav risiko» kan skjule en uløst rettslig svakhet dersom modellen ikke undersøker riktig spørsmål. Beskriv derfor hvorfor tiltakene gir den nødvendige beskyttelsen, og hvilke forutsetninger konklusjonen avhenger av.
Vurder tiltak mot den konkrete svakheten
Et teknisk tiltak må vurderes ut fra hvem som kan lese opplysningene og når. Kryptering kan ha ulik betydning ved ren lagring og ved en supportoppgave som krever klartekst. Undersøk hvor nøklene finnes, hvem som kan bruke dem og om mottakeren kan få tilgang på andre måter. En generell opplysning om kryptering under transport er ikke et fullstendig svar.
Bruk krypteringsvurderingen og pseudonymisering til å beskrive tekniske forutsetninger. Kontrakter, varslingsplikter og interne prosedyrer kan være relevante, men dere må forklare hvordan kombinasjonen av tiltak håndterer den identifiserte mangelen. Et tiltak som ikke påvirker den aktuelle tilgangen, bør ikke få en avgjørende rolle i konklusjonen.
Undersøk support som et eget scenario
Supporttilgang kan være sjelden og likevel omfatte omfattende opplysninger. Kartlegg hvordan tilgang bestilles, hvem som godkjenner den og hvilke data supportmedarbeideren kan se. Vurder om saken kan løses med begrensede tekniske opplysninger, syntetiske eksempeldata eller et redigert utdrag. Det kan redusere overføringens omfang før mer kompliserte tiltak vurderes.
Beskriv også hva supportleverandøren lagrer i sin egen sak. Skjermbilder, logger og vedlegg kan leve videre etter at fjernsesjonen er avsluttet. En tidsbegrenset systemtilgang dekker ikke automatisk oppbevaringen av slike kopier. Ta derfor med hele supportflyten, inkludert eventuell eskalering til andre juridiske enheter.
Hypotetisk eksempel: feilsøking av et HR-system
En tenkt virksomhet bruker en tjeneste med lagring i EØS, men feilsøking kan utføres av en separat enhet i et tredjeland. Gjennomgangen viser at standardtilgangen gir innsyn i personalopplysninger som ikke er nødvendige for den aktuelle feilen. Virksomheten avgrenser tilgangen og lager et teknisk utdrag uten unødvendig personalinnhold.
Deretter vurderes gjenværende overføring med korrekt mottaker og avtalegrunnlag. Hvis tilstrekkelig beskyttelse ikke kan dokumenteres for en nødvendig klarteksttilgang, må arbeidsmåten endres eller overføringen unnlates. Eksemplet viser at en TIA kan føre til et annet driftsopplegg; den er ikke bare dokumentasjon som fylles ut etter at leverandøren allerede har fått all tilgang.
Knytt beslutningen til faktiske forutsetninger
Skriv hva som er godkjent, hvilket omfang beslutningen gjelder og hvilke tiltak som må være på plass før overføring. Angi hvem som har myndighet til å ta beslutningen og hvordan teknisk gjennomføring bekreftes. En juridisk vurdering som forutsetter nøkkelkontroll, må følges av bevis på at nøkkelkontrollen faktisk er etablert.
Beskriv også hva som skjer hvis en forutsetning ikke oppfylles. Det kan være at tilgangen begrenses, overføringen utsettes eller en alternativ leveranse brukes. Et beslutningsnotat bør gjøre det mulig for drift og innkjøp å handle riktig uten å tolke hele den juridiske analysen på nytt under tidspress.
Kontroller dokumentasjonen hos databehandleren
Når en databehandler bistår, må virksomheten forstå hvilke opplysninger vurderingen bygger på. Avklar hvem som følger opp underdatabehandlere og hvem som varsler om endringer i mottakere eller tilgang. Databehandleravtalen bør støtte denne informasjonsflyten, men et kontraktsvilkår må følges i praksis.
Be om presise svar på åpne spørsmål fremfor en ny generell sikkerhetspresentasjon. En samlet leverandørpakke kan gjenbrukes som underlag, men virksomhetens konklusjon må dekke dens egen tjeneste, konfigurasjon og datakategorier. Dokumenter hvilke deler som er kontrollert og hvor dere fortsatt er avhengige av leverandørens opplysninger.
Vedlikehold vurderingen ved endringer
Ny underdatabehandler, annet supportland, nye datakategorier eller endret teknisk arkitektur kan påvirke konklusjonen. Angi disse som konkrete triggere i endringsprosessen. Følg også relevante rettslige endringer. En fast gjennomgangsdato er nyttig, men bør ikke være eneste mekanisme for å oppdage at vurderingens forutsetninger har falt bort.
Oppbevar versjoner og beslutningshistorikk slik at virksomheten kan forklare hvilket grunnlag som gjaldt på et bestemt tidspunkt. Bevar nødvendig dokumentasjon uten å kopiere selve personopplysningene inn i TIA-mappen. Sluttproduktet bør gjøre det mulig å forstå overføringen, kontrollere beskyttelsen og gjennomføre en endring når forutsetningene endres.