Pseudonymisering gjør det mulig å arbeide med et datasett uten at alle som bruker det, trenger å kjenne identiteten bak hver rad. Den praktiske oppgaven er å skille analyseopplysningene fra tilleggsinformasjonen som kan knytte dem til personer, og kontrollere hvem som kan kombinere delene. Et byttet navn i et regneark gir liten beskyttelse hvis den samme mappen inneholder koblingsnøkkelen.
Undersøk også tekniske kjennetegn som blir stående i analysefilen. IP-adresser kan fortsatt knytte data til personer, selv om navn og kundenummer er erstattet.
Personvernforordningen artikkel 4 nr. 5 definerer pseudonymisering med nettopp dette skillet og tilhørende tekniske og organisatoriske tiltak. Artikkel 25 og 32 omtaler pseudonymisering som et mulig tiltak i en konkret vurdering. Metoden er ikke et selvstendig behandlingsgrunnlag og gjør ikke automatisk en ulovlig behandling lovlig.
Bestem hva identitetskoblingen skal brukes til
Begynn med å skrive hvorfor prosjektet trenger å følge samme person over tid, og om det noen gang må finne tilbake til identiteten. En analyse av gjentatte tjenestehenvendelser kan trenge en stabil prosjektkode. Den trenger ikke nødvendigvis navn, telefonnummer eller det ordinære kundenummeret som brukes i resten av virksomheten.
Definer også hvem beskyttelsen skal virke overfor. Skal analytikere ikke kunne se identiteten? Skal en ekstern samarbeidspartner ikke kunne koble data til egne registre? Skal risiko ved tyveri av en enkelt eksport reduseres? Disse situasjonene krever ulike vurderinger av hvilke tilleggsopplysninger mottakeren kan ha eller få tilgang til.
Det er særlig viktig å skille pseudonymisering fra anonymisering. For virksomheten som har koblingsnøkkelen og kan finne tilbake til deltakerne, vil det pseudonymiserte materialet normalt fortsatt være personopplysninger. Om et materiale er personopplysninger for en annen mottaker, krever en konkret vurdering av identifiserbarheten og de tilgjengelige midlene. Ikke merk hele behandlingskjeden som anonym bare fordi én aktør mangler den direkte nøkkelen.
Tegn opp tre atskilte komponenter
En enkel modell består av kildesystemet med identitet, en kontrollert koblingstjeneste eller nøkkelfil, og analysedatasettet med prosjektkode. Formålet med separasjonen er at en normal analysebruker ikke kan hente identiteten gjennom sin vanlige tilgang. Den som forvalter koblingen, skal heller ikke automatisk ha behov for å lese alt analyseinnhold.
I et tenkt serviceprosjekt kan modellen se slik ut:
| Komponent | Innhold | Ordinær tilgang |
|---|---|---|
| Kundesystem | Kundereferanse, navn og kontaktinformasjon | Kundebehandlere etter arbeidsbehov |
| Koblingstabell for prosjektet | Kundereferanse og tilfeldig prosjektkode | To særskilt autoriserte forvaltere |
| Analysegrunnlag | Prosjektkode, tjenestetype, grov tidsperiode og sakskategori | Godkjent analysegruppe |
| Ledelsesrapport | Samlede resultater med kontroll av små grupper | Avtalte beslutningstakere |
Dette er et eksempel på rollefordeling, ikke et lovkrav om et bestemt antall forvaltere. Virksomheten må sikre kontinuitet og nødvendig kontroll uten å gjøre nøkkelen tilgjengelig for alle ved ferie eller fravær. Dokumenter hvordan stedfortrederen får tidsbegrenset tilgang, og hvordan tilgangen fjernes igjen.
Velg en metode som passer koblingsbehovet
Tilfeldige prosjekttokener med en separat koblingstabell er ofte en forståelig modell når identitetskoblingen må kunne gjenopprettes av en autorisert funksjon. Tokenet bør ikke inneholde navn, fødselsdato, avdeling eller andre meningsbærende deler. Unngå å gjenbruke en intern identifikator som mottakerne allerede kan slå opp i andre systemer.
En hash av e-postadressen er ikke automatisk en robust løsning. E-postadresser kan være kjente eller gjettbare, og en angriper kan sammenligne beregnede verdier med datasettet. Metoden må vurderes ut fra muligheten til å gjette inngangsverdiene, koble flere datasett og få tilgang til eventuelle hemmeligheter. Bruk faglig gjennomgåtte mekanismer når kryptografiske metoder inngår; ikke lag et eget kryptografisk opplegg i et regneark.
ENISAs metodeveiledning om pseudonymisering beskriver blant annet ordbokangrep, gjetteangrep og ulike teknikkvalg. Rapporten fra 2019 er teknisk bakgrunn for vurderingen, ikke et norsk påbud om én bestemt metode.
Kryptering kan inngå i beskyttelsen, men løser et annet problem når hele datasettet dekrypteres for vanlig analyse. Da ser analytikeren igjen de opprinnelige identifikatorene. Veiledningen om kryptering av personopplysninger hjelper med å skille vern av lagring og transport fra vern mot identifikasjon under bruk.
Reduser opplysninger som avslører identiteten uten nøkkelen
Selv en godt beskyttet koblingstabell hjelper lite hvis analysefilen inneholder fritekst med navn eller en unik kombinasjon av hendelser. Gjennomgå datoer, sted, stilling, sjeldne tjenestetyper og andre kjennetegn. Spør om en kollega eller en ekstern mottaker kan kjenne igjen personen uten å bruke prosjektkoden.
I serviceeksemplet kan nøyaktig tidspunkt erstattes med uke dersom analysen bare gjelder kapasitet gjennom sesongen. En sjelden sakstype kan slås sammen med en bredere kategori i rapporten. Behold detaljene bare der de er nødvendige, og skill et eventuelt behov for operativ saksoppfølging fra analysebehovet.
Bruk dataminimeringens feltgjennomgang før eksporten bygges. En tillatt kolonneliste er ofte lettere å kontrollere enn en regel om å fjerne «sensitive ting» etterpå. Kontroller også skjulte ark, kommentarspor og filnavn. Identiteten kan følge med uten å være synlig i de første radene.
Etabler en konkret rutine for tilbakekobling
Tilbakekobling bør ha et avgrenset formål, en beslutningstaker og et dokumentert resultat. Et prosjekt kan for eksempel tillate kobling for å håndtere en verifisert rettighetsforespørsel eller rette en dokumentert datafeil. Det betyr ikke at prosjektlederen kan koble identitet for å undersøke en interessant enkeltperson i analysen.
En praktisk forespørsel kan angi: prosjektkode, nødvendig formål, hvilke opplysninger som trengs, hjemmelen for behandlingen og mottakeren av resultatet. Nøkkelforvalteren kontrollerer at forespørselen faller innenfor den godkjente rutinen. Loggen bør registrere beslutningen og hvem som utførte koblingen, uten å bygge opp en ny ukontrollert kopi av identitetsregisteret.
Hvis et nytt formål krever systematisk tilbakekobling, må prosjektet revurderes. Det er ikke lenger bare en sjelden administrativ hendelse. Knytt endringen til kontrollen av viderebruk og formålsbegrensning, og oppdater informasjonen og nødvendige vurderinger før den nye bruken starter.
Beskytt nøkkelen gjennom hele levetiden
Koblingsnøkkelen trenger egen tilgangsstyring, sikker lagring og en plan for sikkerhetskopier. Vurder om administratorroller, tjenestekontoer eller en felles skylagringsmappe i praksis opphever skillet dere har beskrevet. To mapper med samme brede tilgang er ikke en meningsfull organisatorisk separasjon.
Når en nøkkel roteres eller prosjektkoder endres, må teamet forstå hva som skjer med historiske data. Kan gamle og nye eksportfiler kobles gjennom overlappende rader? Finnes en gammel nøkkel fortsatt i en e-post eller en sikkerhetskopi? Planen bør angi hvilke versjoner som er gyldige, hvem som kan bruke dem, og når utdaterte kopier tas ut av ordinær bruk.
Sikkerhetslogger med en tydelig rutine kan støtte kontroll med nøkkelbruk. Loggene må selv begrenses, beskyttes og få en relevant lagringstid. Det er sjelden nødvendig å logge hele identiteten og analyseinnholdet for å dokumentere at en autorisert kobling fant sted.
Avtal mottakerens bruk og vurder overføringer separat
Når et pseudonymisert datasett sendes til en leverandør eller samarbeidspartner, må rolle, formål, tilgang og viderebruk fortsatt være avklart. Beskriv hvilke data som sendes, hvilke tilleggsopplysninger mottakeren kan ha, og om vedkommende kan koble materialet til andre kilder. Et kontraktsforbud er nyttig, men bør vurderes sammen med den faktiske tekniske og organisatoriske beskyttelsen.
Pseudonymisering kan være et relevant supplerende tiltak i en overføringsvurdering, men ikke alle oppsett hindrer identifikasjon hos importøren eller andre aktører. Se vurdering av tredjelandsoverføringer for dokumentasjonen av dataflyt og tiltak. Det er ikke tilstrekkelig å skrive «pseudonymisert» i et avtalevedlegg uten å forklare metoden og tilgjengelige tilleggsopplysninger.
Kontroller resultatet med en representativ prøve
Før ordinær drift bør teamet bruke oppdiktede eller egnet avgrensede prøvedata til å kontrollere eksport, tilgang og tilbakekobling. En analysebruker skal ikke kunne hente koblingsnøkkelen gjennom standardrollen. Nøkkelforvalteren skal kunne utføre en godkjent retting uten å gi analysegruppen hele identitetslisten. Prøven bør også vise at en utilsiktet ekstra kolonne oppdages.
Avslutningsplanen må si hva som skjer med rådata, koblingsnøkkel og rapporter hver for seg. Sletting av nøkkelen gjør ikke automatisk restmaterialet anonymt; andre identifikasjonsmuligheter kan bestå. Dokumenter vurderingen før dere endrer klassifiseringen eller publiserer resultater. Et godt sluttleveranseark viser dataversjon, roller, godkjente koblingsformål, gjennomførte kontroller og den neste planlagte vurderingen av identifiserbarhet.