Zijn QR-codes AVG-proof? Wat een getrackte campagne echt met persoonsgegevens doet

Elk bureau dat een trackbare QR-code laat drukken, krijgt vroeg of laat dezelfde vraag, van een klant of van de eigen juristen: mag dit eigenlijk wel? Je meet immers wat mensen met een gedrukt object doen, en niemand die het scant heeft zich ergens voor aangemeld. Het eerlijke antwoord is dat QR-codes op zichzelf geen privacyprobleem zijn, maar dat een getrackte QR-campagne op twee specifieke plekken wel persoonsgegevens raakt, en de regels waar iedereen zich druk om maakt (de AVG, plus de vaak vergeten ePrivacy-regels achter cookiebanners) gelden dáár, niet voor de code op de muur.

Deze gids is voor de mensen die de campagne draaien, niet voor juristen. Hij is onderbouwd met de daadwerkelijke wetteksten en rechterlijke uitspraken in plaats van met verkooppraat, en hij is eerlijk over de onderdelen waar de branche graag overheen stapt. Het is geen juridisch advies: een campagne die gevoelige gegevens verzamelt, individuen profileert of op grote schaal draait, verdient een blik van een functionaris voor gegevensbescherming. Maar voor het gewone geval, een poster of een flyer of een code op een verpakking die scans telt en mensen naar een pagina stuurt, is de weg naar naleving kort en concreet zodra je ziet waar de data eigenlijk zit.

Een QR-code verzamelt niets. De tracking gebeurt ergens anders

Begin bij het ding zelf. Een QR-code is een gedrukt patroon dat is vastgelegd in een internationale norm, ISO/IEC 18004. Hij codeert een korte reeks tekens, vrijwel altijd een URL, en meer doet hij niet. Hij kan geen code uitvoeren, heeft geen callback, en hij ziet er op de muur hetzelfde uit of niemand hem scant of tienduizend mensen het doen. Een statische QR-code, waarbij die URL rechtstreeks naar je bestemming wijst, logt niets en verzamelt niets. Er valt niets te beschermen, want er is geen data.

Tracking komt om de hoek kijken op het moment dat je de code dynamisch maakt. Een dynamische QR-code codeert je bestemming niet rechtstreeks. Hij codeert een korte URL op het domein van de provider, en bij het scannen maakt de telefoon een korte tussenstop op dat adres voordat de provider hem doorstuurt naar de echte pagina. Die tussenstop is een gewoon webverzoek, en zoals elk webverzoek draagt het informatie met zich mee: het IP-adres van de bezoeker, de user-agentstring (die het apparaat, het besturingssysteem en de browser prijsgeeft), een tijdstempel en soms een referrer. Uit het IP kan de provider een globale locatie afleiden, meestal op stad- of landniveau, en uit de user-agent kan hij het apparaattype afleiden. Niets daarvan is de schuld van de code. Het is de schuld van de redirect.

Dan is er nog de derde laag, en dat is de laag die mensen vergeten: de pagina waar je de scan naartoe stuurt. Een landingspagina is een normale webpagina, en hij kan alles wat elke webpagina kan, en dat betekent cookies plaatsen, Google Analytics laden, een Meta- of TikTok-pixel afvuren en een veel rijker profiel opbouwen dan een redirect ooit zou kunnen. De meeste echte tracking in een QR-campagne zit hier, op de bestemming, niet in de scan.

Het mentale model dat het hele juridische plaatje op zijn plek laat vallen, bestaat dus uit drie lagen, niet uit één.

1. De gedrukte code is passief. Hij bewaart een URL en verzamelt niets, gescand of niet.
2. De redirect is een korte URL op het domein van de provider. Hij logt het verzoek: IP, user-agent, tijdstempel en referrer, plus de globale locatie en het apparaattype die hij daaruit kan afleiden.
3. De landingspagina is waar cookies, analytics-tags en marketingpixels leven, en waar de rijkste tracking daadwerkelijk gebeurt.
4. Het dashboard dat jij leest, is het totaaloverzicht: aantallen per dag, plek en apparaat. Hoe persoonlijk de data daarachter is, hangt volledig af van wat laag twee en drie hebben bewaard.

