Je hebt een analysedashboard ingericht waarbij gebruikers-ID’s zijn vervangen door willekeurige codes. Of je slaat formulierinzendingen op met gehashte e-mailadressen in plaats van de echte adressen. Klaar, toch? De AVG geldt niet meer, want de gegevens zijn toch gepseudonimiseerd?

Dat is een veelgemaakte aanname, en een kostbare. Ze leidt er in de praktijk toe dat privacyverklaringen cruciale informatie weglaten, of juist het tegenovergestelde bevatten: een gekopieerde juridische standaardzin over pseudonimisering die bezoekers niets zegt. In dit artikel ga je stap voor stap na of jouw gepseudonimiseerde gegevens nog onder de AVG vallen, en hoe je dat vervolgens eerlijk en begrijpelijk in je privacyverklaring verwerkt.

Wanneer denk je dat pseudonimisering je vrijstelt van de AVG?

De gedachte is begrijpelijk: je vervangt namen en e-mailadressen door codes, en de data lijkt daarmee anoniem. In de praktijk denken veel website-eigenaren, van een kleine webshop tot een SaaS-aanbieder met duizenden gebruikers, dat ze hiermee buiten het toepassingsgebied van de AVG vallen. Ze laten de verwerkingen dan weg uit hun privacyverklaring of schrijven simpelweg “wij bewaren alleen geanonimiseerde gegevens”.

Het probleem is dat pseudonimisering en anonimisering twee heel verschillende dingen zijn. Bij echte anonimisering is het onomkeerbaar onmogelijk om de data terug te herleiden naar een persoon, ook niet met behulp van aanvullende informatie. Om goed te begrijpen wat telt als een persoonsgegeven onder de AVG is het essentieel dit onderscheid scherp te hebben. Bij pseudonimisering bewaar je ergens een sleutel waarmee de koppeling wél nog te maken is. De AVG noemt dit expliciet: zolang herleiding mogelijk is met redelijkerwijs beschikbare informatie, blijven het persoonsgegevens.

Stap 1: Stel vast of jouw data echt niet herleidbaar is

De Autoriteit Persoonsgegevens (AP) hanteert in haar uitleg drie praktische toetsvragen. Beantwoord ze eerlijk voor jouw situatie.

  • Zijn er aanvullende gegevens beschikbaar waarmee herleiding mogelijk is? Denk aan een koppeltabel in dezelfde database, een logbestand met IP-adressen, of een extern CRM-systeem dat dezelfde gebruikers-ID’s gebruikt.
  • Hoeveel moeite kost herleiding? Als het samenvoegen van twee tabellen in jouw eigen systeem volstaat om de echte naam boven tafel te krijgen, is de data definitief niet anoniem.
  • Wie heeft toegang tot de sleutel? Jijzelf, een verwerker zoals je hostingpartij, of een externe analisepartij?

Stel je beheert een ledenwebsite voor een sportvereniging in Utrecht. Je exporteert statistieken naar een spreadsheet waarbij de namen zijn vervangen door nummers. Maar de nummers staan ook in je ledenadministratie, die jij zelf beheert. Dan kan jij herleiden wie nummer 47 is. Voor jou zijn het dus gewoon persoonsgegevens en geldt de AVG volledig.

Stap 2: Breng in kaart welke partijen de sleutel hebben

Zodra je weet dat herleiding technisch mogelijk is, moet je bepalen wie de sleutel in handen heeft. Dit bepaalt namelijk wie er als verwerkingsverantwoordelijke of verwerker kwalificeert onder de AVG.

Er zijn drie veelvoorkomende situaties. Ten eerste: jijzelf hebt de sleutel. Je bent dan gewoon verwerkingsverantwoordelijke voor die gegevens, ook al werkt je systeem intern met codes. Ten tweede: je verwerker, bijvoorbeeld een analytics-platform of e-mailmarketingdienst heeft de sleutel. Dan geldt de AVG voor die verwerkersrelatie en heb je een verwerkersovereenkomst nodig. Ten derde: een externe partij zoals een advertentienetwerk of onderzoeksbureau heeft de sleutel. Dan is die partij mogelijk zelfstandig verwerkingsverantwoordelijke en moet dat in je privacyverklaring worden vermeld als derde partij.

Een concreet voorbeeld: je gebruikt een A/B-testplatform dat gebruikers identificeert via gehashte device-ID’s. Het platform heeft intern de mogelijkheid om die hashes te koppelen aan profielen. Voor jou zien de gegevens anoniem uit, maar voor het platform zijn het persoonsgegevens. Je privacyverklaring moet deze derde partij dan vermelden.

Stap 3: Bepaal de grondslag, ook bij pseudonieme datasets

Veel website-eigenaren denken dat pseudonimisering de vraag naar een verwerkingsgrondslag overbodig maakt. Dat is niet zo. Zolang de data herleidbaar is, heb je een geldige grondslag nodig: toestemming, een overeenkomst, een wettelijke verplichting, vitaal belang, een taak van algemeen belang, of gerechtvaardigd belang.

Bij gepseudonimiseerde persoonsgegevens avg is het gerechtvaardigd belang vaak een logische keuze voor interne analyses, mits je een afweging hebt gemaakt en gedocumenteerd. Maar toestemming blijft verplicht als je de data gebruikt voor gepersonaliseerde advertenties, ook al werkt het systeem achter de schermen met codes in plaats van namen.

Noteer per verwerking de gekozen grondslag. Dit heb je nodig voor stap 4.

