Pseudonymisering ska göra det möjligt att använda uppgifter utan att den som arbetar med materialet samtidigt får den information som kopplar det till en viss person. En kodkolumn hjälper bara om kodnyckeln, åtkomsten och övriga identifierande uppgifter hanteras genomtänkt. Att lägga namnlistan på nästa flik i samma kalkylark ger ingen meningsfull separation.
Den här guiden hjälper en analysansvarig och en systemägare att välja metod, avgränsa kodernas användning och dokumentera kontrollerad återkoppling till originaldata. Resultatet är ett arbetsbeslut med datamängd, kodnyckelägare, behörigheter och verifiering. För publicering som anonym statistik behövs dessutom en anonymiseringsbedömning.
Vad pseudonymisering betyder enligt GDPR
Artikel 4.5 beskriver behandling som gör att personuppgifter inte längre kan hänföras till en specifik registrerad utan kompletterande information, förutsatt att denna information hålls separat och skyddas med tekniska och organisatoriska åtgärder. Pseudonymisering nämns också i artiklarna 25 och 32 som en möjlig skyddsåtgärd. Den är inte en egen rättslig grund för en ny analys. GDPR: artiklarna 4, 25 och 32.
För en organisation som har kvar användbara återidentifieringsuppgifter finns personkopplingen fortfarande. Skyddet kan ändå vara värdefullt genom att färre roller får tillgång till identiteten. Beskriv vad separationen faktiskt hindrar och vilka personer eller system som fortfarande kan göra kopplingen.
EU-domstolen klargjorde i C-413/23 P den 4 september 2025 att pseudonymiserade uppgifter inte nödvändigtvis är personuppgifter för varje mottagare. Mottagarens rimligen användbara identifieringsmedel ska bedömas. Den ursprungliga insamlarens informationsskyldighet avgörs samtidigt utifrån förhållandena vid insamlingen, där denne kan identifiera personerna. EU-domstolen: pseudonymiserade uppgifter och mottagarkontext.
Håll därför isär den egna kodningen och en eventuell bedömning av en extern mottagares material. Avsaknad av en överlämnad namnlista är bara en del av den senare analysen. Övriga fält, möjliga kombinationer och tillgång till kompletterande information behöver också granskas.
1. Bestäm vad analysen behöver kunna följa
Börja med en fråga som avgör hur koderna ska fungera. Ska analysgruppen följa samma kund över flera månader eller bara jämföra totalsiffror i en avgränsad fil? Behöver samma person ha samma kod i flera projekt? Ska ett fel kunna rättas genom återkoppling till originalsystemet?
Långlivade gemensamma koder förenklar sammanföring, men skapar också fler kopplingsmöjligheter. Om två projekt inte behöver kombineras bör ni pröva separata kodområden. Beskriv även hur länge kopplingen behövs och vad som händer när projektet avslutas.
Ta bort uppgifter som analysen inte behöver innan kodningen används som lösning på allt. En fil med pseudonymiserat kundnummer kan fortfarande innehålla namn i fritext eller en exakt adress. Använd fältgranskningen för uppgiftsminimering för att motivera den återstående datamängden.
2. Välj metod efter hot och användning
Slumpmässiga koder med en separat kopplingstabell kan passa när en kontrollerad funktion behöver återkoppla till originaldata. Kryptering kan användas i vissa upplägg, men kräver lämplig nyckelhantering. En nyckelbaserad funktion kan ge reproducerbara värden för matchning, samtidigt som nyckeln måste hållas skyddad från dem som bara ska använda analysdata.
Vanlig hashning av förutsägbara identifierare är ingen garanti mot återidentifiering. Om möjliga indata går att räkna upp kan någon beräkna jämförelsevärden. Ett telefonnummer eller annat begränsat identifierarutrymme blir inte säkert enbart för att resultatet ser slumpmässigt ut. ENISA:s rapport från 2019 behandlar bland annat gissning, ordboksangrepp och uttömmande sökning som risker vid pseudonymisering. ENISA: tekniker och god praxis.
Låt en kompetent teknisk funktion välja en underhållen implementation och granska parametrarna. En hashfunktion för matchning av analysdata och en metod för säker lösenordslagring fyller olika uppgifter. Återanvänd inte en enkel kodsnutt bara för att ordet hash förekommer i båda sammanhangen.
3. Separera åtkomst och administrativa rättigheter
Bestäm vem som får se analysdata, vem som förvaltar kodnyckeln och vem som får begära en återkoppling. Separationen behöver omfatta databaser, säkerhetskopior, supportåtkomst och exportfiler. Om samma breda administratörsgrupp kan hämta båda delarna måste det ingå i riskbedömningen.
Spara hemliga nycklar i en lämplig skyddad lösning och dokumentera ansvar, återställning och byte. Lägg inte nyckeln i analyskod, en allmän projektmapp eller samma meddelande som filen. Krypteringsguiden ger en struktur för att beskriva nycklarnas livscykel och kvarvarande åtkomst.
Planera också hur separationen verifieras. En analysanvändare ska kunna göra sin uppgift utan att få kodnyckeln. Förvaltaren ska kunna visa hur en återkoppling godkänns och spåras. Säkerhetsbilagan kan sammanfatta de tillämpade åtgärderna för den aktuella tjänsten.
4. Ifyllt exempel: återkommande serviceanalys
Ett fiktivt serviceföretag vill analysera återkommande fel i kundärenden över ett halvår. Analytikerna behöver kunna följa samma kunds ärenden, men behöver inte namn, e-postadress eller hela ärendets fritext. En separat kundservicefunktion behöver kunna utreda vissa bekräftade fel i originalsystemet.
| Del | Beslut i exemplet |
|---|---|
| Analysdata | Projektkod, grov ärendekategori, månad och avgränsat resultat; direkta kontaktuppgifter och fullständig fritext utelämnas |
| Kodning | Projektunika slumpmässiga koder med en separat kopplingstabell |
| Kodnyckelägare | Begränsad förvaltningsfunktion utanför analysgruppen |
| Återkoppling | Analysansvarig lämnar ett avgränsat ärende; behörig kundservicefunktion bedömer behov och hanterar kontakten i originalsystemet |
| Delning | Analysgruppen får bara den beslutade exporten; ingen automatisk publicering av rådata |
| Avslut | Behov av kodnyckel, projektfiler och rapporter prövas separat enligt beslutad gallringsregel |
Beslutet beskriver pseudonymiserat material i den egna behandlingen. Det gör inte anspråk på att hela filen är anonym för alla mottagare. Om företaget senare vill dela materialet externt krävs en bedömning av just den delningen och mottagarens identifieringsmöjligheter.
En praktisk kontroll visar att en analytiker kan beräkna återkommande fel men inte slå upp kundnamn. Förvaltningsfunktionen kan återkoppla en utvald kod efter godkännande. Kontrollanten granskar även exportens andra kolumner så att ett ärendenummer som redan är känt för analytikern inte skapar en oavsiktlig genväg till identiteten.
5. Skydda kodnyckeln under hela livscykeln
Dokumentera hur koder skapas, hur dubbletter hanteras och hur felaktiga kopplingar rättas. En felaktig matchning kan blanda ihop två personers uppgifter och ge missvisande analys. Använd riktighetsrutinen för kontroll av källor och hantering av konflikter.
Bestäm hur nyckelbyte påverkar äldre filer. Om varje kod plötsligt ändras kan en tidsserie brytas; om gamla nycklar behålls utan kontroll kan skyddet försämras. Dokumentera de versioner och återkopplingsmöjligheter som faktiskt behövs, med begränsad åtkomst även till historiskt material.
Radering behöver omfatta kopior av kopplingstabellen, relevanta nycklar och exporter enligt respektive beslut. Att radera en kodnyckel gör inte automatiskt en detaljrik analysfil anonym. Bedöm de återstående identifieringsvägarna innan klassificeringen ändras. Knyt åtgärderna till gallringsplanen.
6. Pröva incidenter och rättigheter utan förenklingar
Om analysdata röjs behöver organisationen bedöma vad mottagaren kan förstå eller koppla ihop. Utred om kodnyckeln, andra identifierare eller kompletterande information också kan ha röjts. Pseudonymisering kan minska risk, men ordet i dokumentationen avgör inte om en incident ska anmälas eller om personer ska informeras.
Rättighetsrutinerna behöver fungera där organisationen kan identifiera personen och berörda uppgifter. Beskriv vem som får göra sökningen och hur resultatet lämnas säkert. Bygg inte en bred analysåtkomst till identiteter bara för att en annan funktion behöver kunna hantera en enskild begäran.
Förvara metodval, åtkomstbeslut och kontrollresultat bland bevisen för ansvarsskyldighet. Märk tydligt vad som har verifierats och vad som fortfarande är ett antagande om en mottagares förmåga.
Vanliga frågor
Är det säkert att skicka kodnyckeln separat via mejl?
Separata meddelanden räcker inte i sig. Bedöm mottagare, kanaler, behörigheter och om samma konto kan nå båda delarna. Om mottagaren inte behöver återidentifiera ska nyckeln normalt inte skickas som en bekvämlighetsåtgärd.
Är en produkt som erbjuder tokenisering automatiskt rätt lösning?
Nej. Kontrollera hur koder skapas, vilka kopplingar som finns, vem som kan återställa identiteten och hur metoden passar analysen. Ett produktnamn eller certifikat ersätter inte bedömningen av den konkreta behandlingen.
Är EDPB:s nya anonymiseringsriktlinjer slutliga?
Den 8 september 2026 är riktlinjerna 02/2026 om anonymisering föremål för offentligt samråd. De ska därför inte beskrivas som slutligt antagna riktlinjer. Använd aktuell rättspraxis och gällande rätt som grund och skilj ett utkast från en slutlig vägledning. EDPB: samråd om riktlinjer 02/2026.