Het loont om twee zorgen uit elkaar te halen die vaak door elkaar lopen, want de zoekresultaten over QR-privacy staan vol met de verkeerde. Deze gids gaat over privacy: welke data een scan met zich meebrengt en hoe je daar rechtmatig mee omgaat. Of iemand je code met een sticker kan kapen is een beveiligingsvraag, en een ander artikel. Houd ze gescheiden en elk krijgt een helderder antwoord.

Zijn scangegevens "persoonsgegevens"? Meestal wel

De AVG geldt alleen voor persoonsgegevens, dus de eerste echte vraag is of een scanlog daaronder valt. De verordening definieert persoonsgegevens als alle informatie over een geïdentificeerde of identificeerbare persoon, en ze noemt uitdrukkelijk "online-identifiers". Het draaipunt zit bij IP-adressen. In zijn Breyer-uitspraak uit 2016 (zaak C-582/14) oordeelde het Hof van Justitie van de Europese Unie dat een dynamisch IP-adres een persoonsgegeven is in handen van een partij die de wettelijke middelen heeft om de persoon erachter te identificeren, doorgaans door naar de internetprovider te stappen. De praktische conclusie voor een bureau is rechttoe rechtaan: behandel de IP-adressen in je scanlogs standaard als persoonsgegevens, want een rechter heeft al beslist dat ze dat meestal zijn.

Hier valt een veelgehoorde claim van providers door de mand. Genoeg QR-providers zeggen dat ze IP-adressen "anonimiseren" en concluderen daaruit dat de data daarom buiten de AVG valt. Een IP hashen of inkorten is echt nuttig, maar het is meestal pseudonimisering, geen anonimisering, en pseudonieme gegevens zijn nog steeds persoonsgegevens. De grens, getrokken door overweging 26 van de AVG, is identificeerbaarheid met "alle middelen waarvan redelijkerwijs valt te verwachten dat ze worden ingezet". Een consistente hash van een kleine, raadbare waarde zoals een IP-adres is vaak terug te draaien of te herleiden, dus die haalt die lat niet. Het Hof onderstreepte dit punt in 2024 in de IAB Europe-zaak (C-604/22): een gecodeerde reeks blijft een persoonsgegeven als die met redelijke middelen tot een persoon te herleiden is. Je scangegevens houden pas op persoonsgegeven te zijn zodra ze onomkeerbaar geaggregeerd zijn, bijvoorbeeld tot aantallen per stad per dag zonder dat er onderliggende per-scanrecords worden bewaard.

De cookiebanner-vraag, waar de meeste campagnes het mis hebben

Hier is het onderscheid dat vrijwel geen enkele providerpagina goed heeft, en het is het nuttigste wat in deze gids staat. Cookiebanners komen niet uit de AVG. Ze komen uit een aparte, oudere set regels, de ePrivacy-richtlijn, waarvan artikel 5, lid 3 zegt dat je toestemming nodig hebt om informatie op te slaan op, of uit te lezen van, het apparaat van iemand. Dat is een andere toets dan "verwerk je persoonsgegevens". Het gaat specifiek over het aanraken van het apparaat.

Pas die toets toe op de drie lagen en het plaatje is helder. De redirectlog triggert hem doorgaans niet. Wanneer een telefoon het webverzoek naar je korte URL doet, stuurt hij zijn IP, user-agent en referrer mee als normaal onderdeel van hoe het web werkt; de provider ontvangt informatie die het apparaat vrijwillig prijsgeeft, en instrueert het apparaat niet om opgeslagen informatie te bewaren of terug te geven. De richtsnoeren van de European Data Protection Board over de technische reikwijdte van artikel 5, lid 3 trekken de grens precies bij die stap van "het apparaat instrueren". Een gewone scanlog aan de serverkant heeft dus meestal geen cookiebanner nodig.

De landingspagina is het tegenovergestelde. Op het moment dat hij Google Analytics, een Meta-pixel of een vergelijkbare tag laadt, schrijft hij naar en leest hij van het apparaat, en analytics-cookies zijn niet "strikt noodzakelijk", dus heb je eerst toestemming nodig. De Britse Information Commissioner is er expliciet over dat analytics-cookies toestemming vereisen, beoordeeld vanuit het perspectief van de gebruiker in plaats van dat van het bedrijf, en EU-toezichthouders hanteren dezelfde lijn. De versie van één zin die je op je scherm mag plakken: de scan heeft meestal geen cookiebanner nodig, maar de pagina waar je mensen naartoe stuurt meestal wel.

