De meeste kleine en middelgrote ondernemingen die een cookiebanner hebben, denken dat ze daarmee aan de cookieregelgeving voldoen. Dat is echter niet het geval. De banner vormt slechts de helft van het geheel: het mechanisme voor het verkrijgen van toestemming. De andere helft – de inventarisatie van waarvoor de banner daadwerkelijk toestemming vraagt – is het punt waarop toezichthouders bij controles steeds weer tekortkomingen constateren. Een controle in 2024 door de Nederlandse Autoriteit Persoonsgegevens, de Franse CNIL en de Italiaanse Garante bracht hetzelfde patroon aan het licht op honderden websites: er waren wel banners aanwezig, maar er was geen onderliggende registratie van welke trackers worden geactiveerd, wie ze instelt, welke gegevens ze van het apparaat lezen en of ze daadwerkelijk correct zijn geclassificeerd.

Een cookie- en trackerinventaris is de documentatielaag onder uw CMP. Dit is wat een auditor vraagt wanneer de banner-controle is doorstaan. Deze gids legt uit wat een inventaris moet bevatten, waarom deze los staat van uw AVG-datamap, wat ePrivacy-artikel 5, lid 3, daadwerkelijk vereist, en hoe u de inventaris actueel kunt houden zonder dit dubbel te doen.

ePrivacy art. 5, lid 3: de regel die de meeste MKB-bedrijven verkeerd interpreteren

Artikel 5, lid 3, van de ePrivacy-richtlijn 2002/58/EG — soms de "cookiewet" genoemd, maar nauwkeuriger de regel inzake eindapparatuur — vereist voorafgaande toestemming voordat er informatie wordt opgeslagen op of uitgelezen van het apparaat van een gebruiker. Twee zaken maken dit moeilijker dan het lijkt:

Het is zelfs van toepassing wanneer de opgeslagen gegevens geen persoonsgegevens zijn. Een tellercookie die registreert "dit is het derde bezoek van de gebruiker" valt onder art. 5, lid 3, ongeacht of die telling aan een geïdentificeerde persoon kan worden gekoppeld. ePrivacy en de AVG zijn afzonderlijke wettelijke kaders; voldoen aan de AVG betekent niet automatisch dat u ook aan ePrivacy voldoet.

Het is van toepassing op alles wat op het apparaat is opgeslagen, niet alleen op cookies. localStorage, sessionStorage, IndexedDB-vermeldingen, pixeltags die bestaande identificatiegegevens lezen, SDK-beacons, fingerprinting dat een stabiel signaal afleidt uit de browser, service-worker-caches — het zijn allemaal "gegevens die zijn opgeslagen op de eindapparatuur van een abonnee of gebruiker". Als uw inventaris alleen cookies op naam bijhoudt, mist u het grootste deel van wat toezichthouders nu controleren.

De uitzondering is beperkt: een tracker is alleen zonder toestemming toegestaan als deze "strikt noodzakelijk" is om de dienst te leveren waar de gebruiker uitdrukkelijk om heeft gevraagd. Het Hof van Justitie van de Europese Unie (HvJ-EU) en nationale gegevensbeschermingsautoriteiten interpreteren dit strikt. Sessiecookies voor een afrekenproces waarbij de gebruiker is ingelogd, komen in aanmerking. Analytics die "ons helpen de dienst te verbeteren" doen dat niet. Marketingpixels doen dat nooit.

Wat moet er in de inventaris worden opgenomen

