Cookies: functioneel versus niet-functioneel, met voorbeelden
De wet vraagt geen toestemming voor cookies die strikt noodzakelijk zijn om een dienst te leveren die je zelf hebt gevraagd. Voor al het andere wel, vooraf. Het verschil tussen die twee is de hele cookiewet, en het wordt structureel verkeerd getrokken. Hier staat per soort cookie of hij zonder toestemming mag, met echte voorbeelden en de toets die je zelf kunt doen.
De enige vraag die telt¶
De cookiewet, artikel 11.7a van de Telecommunicatiewet, kent maar twee uitzonderingen op de toestemmingsplicht. Een cookie mag zonder toestemming als hij dient om communicatie over een netwerk uit te voeren, of als hij strikt noodzakelijk is om een dienst te leveren die de gebruiker zelf uitdrukkelijk heeft gevraagd.
Let op het woord strikt. Niet handig, niet gebruikelijk, niet nuttig voor de organisatie. Strikt noodzakelijk voor de dienst die de bezoeker vroeg. De toets is: valt de dienst om zonder deze cookie, vanuit het perspectief van de bezoeker?
Dat is de hele wet. Al het andere volgt daaruit. Toch wordt het structureel verkeerd getrokken, en het patroon is altijd hetzelfde: de organisatie bepaalt wat noodzakelijk is vanuit haar eigen bedrijfsvoering, niet vanuit de dienst die de bezoeker aanvroeg.
Letterlijk: wat ik aantrof voor de toestemmingsvraag¶
Hieronder staan de cookies die ik op Nederlandse overheidssites daadwerkelijk aantrof in de modus waarin de bezoeker niets deed. Geen klik, geen keuze, alleen de pagina openen. De aantallen komen uit de scan van 14 juli 2026 over 1.718 sites.
Dit mag zonder toestemming (functioneel):
JSESSIONID 48 sites sessie op een Java-server, houdt je ingelogd
ASP.NET_SessionId 22 sites idem op een .NET-server
PHPSESSID idem op PHP, de bekendste van de drie
Archiefsessid 32 sites sessie binnen een archiefomgeving
GUEST_LANGUAGE_ID 18 sites onthoudt je taalkeuze
COOKIE_SUPPORT 18 sites test of je browser cookies aanneemt
cookies_consent 17 sites onthoudt je eigen cookiekeuze
OptanonConsent idem, van OneTrustDe laatste twee verdienen toelichting, want ze zorgen voor verwarring. De cookie die jouw keuze onthoudt is zelf functioneel. Zou hij dat niet zijn, dan moest je bij elke pagina opnieuw kiezen, en dat is precies de dienst die je vroeg. Een toestemmingsmodule mag dus een cookie zetten. Wat hij niet mag, is naast die keuze-cookie ook nog telemetrie over jou wegsturen. Zie Je cookiebanner is zelf een tracker.
Dit mag niet zonder toestemming, en stond er toch:
stg_traffic_source_priority 730 sites Piwik PRO tag manager
stg_last_interaction 730 sites idem, legt je gedrag vast
stg_returning_visitor 730 sites idem, herkent je als terugkeerder
stg_externalReferrer 353 sites idem, legt vast waar je vandaan kwam
_ga 143 sites Google Analytics, jouw bezoeker-ID
_gid 51 sites Google Analytics, per dag
_gat 17 sites Google Analytics, snelheidsregeling
_pk_id / _pk_ses 18 sites Matomo of Piwik, bezoeker en sessie
VISITOR_INFO1_LIVE 20 sites YouTube, via een ingesloten video
YSC 20 sites YouTube, sessie
__Secure-YNID 20 sites YouTube, identificatie
__Secure-ROLLOUT_TOKEN 20 sites YouTube
VISITOR_PRIVACY_METADATA 20 sites YouTube, ironisch genoegHet woord stg_returning_visitor is de scherpste illustratie die er bestaat. Een cookie die letterlijk vastlegt dat jij hier eerder was, gezet voordat je iets kon kiezen, op 730 overheidssites.
En dit is het grijze gebied, met de redenering erbij:
__cf_bm 52 sites Cloudflare bot managementCloudflare zet deze cookie om geautomatiseerd verkeer te onderscheiden van mensen. Het argument voor de uitzondering is dat de dienst zonder botbescherming omvalt. Het argument ertegen is dat de bezoeker geen botbescherming vroeg, maar een webpagina. Mijn eigen standpunt: als de cookie uitsluitend een kortlopend beveiligingsdoel dient, niet over sites heen leest en niet naar analytics gaat, is de uitzondering verdedigbaar. Kun je dat niet aantonen, dan is hij toestemmingsplichtig. Label dit als verdedigbaar, niet als vaststaand.
Analytics is geen aparte categorie¶
De hardnekkigste misvatting is dat analytics een eigen uitzondering heeft. Die bestaat niet in de wet. Wat wel bestond, is een handreiking van de Autoriteit Persoonsgegevens voor analytics-cookies die zo zijn ingericht dat de inbreuk verwaarloosbaar is. Die pagina is inmiddels van de site verdwenen en de toezichthouder heeft laten weten de norm nog verder in te vullen, dus ik noem de voorwaarden hier als historische lijn en niet als geldend recht. Ze luidden, cumulatief:
1. een verwerkersovereenkomst hebben met de leverancier; 2. het laatste octet van het IP-adres maskeren; 3. gegevensdeling met de leverancier voor eigen doeleinden uitzetten; 4. geen cookies van derden gebruiken die de leverancier over sites heen kan koppelen; 5. de bezoeker hierover informeren in je privacyverklaring.
Als een van deze vijf ontbreekt, is je analytics gewoon toestemmingsplichtig. In mijn metingen is punt 3 het vaakst het struikelblok, en punt 4 daarna: zodra je Google Analytics via de standaardconfiguratie draait, staat gegevensdeling aan en gaat het naar een partij die het over duizenden sites kan aan elkaar knopen.
Zelf gehoste analytics, Matomo of Piwik PRO op je eigen domein, komt veel dichter bij de uitzondering. Maar zelf gehost is geen vrijbrief, en juist dat maakt het het scherpste voorbeeld in dit hele stuk.
Waarom Piwik het beste voorbeeld is van goede bedoelingen¶
De Nederlandse overheid heeft Piwik PRO breed uitgerold als vervanger van Google Analytics. De redenering erachter is verdedigbaar en zelfs prijzenswaardig: geen Amerikaanse partij, geen doorgifte buiten Europa, gegevens onder eigen beheer, en een leverancier die je contractueel kunt binden. Dat is precies wat je wilt dat een overheid doet.
Toen ik het mat, vond ik op 730 van de gemeten sites deze cookies staan voordat de bezoeker iets had gekozen:
stg_traffic_source_priority 730 sites
stg_last_interaction 730 sites
stg_returning_visitor 730 sites
stg_externalReferrer 353 sitesDie stg_-cookies horen bij de tagbeheerder van Piwik PRO, en ze leggen gedrag vast. Ze stonden er voordat er iets te kiezen viel. Op de sites waar rijksoverheid.nl als partij optrad, ging het om 668 van de 669. Zie De rijksbrede analytics staat op 668 sites voor toestemming.
De intentie was soevereiniteit. Het effect is dat er nog steeds gedrag wordt vastgelegd voordat iemand ja heeft gezegd, alleen nu op een Europese server.
Dat is geen kleinigheid, want het juridische probleem verandert er niet door. Artikel 11.7a vraagt niet waar de server staat. Het vraagt of er iets is opgeslagen of gelezen op de apparatuur van de gebruiker zonder toestemming. Een Belgische server met een Nederlandse verwerkersovereenkomst maakt dat niet anders.
En het is precies daarom een goed voorbeeld. Er is hier niemand aan te wijzen die het slecht bedoelde. Iemand koos een privacyvriendelijker pakket, iemand anders zette de tagbeheerder standaard aan, en niemand controleerde daarna wat er in de nulmeting gebeurt. De keuze was goed, de uitvoering niet.
Wie hierop reageert met "wij hebben juist voor de privacyvriendelijke optie gekozen" heeft gelijk over de intentie en ongelijk over het effect. Zie Bij gedrag telt het effect, bij de persoon de intentie.
Wat je dan wel doet. De reparatie is niet het pakket vervangen. Het is de tagbeheerder zo configureren dat hij zonder toestemmingsvlag niets uitvoert, en dat daarna zelf natrekken in een schoon browserprofiel. Dat is dezelfde toets als hieronder, en hij kost vijf minuten.
"Maar functionele cookies mag ik toch plaatsen?"¶
Dit is het antwoord dat ik het vaakst terugkrijg, en het is technisch juist. Ja, functionele cookies mogen zonder toestemming. Daar gaat de discussie ook niet over.
De discussie gaat over wie bepaalt wat functioneel is. In de praktijk plakt de organisatie dat label er zelf op, en de toets verschuift dan ongemerkt van "valt de dienst om zonder deze cookie, gezien vanuit de bezoeker" naar "hebben wij hier een reden voor". Dat zijn twee verschillende vragen, en alleen de eerste staat in de wet.
Een paar voorbeelden van die verschuiving, allemaal aangetroffen:
"onze analytics is functioneel, want we moeten weten of de site werkt"
→ de bezoeker vroeg een pagina, geen meting van zichzelf
"onze A/B-test is functioneel, want anders kunnen we niet verbeteren"
→ verbeteren is jouw belang, geen dienst die hij aanvroeg
"de tagbeheerder is functioneel, want zonder hem laadt er niets"
→ dan heb je je site zo gebouwd dat een meetinstrument
onmisbaar is geworden, en dat is een keuzeDe wet is de ondergrens, niet het doel¶
Hier zit het patroon waar het mij werkelijk om gaat. Wie bij elke keuze vraagt "mag dit nog net", gebruikt de wet als plafond. Dat is precies omgekeerd. De wet beschrijft waar het onaanvaardbaar wordt, en dat is de bodem van wat je kunt doen.
Er zijn twee vragen, en ze zijn allebei geldig:
1. Mag dit? Een juridische vraag met een juridisch antwoord. 2. Moet ik dit willen? Een vraag over wat je aan een ander doet.
Wie alleen de eerste stelt, komt onvermijdelijk uit bij de mazen. Niet omdat hij een slecht mens is, maar omdat de vraag zelf naar de rand leidt. Als "mag het" je enige toets is, dan zoek je per definitie de grens op.
En dat is ook de reden dat de regels steeds strenger worden. Elke maas die stelselmatig wordt gebruikt, wordt uiteindelijk dichtgetimmerd, en dan geldt de nieuwe regel ook voor iedereen die hem nooit nodig had.
De toets die geen jurist nodig heeft¶
Ik gebruik zelf twee vragen, en ze werken beter dan een juridische analyse.
De uitlegtoets. Zou je in de banner in gewone taal kunnen opschrijven wat je doet, zonder dat het gek klinkt? "Wij onthouden je taalkeuze" is prima. "Wij leggen vast dat je hier eerder was, voordat je iets mocht kiezen, zodat wij ons bereik kunnen rapporteren" is een zin die niemand durft op te schrijven. Dat is geen toeval.
De omkeertoets. Zou je het acceptabel vinden als het jou overkwam op een site waar je niet omheen kunt? Bij een overheidsloket, een zorgportaal, een schoolomgeving? Als het antwoord nee is, heb je je antwoord.
Geen van beide is een juridisch criterium. Allebei voorspellen ze verrassend goed wat een toezichthouder ervan vindt.
Verantwoorden is iets anders dan goedpraten¶
De AVG kent een verantwoordingsplicht. Je moet kunnen aantonen dat je het goed doet, en dat is een actieve verplichting. Het is niet genoeg om achteraf een verklaring te hebben waarom het mocht.
Dat onderscheid is scherper dan het lijkt:
GOEDPRATEN achteraf een reden zoeken waarom het toch mag
VERANTWOORDEN vooraf vastleggen waarom je het doet, wat je hebt
afgewogen, en hoe je controleert dat het kloptWie goedpraat, heeft een argument. Wie verantwoordt, heeft een dossier. Het verschil merk je pas als iemand doorvraagt, en dan is het te laat om het alsnog te maken.
Voor de duidelijkheid: dit is mijn opvatting en geen meting. Ik label het als gedachte. Wat wel gemeten is, staat hierboven: op de sites waar men het label functioneel het ruimst opvatte, stonden de meeste cookies vóór de vraag.
Waar je als bouwer op moet letten¶
Dit is de checklist die ik zelf afloop, in deze volgorde, omdat elke stap goedkoper is dan de volgende.
Stap 1. Tel wat er laadt voordat je iets klikt. Open de ontwikkelaarstools, tabblad netwerk, laad de pagina, doe niets. Alles wat je daar ziet naar een ander domein dan je eigen, is verdacht tot het tegendeel blijkt. Sla het op als HAR-bestand zodat je het later kunt narekenen. Zie Netwerkverkeer lezen via HAR-files.
Stap 2. Haal je lettertypen, kaarten en scripts van je eigen server. Dit is de grootste bron van pre-consent verkeer op Nederlandse overheidssites, en de makkelijkste te repareren. Zie Wat je van een CDN haalt, laadt voor je banner.
Stap 3. Vervang ingesloten video door een facade. Een YouTube-embed zet vijf cookies voordat iemand op play drukt. Een statische afbeelding met een afspeelknop die de echte speler pas na de klik laadt, kost je twintig regels code. Het youtube-nocookie.com-domein helpt, maar het is geen volledige oplossing: het stelt het zetten van cookies uit tot de klik, en dat is precies wat je wilt, maar controleer het zelf per implementatie.
Stap 4. Zet je tag manager op weigeren als startstand. De meeste tag managers laden hun eigen container voordat de toestemmingsstatus bekend is. Dat is een instelling, geen wet van de natuur. Configureer de container zo dat er zonder expliciete toestemmingsvlag niets vuurt.
Stap 5. Test je weigerknop echt. Klik weigeren, herlaad, kijk opnieuw in het netwerktabblad. Op vier van de vijf gemeten sites was er geen verschil. Zie Weigeren doet op vier van de vijf sites niets.
Stap 6. Controleer je DNS op verhulde derden. Een subdomein van jezelf dat via een CNAME naar een tracker wijst, telt juridisch als een derde partij, maar gedraagt zich technisch als eigen verkeer. Zie CNAME-cloaking zit op vier op de tien overheidssites.
Wat je als bouwer niet moet willen¶
Niet: een toestemmingsmodule kopen en denken dat je klaar bent. De module is een vraag, niet een slot. In mijn metingen laadde bij twee van de gemeten modules op elke onderzochte site al iets voordat de vraag beantwoord was.
Niet: gegevens verzamelen omdat het kan. Elk veld dat je verzamelt is een veld dat kan lekken, dat je moet verantwoorden en dat je moet bewaren binnen een termijn. Wat je niet bewaart, kan niet lekken.
Niet: de privacyverklaring laten schrijven door iemand die de code niet heeft gezien. Het gat tussen de verklaring en de uitvoering is de meest voorkomende bevinding in mijn werk. Zie Papier versus code: de verklaring en de uitvoering.
Niet: aannemen dat een keurmerk of een gerenommeerde leverancier je vrijwaart. Ik heb de partijen gemeten die privacy keuren, en ze zakten zelf voor de toets.
De toets die je zelf kunt doen, in vijf minuten¶
1. Open een privevenster, ga naar je site, doe niets. 2. Ontwikkelaarstools, tabblad Application of Opslag, kijk onder Cookies. 3. Staat er iets anders dan een sessie-, taal- of keuzecookie? Dan heb je een probleem. 4. Klik weigeren, herlaad, kijk opnieuw. 5. Is de lijst gelijk gebleven? Dan heb je een groter probleem, want dan is je weigerknop een decorstuk.
Dit kost minder tijd dan het lezen van je eigen cookieverklaring, en het levert bewijs op in plaats van een indruk.