Eén eerlijke kanttekening, want de branche probeert hier al omheen te werken. Je ontloopt de banner niet door aan de serverkant stilletjes apparaatsignalen tot een fingerprint samen te voegen. Diezelfde EDPB-richtsnoeren beschouwen doelbewuste fingerprinting en geïnstrueerd verzamelen van identifiers als binnen de reikwijdte van artikel 5, lid 3. De regel "redirectlog is vrijgesteld" geldt voor een gewone log die vastlegt wat een verzoek toevallig bevatte. Het is geen vrijbrief om een verkapte identifier te bouwen.

Welke grondslag heb je nu echt nodig?

Als de scangegevens persoonsgegevens zijn, zegt de AVG dat je een van de zes grondslagen voor de verwerking moet hebben. Voor gewone, geaggregeerde scananalytics is de werkbare grondslag meestal gerechtvaardigd belang. Meten hoe een campagne waarvoor je betaald hebt presteert, is een gerechtvaardigd doel, de betrokken data is bescheiden, en de Breyer-uitspraak hierboven aanvaardde uitdrukkelijk dat een sitebeheerder een gerechtvaardigd belang kan hebben bij het loggen van dit soort verzoekgegevens. Gerechtvaardigd belang is echter geen vrijbrief. Je moet de driedelige toets daadwerkelijk doorlopen, en dat betekent het belang benoemen, aantonen dat de verwerking daarvoor noodzakelijk is, en het afwegen tegen de rechten en redelijke verwachtingen van de mensen die scannen, en die beoordeling vervolgens opschrijven.

Je komt in het terrein van toestemming zodra je verder gaat dan tellen. Een profiel van een individu opbouwen over scans heen, dezelfde persoon volgen over sites of sessies heen, precieze GPS-locatie vastleggen, of scangegevens combineren met andere identifiers om iemand eruit te lichten: dat verhoogt de inzet, en de veiligere (vaak vereiste) grondslag wordt dan toestemming die voldoet aan de AVG-norm, namelijk vrijelijk gegeven, specifiek, geïnformeerd en ondubbelzinnig, zonder vooraf aangevinkte vakjes.

En hier is de valkuil die je moet vermijden. Gerechtvaardigd belang onder de AVG ontslaat je niet van de toestemmingseis uit ePrivacy. Het zijn twee aparte vragen. Je kunt een prima zaak voor gerechtvaardigd belang hebben voor je analytics en toch toestemming nodig hebben voor de cookie die het op de landingspagina aandrijft. Beantwoord ze allebei, elke keer.

Een nalevingschecklist voor de campagne

Niets hiervan is in de praktijk lastig na te leven. Voor de gewone getrackte QR-campagne komt het werk neer op een korte lijst.

1. Kies een provider die standaard aggregeert en geen persoonlijke profielen opbouwt. Dit is dataminimalisatie (artikel 5, lid 1, onder c) concreet gemaakt: als je alleen aantallen nodig hebt, verzamel dan alleen aantallen.
2. Kort het IP in of anonimiseer het bij de redirect, en bewaar geaggregeerde statistieken. Wees eerlijk dat inkorten het risico verkleint in plaats van anonimiteit te garanderen, maar het is de juiste standaard en precies het soort maatregel waar het minimalisatiebeginsel om vraagt.
3. Zet een privacyverklaring op de landingspagina. De artikelen 13 en 14 verplichten je om mensen, op het moment van verzameling, te vertellen wie je bent, wat je verzamelt, waarom, je grondslag, hoe lang je het bewaart en welke rechten ze hebben. De landingspagina is dat moment van verzameling.
4. Vraag toestemming vóór elke niet-essentiële cookie of pixel op de bestemming. Als je pagina GA4 of een marketingpixel draait, is de toestemmingsbanner niet optioneel, en moet hij een echte keuze bieden in plaats van een muur.
5. Sluit een verwerkersovereenkomst met je QR- en analyticsprovider. Wanneer zij scangegevens in jouw opdracht verwerken, vereist artikel 28 een schriftelijke verwerkersovereenkomst. Onthoud de keten: jij bent meestal de verwerker voor je klant, die de verwerkingsverantwoordelijke is, en je QR-provider is jouw subverwerker.
6. Controleer waar de data staat. Geef de voorkeur aan een provider die in de EU of EER host. Belandt scandata in de VS of elders, dan heb je een goed doorgiftemechanisme nodig, ofwel de EU-VS Data Privacy Framework-certificering van de provider, ofwel modelcontractbepalingen plus een doorgiftebeoordeling.
7. Stel een bewaartermijn in en houd je eraan. Identificeerbare scanlogs zouden niet eeuwig moeten blijven bestaan. Bepaal hoe lang je ze echt nodig hebt, leg dat vast, en verwijder of aggregeer daarna.
8. Houd een route open voor verzoeken van betrokkenen. Als iemand vraagt wat je over hem bewaart of vraagt om het te wissen, moet je antwoord kunnen geven voor welke identificeerbare scandata je ook nog hebt.