Een cookie- en trackerinventaris is uitgebreider dan de cookielijst die uw CMP-scanner weergeeft. Zes categorieën van opslag- en signaalverzamelingsmechanismen tellen mee:

  • Cookies — first-party en third-party, sessiecookies en permanente cookies
  • localStorage en sessionStorage — sleutel-waardeopslagplaatsen in de browser die langer blijven bestaan dan cookies voor first-party-bronnen
  • Pixeltags — 1×1-afbeeldingsverzoeken die identificatiegegevens in de URL bevatten of bestaande cookies op het doeldomein lezen
  • SDK's — JavaScript-bibliotheken van derden (analytics, chatwidgets, foutmonitors, advertentienetwerken) die vaak hun eigen cookies plaatsen en lezen of schrijven naar localStorage en beacons activeren
  • Fingerprinting — het afleiden van een stabiele identificatiecode uit apparaatkenmerken (canvas, WebGL, lettertypelijst, audiocontext). Zelfs zonder iets op te slaan, leest fingerprinting gegevens van het apparaat — artikel 5, lid 3 is van toepassing.
  • Beacons — navigator.sendBeacon()-aanroepen die worden geactiveerd bij het sluiten van de pagina, gebruikelijk in SDK’s voor analyse en foutrapportage

Voor elke vermelding moet het controleerbare dossier ten minste het volgende bevatten: naam, aanbieder (het bedrijf erachter), het domein waarnaar het verwijst, type, doel, duur, de ePrivacy-grondslag (toestemming of strikt noodzakelijk) en het toestemmingsmechanisme dat hierover waakt (uw CMP, of "geen CMP — strikt noodzakelijk"). Als er iets ontbreekt, kunt u de vraag van de toezichthouder "toont u mij de rechtsgrond voor deze specifieke tracker op deze specifieke dienst" niet beantwoorden.

Inventaris ≠ CMP — ze vervullen verschillende taken

Een CMP (Consent Management Platform) — Cookiebot, OneTrust, Didomi, Iubenda, Usercentrics, Cookie Information, Axeptio — doet drie dingen:

  1. De banner weergeven met schakelaars voor de categorieën
  2. Individuele gegevens over toestemming opslaan met een tijdstempel en de versie van het geldende beleid
  3. Trackers blokkeren totdat toestemming is gegeven (de technische handhavingslaag)

Een CMP is operationeel. Het wordt bij elke paginalading uitgevoerd. Het is de taak ervan om toestemming in realtime te beheren.

Een inventaris doet iets anders: het is de documentatie van waarvoor het CMP toestemming vraagt. Het beantwoordt vragen die een CMP niet kan beantwoorden:

  • Waarom wordt deze tracker geclassificeerd als analyse in plaats van marketing?
  • Wie binnen de organisatie heeft de toevoeging van de LinkedIn Insight Tag goedgekeurd, en op welke datum?
  • Welke gegevens leest of schrijft deze SDK daadwerkelijk – afgezien van wat de documentatie van de leverancier beweert?
  • Als een toezichthouder vraagt: "Toon de noodzaak van deze analytische cookie aan op basis van uw beoordeling van gerechtvaardigde belangen", wat is dan het antwoord?
  • Wanneer de cookielijst verandert – een nieuwe SDK toegevoegd, van leverancier gewisseld – verschijnt de wijziging dan in uw auditlog?

Een CMP-scan vertelt u welke cookies vandaag worden geactiveerd. Een inventaris vertelt u welke cookies zouden moeten worden geactiveerd, waarom elke cookie op de lijst staat en wat er in de afgelopen zes maanden is veranderd. De twee vullen elkaar aan; geen van beide vervangt de ander.

Dit is ook de reden waarom toezichthouders steeds vaker om beide vragen. Een CMP zonder inventaris is een vlag zonder rechtvaardiging. Een inventaris zonder CMP is een register zonder handhavingsmechanisme. MKB-bedrijven die beide door elkaar halen — meestal door de automatische scan van de CMP als de inventaris te beschouwen — komen er tijdens een audit achter dat de CMP-scanner de SDK's heeft gemist die pas worden geactiveerd na een klik op een knop, de analytics-beacon die alleen bij fouten wordt geactiveerd, en de localStorage-vermelding die de chatwidget schrijft nadat de gebruiker een bericht heeft getypt.

De vier categorieën trackers

Elke serieuze CMP en elk richtsnoer van een toezichthouder deelt trackers in dezelfde vier categorieën in. Deze indeling bepaalt zowel het proces voor toestemming als de risicopositie van de inventaris.

