Pseudonymisering gør det muligt at arbejde med oplysninger om personer uden at give alle brugere adgang til deres direkte identitet. Et kundenummer kan erstattes af en tilfældig kode, mens forbindelsen til kunden opbevares i en særskilt, beskyttet tjeneste. Analytikeren kan dermed følge udviklingen i et forløb uden normalt at kende navnet.
Beskyttelsen afhænger af mere end selve koden. Den bryder sammen, hvis samme analytiker kan hente koblingstabellen, hvis eksporten stadig indeholder en præcis adresse, eller hvis pseudonymet kan beregnes ud fra en kendt e-mailadresse. Denne guide viser, hvordan en virksomhed vælger metode, adskiller roller og kontrollerer en konkret analyseproces.
Hvad betyder pseudonymisering efter GDPR?
Artikel 4, nr. 5, beskriver en behandling, hvor oplysninger ikke længere kan henføres til en bestemt person uden supplerende information. Den supplerende information skal holdes særskilt og beskyttes med tekniske og organisatoriske foranstaltninger. Definitionen er dermed også et krav til organiseringen omkring den tekniske transformation. Se GDPR’s artikel 4, 25 og 32.
Et regneark med fanerne »analyse« og »navnenøgle« giver ikke den tilsigtede adskillelse, hvis alle modtagere kan åbne begge faner. Omvendt kan en kontrolleret nøglefunktion give en reel beskyttelse, selv om den dataansvarlige fortsat kan identificere personen ved et begrundet behov.
Pseudonymisering kan begrænse risikoen ved behandling og støtte databeskyttelse gennem design. Den skaber ikke i sig selv et behandlingsgrundlag og gør ikke et unødvendigt analyseformål lovligt. Før teknikken vælges, skal virksomheden kunne forklare, hvorfor den behandler oplysningerne, og hvorfor de valgte felter er nødvendige.
Pseudonymiseret er ikke uden videre anonymt
Den dataansvarlige, der har koblingen tilbage til personerne, behandler fortsat personoplysninger i denne sammenhæng. En intern analytikers manglende adgang til nøglen ændrer ikke automatisk virksomhedens pligter. Skeln derfor mellem adgangsbegrænsning for en rolle og den retlige vurdering af hele behandlingen.
Der er samtidig en vigtig nuance i den aktuelle praksis. Datatilsynets omtale af EU-Domstolens dom i C-413/23 forklarer, at oplysninger ikke nødvendigvis er personoplysninger for enhver modtager i enhver behandlingssituation. Vurderingen afhænger af den konkrete sammenhæng og rimelige identifikationsmuligheder. Det er ikke en generel fritagelse for pseudonymiserede datasæt. Se Datatilsynets omtale fra september 2025.
For databehandlere har Datatilsynet præciseret, at vurderingen i databehandlerkonstruktionen skal tage udgangspunkt i den dataansvarliges perspektiv, når leverandøren arbejder på dennes vegne og efter instruks. Har den dataansvarlige nøglen, bliver oplysningerne ikke uden videre upersonlige hos leverandøren. Egen videreanvendelse kræver desuden vurdering af videregivelsen fra den oprindelige dataansvarlige. Se tilsynets præcisering fra oktober 2025.
Hvis målet er en rapport, der kan deles uden personhenførbare oplysninger, skal der foretages en særskilt vurdering af anonymisering. At slette én nøgle er utilstrækkeligt, hvis andre felter stadig identificerer personerne.
Eksempel: analyse af kunders supportforløb
Den fiktive virksomhed Vestkyst Support vil se, hvor ofte en kunde må henvende sig igen om samme produktproblem. Den har brug for at forbinde flere henvendelser fra samme kunde i analyseperioden. Analytikeren har ikke brug for navn, e-mail, telefonnummer eller de fulde beskeder til support.
Projektet vælger derfor et stabilt pseudonym inden for netop denne analyse. En særskilt tjeneste oversætter internt kundenummer til en tilfældig analysekode. Kundesystemets direkte identifikatorer følger ikke med i datasættet. Tabellen viser et udfyldt, konstrueret eksempel:
| Placering | Indhold | Adgang |
|---|---|---|
| Kundesystem | Kunde 48217, navn og kontaktoplysninger | Support med arbejdsbetinget behov |
| Koblingstjeneste | Kunde 48217 svarer til analysekode K7M4Q | Begrænset nøglefunktion |
| Analysedatasæt | K7M4Q, produktgruppe B, uge 36, to genhenvendelser | Analysegruppen |
| Ledelsesrapport | Samlet andel genhenvendelser for produktgruppe B | Relevante ledere |
Koden i tabellen er forkortet for at gøre eksemplet læsbart. Den er ikke en anbefaling om en bestemt kodestørrelse i produktion. Den faktiske løsning skal sikre tilstrækkelig tilfældighed, håndtere kollisioner og passe til datamængden og truslerne.
Vestkyst Support udelader friteksten fra analysen, fordi kunder kan have skrevet helbredsforhold eller andre oplysninger, som ikke er nødvendige for opgaven. Arbejd først med dataminimering af felter og kopier; pseudonymisering bør ikke bruges som begrundelse for at beholde hele kildesystemet i analyseplatformen.
Vælg teknik efter behovet for sammenkobling
Tilfældige tokens med en separat koblingstabel passer til eksemplet, fordi virksomheden har brug for kontrolleret genfinding og kan drive en afgrænset nøglefunktion. Det kræver beskyttelse af tabellen, adgangsstyring og en plan for dens levetid. Et token er ikke risikofrit blot fordi det ser tilfældigt ud.
En almindelig hash af en e-mailadresse er et svagere valg, end mange forventer. En modtager kan prøve kendte adresser og sammenligne resultatet. En hemmelig nøgle i en egnet kryptografisk konstruktion ændrer angrebsbilledet, men kræver sikker nøglehåndtering. Kryptering kan også indgå, når den konkrete udformning sikrer den nødvendige adskillelse. Diskkryptering alene betyder ikke, at analytikerens læsbare datasæt er pseudonymiseret.
ENISA beskriver blandt andet tilfældige værdier, hashfunktioner, nøglebaserede metoder og kryptering samt angreb ved afprøvning af mulige input. Metodevalget skal afveje beskyttelse, anvendelighed og mulighed for genfinding. Se ENISA’s tekniske gennemgang af pseudonymisering.
Et stabilt pseudonym gør gentagne hændelser sammenlignelige, men kan også gøre profiler mere detaljerede. Vestkyst Support genbruger derfor ikke automatisk samme analysekode i HR, marketing og produktudvikling. Et fælles pseudonym på tværs af formål kan skabe en ny mulighed for sammenkobling, som den oprindelige vurdering ikke dækkede.
Adskil rollerne i praksis
Analysegruppen må læse analysedata, men må ikke slå koder tilbage til kunder. Nøglefunktionen må udføre godkendte opslag, men har ikke brug for almindelig adgang til alle analyser. Systemadministratorer kan have særlige tekniske muligheder; disse skal beskrives og begrænses, så adskillelsen ikke kun findes i et organisationsdiagram.
Virksomheden vælger i eksemplet, at en genidentifikation kræver en konkret sag og godkendelse fra en anden udpeget person. Et ønske om at kontakte kunder med lave vurderinger bliver afvist, fordi det ikke indgår i det godkendte analyseformål. En anmodning om at finde oplysninger til behandling af en rettighedsanmodning undersøges derimod gennem den kontrollerede proces.
Loggen registrerer formål, godkender, tidspunkt og resultat af opslaget uden at kopiere mere persondata end nødvendigt. Den opbevares med egne adgangs- og sletteregler. Brug sikkerhedslogning med målrettet kontrol, så gentagne eller usædvanlige opslag faktisk bliver undersøgt.
Nøgler og koblingstabeller kræver også sikkerhedskopiering, hvis de fortsat er nødvendige. Beskyttelsen skal omfatte både den aktive tjeneste og dens kopier. Den praktiske styring af krypteringsnøgler hjælper med at adskille adgang, genopretning og udfasning.
Undersøg andre veje til identifikation
I den første prøvefil har Vestkyst Support erstattet kundenummeret, men bevaret det præcise tidspunkt for hver henvendelse. En supportmedarbejder kan genkende en usædvanlig sag og slå tidspunktet op i kundesystemet. Projektet vælger derfor ugeniveau i analysen og fjerner særprægede sagsnoter.
Kontrollen omfatter også små grupper, geografiske felter og usædvanlige kombinationer. En sjælden produktfejl hos én bestemt kunde kan være identificerende for en person, der kender hændelsen. Vurderingen skal tage hensyn til den viden, som de reelle modtagere har, ikke kun til hvad en tilfældig udenforstående kan gætte.
De rettede data afprøves med analysegruppens almindelige rettigheder. Gruppen forsøger at hente koblingstabellen, bruge administrationsgrænseflader og åbne gamle eksporter. En vellykket adskillelse i hovedsystemet hjælper ikke, hvis en gammel fil stadig ligger i en fælles mappe.
Fastlæg rettigheder, leverandørinstruks og afslutning
Vestkyst Support beskriver processen i sin behandlingsdokumentation og leverandørinstruks. Leverandøren må ikke forsøge genidentifikation eller anvende materialet til egne formål uden en særskilt retlig vurdering. Rollefordelingen skal følge den faktiske behandling; se dataansvarliges og databehandleres opgaver.
Ved en indsigts- eller sletteanmodning bruger den ansvarlige medarbejder det kontrollerede opslag til at finde relevante poster. Der skal ikke indsamles nye direkte identifikatorer i alle analysefiler blot for at gøre fremtidige anmodninger lettere. Løsningen skal understøtte de rettigheder, som gælder for behandlingen, med forholdsmæssige midler.
Slutbeslutningen i eksemplet er, at analysen kan fortsætte med ugeoplysninger, separate adgangsgrupper og godkendte opslag. Fritekst og præcise tidspunkter udgår. Den fælles marketingnøgle afvises. Ved analyseperiodens udløb slettes rådata og koblinger efter den fastlagte plan, mens en kontrolleret samlet rapport kan bevares, hvis dens oplysninger reelt er anonyme. Beslutningen forbinder dermed metode, adgang og faktisk anvendelse i én dokumenteret proces.