Het grootste deel hiervan is providerconfiguratie plus één pagina verklaringstekst. De bureaus die in de problemen komen, zijn zelden degenen die getrackte codes draaien; het zijn degenen die marketingpixels op de landingspagina draaien zonder toestemming en zonder verklaring, en dat is een websiteprobleem dat toevallig achter een QR-code zit. Houd je de campagnes van elke klant in een eigen aparte werkruimte en weersta je de neiging om scandata over klanten heen te bundelen, dan voldoe je bijna gratis ook aan doelbinding.

Wat er verandert in Nederland en Duitsland

De AVG is één verordening voor de hele EU, maar ze wordt lokaal geïmplementeerd en lokaal gehandhaafd, en twee van de markten die dit product bedient verdienen een specifiek woord.

Nederland (AVG)

In het Nederlands is de GDPR de AVG, en de toezichthouder is de Autoriteit Persoonsgegevens (AP). Cookietoestemming staat in artikel 11.7a van de Telecommunicatiewet, dat toestemming vereist voor trackingcookies en strikt noodzakelijke en bepaalde privacyvriendelijke analytics-cookies vrijstelt. Wat nu telt, is de handhaving. In 2024 en 2025 stuurt de AP actief waarschuwingsbrieven naar organisaties die trackingcookies zonder geldige toestemming gebruiken, en pakt ze misleidende cookiebanners aan, waarbij ontvangers doorgaans rond de drie maanden krijgen om het op orde te brengen. Een Nederlandse landingspagina die GA4 draait zonder toestemming zit recht in het huidige schootsveld van de AP, wat punt vier op de checklist het belangrijkste maakt om serieus te nemen.

Duitsland (DSGVO)

In het Duits is de GDPR de DSGVO, die naast het federale BDSG staat en grotendeels wordt gehandhaafd door de deelstaatautoriteiten die via de DSK worden gecoördineerd. Toestemming voor apparaattoegang heeft een eigen wet, paragraaf 25 van het TDDDG (de opvolger uit 2024 van het TTDSG), die voorafgaande toestemming vereist voor cookies en vergelijkbare opslag en boetes tot 300.000 euro met zich meebrengt. Duitsland is historisch het strengste land op het gebied van IP-logging: het is geen toeval dat de Breyer-zaak daar begon, met een burger die de staat aanklaagde over diens webserverlogs. Het geruststellende deel is dat zelfs Duitsland het IP en de referrer in een gewoon HTTP-verzoek behandelt als data die het apparaat uit zichzelf verstuurt, niet als apparaattoegang die toestemming op grond van paragraaf 25 vereist. Het onderscheid tussen redirect en landingspagina houdt ook in de strengste markt stand.

Veelgestelde vragen

Zijn QR-codes AVG-proof?

De code zelf valt buiten de reikwijdte, want een gedrukte QR-code is passief en verzamelt niets. Naleving gaat over de twee lagen erachter. De redirect die een scan logt heeft een grondslag nodig (meestal gerechtvaardigd belang) maar doorgaans geen cookiebanner, en de landingspagina heeft een privacyverklaring nodig en toestemming voor niet-essentiële cookies. Krijg je die goed, dan is een getrackte QR-campagne volledig AVG-proof.