Strikt noodzakelijk. Trackers zonder welke de expliciet aangevraagde dienst niet kan functioneren. Sessie-identificatoren voor een geauthenticeerde sessie, een CSRF-token-cookie, de cookie die uw taalvoorkeur voor het huidige bezoek onthoudt, de affinity-cookie van de load-balancer. Deze zijn vrijgesteld van de toestemmingsvereiste. Wees conservatief — als een toezichthouder aannemelijk zou kunnen stellen dat "de dienst ook zonder dit zou functioneren", is het niet strikt noodzakelijk.

Functioneel. Trackers die de gebruikerservaring verbeteren maar niet essentieel zijn — het onthouden van UI-voorkeuren tussen sessies, het onthouden van een lijst met recent bekeken items, taalvoorkeur die bij bezoeken behouden blijft. Hiervoor is toestemming vereist. De grens tussen strikt noodzakelijk en functioneel is smal en vaak omstreden; het documenteren van uw redenering per tracker is wat een audit doorstaat.

Analytics. Trackers die meten hoe de dienst wordt gebruikt — paginaweergaven, sessieduur, conversiepaden, foutpercentages. Het Hof van Justitie van de Europese Unie (HvJ-EU) en de meeste nationale gegevensbeschermingsautoriteiten hebben geoordeeld dat zelfs first-party analytics toestemming vereisen, tenzij de gegevens daadwerkelijk geaggregeerd zijn en uitsluitend door de verwerkingsverantwoordelijke worden gebruikt voor het meten van zijn eigen dienst. Zelfgehoste Matomo met IP-anonimisering en zonder cross-site tracking komt het dichtst in de buurt van een analytics-opstelling zonder toestemming; Google Analytics 4 doet dat niet.

Marketing. Retargetingpixels, advertentienetwerk-identificatoren, conversietags, trackingpixels voor sociale media. Vereisen altijd toestemming. Bijna altijd van derden. De categorie die de meeste aandacht van handhavingsinstanties trekt.

De inventaris registreert de categorie voor elke tracker, de ePrivacy-grondslag (toestemming of noodzakelijk) en — cruciaal — de motivering. De categorie bepaalt de toestemmingsstroom; de motivering bepaalt of de classificatie standhoudt bij controle.

ePrivacy-grondslag versus rechtsgrond van AVG art. 6: verwar ze niet

Dit is de meest voorkomende fout in de cookiedocumentatie van het MKB. ePrivacy art. 5, lid 3 en AVG art. 6 zijn afzonderlijke rechtsgronden, die afzonderlijke vragen stellen:

  • ePrivacy art. 5, lid 3 vraagt: mag deze tracker überhaupt op het apparaat worden geplaatst? Het antwoord is consent of strictly necessary.
  • AVG art. 6 vraagt: als deze verwerking persoonsgegevens oplevert, wat is dan de rechtsgrond voor de verwerking ervan? Het antwoord is een van de zes gronden van art. 6, lid 1: toestemming, overeenkomst, wettelijke verplichting, vitale belangen, openbare taak, gerechtvaardigde belangen.