Stap 4: Formuleer de verwerkingsomschrijving voor je privacyverklaring

Nu komt het praktische werk: hoe schrijf je dit begrijpelijk op? De kernregel is simpel: beschrijf pseudonimisering als een beveiligingsmaatregel, niet als een reden waarom de AVG niet van toepassing is.

Een slechte formulering is: “Wij bewaren geen persoonsgegevens, want alle gegevens worden gepseudonimiseerd.” Dit is onjuist en kan bij een klacht of handhavingsonderzoek van de AP tot problemen leiden.

Een betere formulering is: “Voor onze gebruiksanalyses vervangen wij jouw gebruikers-ID door een interne code. Wij bewaren de koppeling tussen die code en jouw account in een afgeschermde omgeving. Het doel van deze verwerking is het verbeteren van onze dienst. De grondslag is ons gerechtvaardigd belang.”

Zo geef je bezoekers een eerlijk beeld van wat er gebeurt, zonder technisch jargon, en voldoe je aan de transparantieverplichting uit de AVG.

Stap 5: Vermeld de bewaartermijnen en het koppelrisico

Bewaartermijnen gelden ook voor gepseudonimiseerde data. Bepaal hoe lang je de gecombineerde set (de codes én de sleutel) bewaart. Vernietig je de sleutel op een bepaald moment wel definitief, dan worden de resterende data op dat punt pas echt anoniem.

Vermeld in je privacyverklaring ook wat er met de sleutel gebeurt. Iets als: “De koppeltabel wordt uiterlijk twaalf maanden na het einde van jouw account verwijderd. Na die verwijdering is herleiding niet meer mogelijk.” Dit laat zien dat je nagedacht hebt over het koppelrisico, de situatie waarbij de sleutel en de gepseudonimiseerde data onbedoeld samenkomen door een beveiligingsincident of een fusie.

Stap 6: Beschrijf de rechten van betrokkenen

Hier zit een veelgestelde vraag: als iemand een inzageverzoek indient, moet je dan ook de gepseudonimiseerde gegevens verstrekken?

Het antwoord hangt af van of jij de persoon kunt identificeren. Kan je dat, dan moet je het inzageverzoek inwilligen en de betrokkene laten zien welke gegevens er van hem of haar zijn, inclusief de gepseudonimiseerde verwerkingen. Kan je de persoon achter de code echt niet achterhalen, ook niet met aanvullende informatie die de betrokkene zelf aanlevert, dan mag je weigeren op grond van artikel 11 AVG.

Schrijf dit duidelijk in je privacyverklaring: “Als wij jou niet kunnen identificeren aan de hand van de beschikbare gegevens, kunnen wij een verzoek tot inzage of verwijdering mogelijk niet volledig inwilligen. Wij leggen dan uit waarom en welke stappen jij zelf kunt nemen om je identiteit te bevestigen.”

Veelgemaakte formuleerfouten en de correcte alternatieven

Foutieve formulering Waarom het fout is Correcte alternatief
“Deze gegevens zijn anoniem omdat ze zijn gepseudonimiseerd.” Pseudoniem is niet hetzelfde als anoniem. “Deze gegevens zijn gepseudonimiseerd als beveiligingsmaatregel, maar vallen nog onder de AVG.”
“Wij slaan geen persoonsgegevens op in onze analyses.” Als de koppeltabel bestaat, zijn het nog steeds persoonsgegevens. “Wij gebruiken interne codes voor analyses; de koppeling met uw account bewaren wij apart en beveiligd.”
“U heeft geen rechten op gepseudonimiseerde verwerkingen.” Dit klopt alleen als herleiding echt onmogelijk is. “U kunt een inzageverzoek indienen; wij beoordelen dan of wij u kunnen identificeren.”

Controleer je eindresultaat: acht punten voordat je publiceert

Voordat je de bijgewerkte privacyverklaring live zet, loop je deze checklist door.

  • Stap 1: Heb je per verwerking getoetst of herleiding mogelijk is, en is de conclusie gedocumenteerd?
  • Stap 2: Zijn alle partijen met toegang tot de sleutel, inclusief verwerkers en derden, vermeld?
  • Stap 3: Is per verwerking een geldige grondslag benoemd?
  • Stap 4: Omschrijf je pseudonimisering als beveiligingsmaatregel en niet als uitzondering op de AVG?
  • Stap 5: Zijn bewaartermijnen voor zowel de gepseudonimiseerde data als de sleutel opgenomen?
  • Stap 6: Is uitgelegd wanneer je een inzageverzoek inwilligt en wanneer niet?
  • Stap 7: Zijn de foutieve formuleringen uit de vergelijkingstabel hierboven gecheckt en gecorrigeerd?
  • Stap 8: Begrijpt een gemiddelde bezoeker, zonder juridische achtergrond, wat er met zijn of haar gegevens gebeurt?

Gepseudonimiseerde persoonsgegevens vallen in verreweg de meeste situaties gewoon onder de AVG. Dat is geen reden tot paniek, maar wel een reden om je privacyverklaring eerlijk en concreet te schrijven. Beschrijf pseudonimisering als wat het werkelijk is: een goede beveiligingskeuze, geen juridische ontsnappingsroute.

Gebruik de stappen en de checklist hierboven om je privacyverklaring te controleren of bij te werken. Twijfel je over een specifieke verwerking? De generator op deze site helpt je de juiste omschrijvingen te formuleren, zonder dat je zelf het AVG-jargon hoeft te ontcijferen.