Houden QR-codes je in de gaten?

Een statische QR-code houdt niemand in de gaten; het is een gedrukte link zonder logging. Een dynamische, trackbare code logt de scangebeurtenis bij zijn redirect: je IP-adres, apparaattype, globale locatie en het tijdstip. Het houdt de scan in de gaten, niet je naam, en hoe ver het gaat hangt volledig af van de provider en de bestemmingspagina, niet van de QR-techniek zelf.

Verzamelen QR-codes persoonsgegevens?

De afbeelding verzamelt niets. De redirect achter een dynamische code logt je IP-adres, user-agent, tijdstempel en referrer, en een IP-adres is onder de AVG doorgaans een persoonsgegeven. Een getrackte QR-campagne verwerkt dus wel persoonsgegevens, en daarom heeft ze een grondslag en een privacyverklaring nodig, ook al komt ze nooit je naam te weten.

Heb je toestemming nodig om QR-scans te tracken?

Niet voor gewone geaggregeerde scananalytics die aan de serverkant bij de redirect gebeuren, want die kunnen rusten op gerechtvaardigd belang. Je hebt wél toestemming nodig voor alles wat het apparaat van de bezoeker op de landingspagina aanraakt, zoals Google Analytics, een marketingpixel of andere niet-essentiële cookies. De scanlog en de cookies van de landingspagina zijn twee aparte toestemmingsvragen.

Is een IP-adres een persoonsgegeven?

Ja, als uitgangspunt. Het Hof van Justitie oordeelde in Breyer (2016) dat een dynamisch IP-adres een persoonsgegeven is voor iedereen met de wettelijke middelen om de persoon erachter te identificeren. Behandel de IP-adressen in je scanlogs als persoonsgegevens, en minimaliseer of kort ze dienovereenkomstig in.

Gebruiken QR-codes cookies?

Nee. Noch de code noch de redirect plaatst een cookie; de redirect is een sprong aan de serverkant. Cookies verschijnen alleen als de bestemmingspagina ze plaatst, precies zoals op elke andere webpagina. Dat is ook waarom de cookietoestemmingsregels gelden voor je landingspagina en niet voor de scan.

Heeft een QR-codecampagne een privacyverklaring nodig?

Ja, als de landingspagina persoonsgegevens verzamelt of niet-essentiële cookies plaatst, en dat doen de meeste. De artikelen 13 en 14 van de AVG vereisen een privacyverklaring op het moment van verzameling, die mensen vertelt wat je verzamelt, waarom, je grondslag, hoe lang je het bewaart en hun rechten. Een duidelijke link ernaartoe vanaf de landingspagina is de norm.

Heb ik een verwerkersovereenkomst nodig met mijn QR-codeprovider?

Ja, als de provider scangegevens namens jou verwerkt, en dat doet een getrackte-QR-provider. Artikel 28 van de AVG vereist een schriftelijke verwerkersovereenkomst tussen jou (de verwerkingsverantwoordelijke, of de verwerker van je klant) en de provider (de verwerker of subverwerker). Betrouwbare providers bieden er standaard een aan; kan de jouwe dat niet, beschouw dat dan als een alarmsignaal.

De korte versie

Een QR-code is geen privacyrisico. Het patroon op de muur bewaart een link en verzamelt niets, en een statische code logt helemaal niets. Tracking zit op twee plekken achter een dynamische code: de redirect, die het scanverzoek logt (behandel die IP-adressen als persoonsgegevens, leun op gerechtvaardigd belang, en je hebt meestal geen cookiebanner nodig), en de landingspagina, waar cookies, analytics en pixels leven en waar toestemming vereist is. Houd die twee uit elkaar en het meeste verwarring op dit gebied verdwijnt gewoon.

Om een getrackte campagne netjes te draaien: kies een provider die standaard aggregeert en in de EU host, kort het IP in, schrijf een privacyverklaring voor de landingspagina, zet alle marketingtags achter echte toestemming, sluit een verwerkersovereenkomst, en stel een bewaartermijn in. Dat is een korte lijst, en niets ervan vertraagt de campagne. Doe het één keer, bouw het in je template, en je kunt de klant het antwoord geven dat hij echt wil: ja, we meten dit, en ja, het gebeurt netjes. Druk dan de code.