Een first-party analytisch cookie waarvoor toestemming van de gebruiker vereist is op grond van de ePrivacy-richtlijn, mag, nadat toestemming is gegeven, de daaruit voortvloeiende gegevens verwerken op grond van AVG art. 6, lid 1, onder a) (toestemming) — of op grond van art. 6, lid 1, onder f) (gerechtvaardigde belangen) zodra de toestemming op geldige wijze is verkregen voor het plaatsen van het cookie. In sommige interpretaties berusten zowel het plaatsen als de verwerking op de toestemming; in andere is het plaatsen afhankelijk van toestemming en de verwerking op gerechtvaardigde belangen. De richtsnoeren van nationale gegevensbeschermingsautoriteiten (DPA's) lopen uiteen. Wat universeel is: de twee rechtsgronden worden afzonderlijk geregistreerd. Een inventaris die slechts één veld "rechtsgrond" per tracker heeft, vermengt de twee en levert een register op dat geen enkele DPA zal accepteren.

Een serieuze inventaris heeft voor elke tracker een veld 'legal_basis_eprivacy' (toestemming / noodzakelijk) en een apart veld 'legal_basis' voor de persoonsgegevens die de tracker genereert (de grondslag van artikel 6 AVG). Deze staan in verschillende tabellen in het datamodel omdat ze verschillende vragen beantwoorden.

Wat verandert er onder het voorstel voor de Digital Omnibus

In november 2025 publiceerde de Europese Commissie het voorstel voor de Digital Omnibus COM(2025) 837 definitief. Het is nog niet aangenomen — en het is niet zeker of het in zijn huidige vorm zal worden goedgekeurd — maar de koers die wordt ingezet is van belang omdat deze de handhaving van de ePrivacy-richtlijn ingrijpend zou veranderen.

Het voorstel zou de regel inzake cookies/eindapparatuur verplaatsen van artikel 5, lid 3, van de e-privacyverordening naar een nieuw artikel 88 bis van de AVG voor abonnees die natuurlijke personen zijn. Zes genoemde doeleinden zouden zonder toestemming rechtmatig zijn: het uitvoeren van elektronische communicatie, het verlenen van een expliciet gevraagde dienst, geaggregeerde publieksmetingen voor eigen gebruik door de verwerkingsverantwoordelijke, het handhaven van de veiligheid van de dienst en het ondersteunen van diensten van de informatiemaatschappij waar de gebruiker om heeft gevraagd. Weigering van toestemming zou met één klik moeten kunnen gebeuren, en een verwerkingsverantwoordelijke wiens verzoek is geweigerd, zou ten minste zes maanden moeten wachten alvorens het opnieuw te vragen.

Een bijbehorend art. 88b zou verwerkingsverantwoordelijken verplichten om machine-leesbare toestemmingssignalen te respecteren — Global Privacy Control, een toekomstige ESO-standaard — zodra de technische specificaties zijn gepubliceerd, en zou browsers die geen MKB-bedrijven zijn, verplichten deze te verstrekken.

Voor MKB-bedrijven die momenteel een tracker-inventaris bijhouden, verandert er operationeel niets. Het huidige onderscheid tussen toestemming en noodzaak in ePrivacy art. 5, lid 3 blijft correct onder de geldende ePrivacy-richtlijn. Er volgen echter twee toekomstgerichte richtlijnen:

  • De taxonomie die in de toekomst van belang is, is doel, niet cookietype. Een inventaris die het doel van elke tracker vastlegt (de expliciete dienst waar de gebruiker om heeft gevraagd, publieksmeting voor eigen gebruik, enz.) sluit naadloos aan bij de regeling van artikel 88 bis, mocht deze van kracht worden. Een inventaris die alleen "analytics — toestemming vereist" registreert, moet opnieuw worden geclassificeerd.
  • Ondersteuning voor machinaal leesbare signalen van toestemming wordt een CMP-functie, geen inventarisfunctie — maar de inventaris moet vastleggen welke CMP in gebruik is, zodat de auditor de naleving van art. 88b kan verifiëren zodra de norm is gepubliceerd.

Het voorstel is gedateerd en geeft expliciet een vooruitblik op toekomstige wetgeving. Bouw voor de huidige wetgeving; ontwerp voor de voorgestelde richting.

Hoe Readmodel® omgaat met cookie- en tracker-inventarissen

Readmodel® houdt de cookie- en tracker-inventaris bij op serviceniveau — binnen hetzelfde datamodel waarin uw services, gegevensitems en overdrachten worden opgeslagen — zodat een tracker altijd gekoppeld is aan de service die deze plaatst, de gegevens die deze leest of genereert, en (wanneer er persoonsgegevens uit voortvloeien) het AVG-verwerkingsrecord dat er gebruik van maakt.

Elke tracker-vermelding bevat: naam, aanbieder, domein, type (cookie / localStorage / pixel / fingerprint / SDK / beacon / overig), categorie (strictly_necessary / functional / analytics / marketing), de toestemmingsstatus (toestemming / necessary) — bewust zo genoemd om verwarring te voorkomen met de AVG-legal_basisen van artikel 6 met betrekking tot gegevensitems — doel, duur, de verwijzing naar het toestemmingsmechanisme (uw CMP) en een optionele URL naar de documentatie van de leverancier.

Een voorgevulde bibliotheek met 167 veelvoorkomende trackers — waaronder EU-CMP's (Cookiebot, Didomi, Iubenda, Usercentrics, Axeptio), analytics (GA4, Matomo, Piwik PRO, Hotjar, Microsoft Clarity), advertentienetwerken (Meta, LinkedIn, TikTok, Criteo, RTB House, Google Ads), chatwidgets (Intercom, Crisp, LiveChat, Tidio), betalings-SDK's (Stripe, Adyen, Mollie, Klarna), identiteitsbeheer (Auth0, Keycloak, NextAuth.js), e-commerce (Shopify, WooCommerce, Magento), foutopsporing/APM (Sentry, Datadog, New Relic) en CMS-patronen (WordPress, Drupal, TYPO3) – dekt de meeste MKB-stacks in slechts enkele muisklikken. Aangepaste vermeldingen volgen hetzelfde schema.

Het risicoregister markeert automatisch elke niet-essentiële tracker (category != 'strictly_necessary' en legal_basis_eprivacy = 'consent') waarvoor geen mechanisme voor toestemming op rijniveau is gedocumenteerd en geen CMP projectbreed is ingesteld. Op elk van beide niveaus verdwijnt de markering — dus MKB-bedrijven die één CMP op projectniveau documenteren (bijvoorbeeld Cookiebot voor de hele site) hoeven dit niet op elke trackerrij te herhalen.

Een ingebouwde cookie-beleidsgenerator produceert een afdrukbaar en als Markdown/HTML te kopiëren cookie-beleidsdocument, waarin trackers per categorie worden gegroepeerd en beschrijvingen en geldigheidsduur worden opgenomen. Dit is het document dat u op uw website publiceert om te voldoen aan de transparantie-eis die naast de vereiste toestemming geldt.

Cruciaal is dat Readmodel® uw CMP niet vervangt. Het genereert geen toestemmingsbanners, slaat geen individuele toestemmingsgegevens op, parseert geen TCF-strings en scant uw site niet automatisch. Het is de inventarislaag onder de CMP die u gebruikt. Voor een breder beeld van hoe Readmodel® past binnen de rest van uw privacystack, zie de vergelijking van tools voor AVG-compliance.

Cookie- en trackerinventaris: veelgestelde vragen

Is een cookie-inventaris wettelijk verplicht? De cookie-inventaris zelf wordt in geen enkele wet genoemd, maar de verplichting waaraan deze voldoet wel. Artikel 5, lid 3, van de ePrivacy-richtlijn vereist toestemming voordat informatie op het apparaat van een gebruiker wordt geplaatst of gelezen, met uitzondering van strikt noodzakelijke trackers. Op grond van het verantwoordingsbeginsel van de AVG (art. 5, lid 2) moet de verwerkingsverantwoordelijke kunnen aantonen dat aan de voorschriften wordt voldaan — wat in de praktijk neerkomt op een gedocumenteerd overzicht van elke tracker, de categorie, het doel en de rechtsgrond. Toezichthouders vragen tijdens audits steeds vaker om dit overzicht.

Geeft mijn CMP-scanner mij het overzicht niet automatisch? Een CMP-scanner geeft u een momentopname van de cookies die tijdens de scan zijn geactiveerd. De scanner mist trackers die voorwaardelijk worden geactiveerd (na een klik op een knop, bij fouten, in geauthenticeerde gebieden waar de scanner niet is ingelogd), mist bij de meeste abonnementen opslag zonder cookies (localStorage, fingerprinting, beacons) en registreert niet de redenering achter uw categoriseringen. Gebruik de scanner als input voor de inventaris; beschouw de output van de scanner niet als de inventaris.

Wat is het verschil tussen strikt noodzakelijk en functioneel? Strikt noodzakelijke trackers zijn die zonder welke de dienst die de gebruiker expliciet heeft aangevraagd niet kan werken — sessie-identificatoren voor een afrekenproces, CSRF-tokens, load-balancer-affiniteit. Functionele trackers verbeteren de gebruikerservaring, maar zijn niet essentieel — het onthouden van UI-voorkeuren tussen sessies, lijsten met recent bekeken items. Strikt noodzakelijke trackers zijn vrijgesteld van toestemming; functionele trackers vereisen toestemming. Nationale gegevensbeschermingsautoriteiten interpreteren de vrijstelling strikt; bij twijfel dient u deze als functioneel te classificeren en toestemming te vragen.

Moet ik trackers van derden inventariseren? Ja. Alles wat informatie op het apparaat van de gebruiker plaatst of leest, telt mee, ongeacht wie het beheert. Ingesloten YouTube-video’s die DoubleClick-cookies plaatsen, Stripe Elements die cookies voor fraudepreventie plaatsen, de ingesloten Google Maps die NID plaatst — al deze moeten in de inventaris worden opgenomen, met vermelding van de externe aanbieder.

Moet mijn fingerprinting-bibliotheek in de inventaris worden opgenomen? Ja. Fingerprinting leest kenmerken van het apparaat van de gebruiker om een stabiele identificatiecode af te leiden — het Hof van Justitie van de Europese Unie (HvJ-EU) en het Europees Comité voor gegevensbescherming (EDPB) hebben bevestigd dat dit onder artikel 5, lid 3, valt, zelfs wanneer er niets wordt opgeslagen. Documenteer de bibliotheek, het doel ervan en het mechanisme voor toestemming dat de toegang regelt. De meeste fingerprinting in productie is bedoeld voor fraudepreventie (Sift, Forter, DataDome) en kan worden aangemerkt als strikt noodzakelijk voor veiligheidsdoeleinden; documenteer de redenering.

Hoe verhoudt dit zich tot de EU AI-verordening? Als u AI gebruikt op de gegevens die uw trackers verzamelen — op clickstreams gebaseerde aanbevelingssystemen, modellen voor gedragsgerichte advertenties, ML voor fraudedetectie — valt de AI-verwerkingslaag onder de EU AI-verordening, terwijl de onderliggende plaatsing van trackers onder ePrivacy valt. Beide moeten afzonderlijk worden gedocumenteerd. Zie de AI-governancegids voor de AI-laag.

Wat gebeurt er als het voorstel voor de Digital Omnibus wordt aangenomen? De regel inzake cookies/eindapparatuur wordt verplaatst van artikel 5, lid 3, van de ePrivacy-richtlijn naar een nieuw artikel 88a van de AVG voor abonnees die natuurlijke personen zijn, met zes genoemde doeleinden die zonder toestemming rechtmatig zijn. Een inventaris die is opgebouwd rond het doel (in plaats van rond cookienamen) kan naadloos worden overgezet. Het voorstel is nog niet aangenomen; houd u aan de huidige wetgeving.

Hoe vaak moet ik de inventaris bijwerken? Ten minste elk kwartaal, plus bij elke wijziging: een nieuwe SDK toegevoegd aan de site, een leverancier gewisseld (Cookiebot → OneTrust), een nieuwe functie die voorwaardelijke trackers introduceert, een update van de CMP-regel. De inventaris is een levend document; het auditlog van elke tracker is het bewijs dat u deze bijhoudt.

Begin met het documenteren van uw trackers

Cookie- en trackerinventarissen zijn niet erg glamoureus. Ze zijn ook het volgende aandachtspunt voor audits door toezichthouders, nu handhaving via banners alleen zijn grenzen bereikt. Het werk is voor een MKB-bedrijf echt goed te doen zodra u de structuur hebt: één tracker per rij, een categorie, een basis, een doel, een CMP-referentie en een duur.

Maak een gratis Readmodel®-account aan: haal de voorgevulde bibliotheek op en u beschikt binnen een uur over een controleerbare inventaris. De trackerpagina, de cookie-beleidsgenerator, de risicoregistermarkering voor ontbrekende toestemming en het verwerkingsregister zijn beschikbaar in elk abonnement, inclusief het gratis Explore-abonnement.