IAB TCF v2.4: Wat CMPs moeten wijzigen vóór oktober 2026

IAB TCF v2.4 heeft nu een bevestigd uitrolschema. IAB Europe is van plan de definitieve technische specificaties en de bijgewerkte Global Vendor List (GVL) op 23 juli 2026 te publiceren. CMPs hebben vervolgens tot 23 oktober 2026 voor webimplementaties en tot 23 februari 2027 voor mobiele apps en connected tv-omgevingen. Als uw consentstack deelneemt aan het TCF, is dit een implementatieproject — geen update waarbij alleen de tekst op de banner wordt aangepast.

De wijzigingen bevinden zich in TCF Policy v5.0.b en Technical Specifications v2.4. Ze hebben invloed op hoe CMPs Features uitleggen, de reikwijdte van een keuze bekendmaken, toestemming op meerdere apparaten ondersteunen en een specifiek geval van vendor-signalering coderen. Voor achtergrondinformatie over het huidige framework, zie Conzent's IAB TCF compliance-overzicht.

Belangrijkste punten

De bevestigde datums geven CMPs en uitgevers een korte maar haalbare volgorde: inspecteer het definitieve pakket in juli, rond de webwijzigingen af in oktober, en houd mobiel en CTV op een afzonderlijk februariplan. De belangrijkste punten zijn:

• 23 juli 2026: IAB Europe is van plan Technical Specifications v2.4 en de bijbehorende GVL-update te publiceren.
• 23 oktober 2026: CMPs moeten de nieuwe openbaarmakingen in webomgevingen implementeren.
• 23 februari 2027: de equivalente deadline geldt voor mobiele app- en CTV-omgevingen.
• CMP-interfaces hebben duidelijkere standaarduitleg en illustraties voor Features nodig.
• De initiële laag moet gebruikers informeren of een keuze service-specifiek, groep-specifiek of apparaatoverstijgend is.
• De technische preview verwijdert een verouderde legitiem-belang-omweg voor vendors die alleen Speciale Doeleinden aangeven; teams dienen de definitieve formulering op 23 juli te controleren.
• TCF-deelname ondersteunt compliancewerkzaamheden, maar vervangt niet de eigen juridische beoordeling van een uitgever of vendor.

De drie datums voor uw leveringsplan

De bevestiging van IAB Europe gedateerd 16 juli 2026 stelt drie afzonderlijke mijlpalen vast. Ze als één deadline behandelen zou discovery, implementatie, vertaling en QA in hetzelfde releasevenster samendrukken.

De praktische volgorde is:

1. 23 juli 2026 — publicatie van specificatie en GVL. Download de definitieve bestanden, vergelijk ze met het openbare-commentaarmateriaal en maak van elke bevestigde wijziging een concrete taak.
2. 23 oktober 2026 — webdeadline. Productie-web-CMPs moeten de nieuwe openbaarmakingen tonen en de definitieve v2.4-signaleringssvereisten naleven.
3. 23 februari 2027 — app- en CTV-deadline. Ingebouwde SDK's, doorlooptijden in de appstore, televisie-interfaces en apparaatspecifieke toegankelijkheidstests krijgen een latere datum, geen vrijstelling.

De periode tussen publicatie en de webdeadline bedraagt drie maanden. Dat is voldoende voor een gecontroleerde update als teams beginnen met een specificatievergelijking en een testmatrix. Het is krap als het werk begint met een late banner-herontwerp.

De bevestigde volgorde scheidt het bronmateriaal, de webimplementatie en de app/CTV-uitrol. Plan en test ze als drie mijlpalen in plaats van één lancering.

Wie moet handelen — en wie moet nog steeds opletten

De deadlines gelden voor live TCF-implementaties en de CMPs die daarvoor verantwoordelijk zijn. De officiële TCF-beleidsregels omvatten zowel commerciële CMPs die klanten bedienen als privé-CMPs die door een uitgever voor zijn eigen domeinen worden beheerd. Uitgevers blijven verantwoordelijk voor de framework-UI die op hun digitale kanalen wordt gepresenteerd, ook wanneer een derde partij de CMP levert.

U moet dit werk op een leveringsplan zetten als u:

• een geregistreerde TCF-CMP bouwt of beheert;
• een commerciële CMP gebruikt op een website die wordt gefinancierd door programmatische advertenties;
• een privé-uitgever-CMP onderhoudt;
• dezelfde toestemmingservaring levert via web, app en CTV;
• afhankelijk bent van TCF-signalen voor vendors, biedingen, meting of gepersonaliseerde advertenties.

Een website die niet deelneemt aan het TCF is niet automatisch verplicht TCF v2.4 te implementeren. Er kan nog steeds een geldig toestemmingsmechanisme vereist zijn op grond van toepasselijk recht of platformregels. De frameworkversie en de wettelijke plicht om toestemming te verkrijgen zijn gerelateerde vragen, maar niet dezelfde vraag.

Dit onderscheid is relevant voor Google-uitgeversproducten. Google vereist een gecertificeerde CMP die is geïntegreerd met het TCF voor gepersonaliseerde advertenties die via AdSense, Ad Manager of AdMob worden getoond aan gebruikers in de EER, het VK en Zwitserland. Google stelt ook dat zijn certificeringscontrole niet nagaat of volledig aan het TCF of het toepasselijke privacyrecht wordt voldaan.

Wat gebruikers anders zullen zien in een CMP

De meest zichtbare wijziging is een inspanning om Features duidelijker uit te leggen. Binnen het TCF beschrijft een Doel waarom gegevens worden verwerkt en geeft de gebruiker waar van toepassing een toestemmings- of bezwaarmogelijkheid. Een Feature beschrijft een verwerkingsmethode die wordt gebruikt in het kader van één of meer Doeleinden; zij draagt op dezelfde manier geen afzonderlijke gebruikerscontrole.

Onder Policy v5.0.b en de bevestigde GVL-update moeten CMPs rekening houden met:

• een nieuw standardTexts-veld met de standaarduitleg voor Features;
• illustraties voor elke Feature in de bijgewerkte GVL;
• de standaard Feature-uitleg weergegeven met de standaardnaam en volledige gebruiksvriendelijke tekst;
• Feature-informatie die visueel niet is gekoppeld aan bedieningselementen die de Feature niet daadwerkelijk kunnen uitschakelen;
• een nieuwe naam en richtlijnen voor Speciale Feature 2.

De bijgewerkte naam voor Speciale Feature 2 is "Apparaten identificeren op basis van actief opgevraagde informatie." De beleidsrichtlijn dekt expliciet kenmerken die worden verzameld via JavaScript of API's — zoals lettertypen, schermresolutie en plug-ins — en informatie die actief wordt opgevraagd via User-Agent Client Hints. Gebruikers moeten toestemming geven voordat een vendor deze Speciale Feature gebruikt.

Waarom dit meer is dan een tekstuele update

Een CMP die labels hard-codeert of uitgaat van de oude GVL-structuur kan falen, ook als de banner er nog normaal uitziet. Productteams moeten de nieuwe gegevens traceren van inlezen tot elke UI-laag, vertaling, toegankelijkheidslabel, gecached vendorrecord en regressietest. Het veilige ontwerpprincipe is eenvoudig: geef de officiële betekenis nauwkeurig weer, maak de aan- of afwezigheid van een gebruikerskeuze ondubbelzinnig duidelijk, en maak van een verklarende Feature geen nepschakelaar.

Toestemming op meerdere apparaten vereist een expliciete reikwijdte

Policy v5.0.b voegt een apparaatoverstijgende reikwijdte toe aan de definities van het framework. Een rechtsgrond kan van toepassing zijn op meerdere toegangspunten voor dezelfde dienst of groep — bijvoorbeeld een website en mobiele app die worden gebruikt door een geauthenticeerd account — wanneer de implementatie die reikwijdte ondersteunt. De initiële laag van de framework-UI moet de gebruiker meedelen of de toestemmingskeuze service-specifiek, groep-specifiek en/of apparaatoverstijgend is.

Dit gemak brengt een productverantwoordelijkheid met zich mee. Een CMP heeft een gedefinieerde manier nodig om een keuze die vóór inloggen op een apparaat is gemaakt, af te stemmen op voorkeuren die al op het account zijn opgeslagen. Het moet ook weigering en intrekking even bruikbaar houden als acceptatie binnen diezelfde reikwijdte.

De aanbeveling van de CNIL van januari 2026 over cross-device is Franse regelgevende richtlijnen en geen EU-brede TCF-regel, maar vormt een nuttige implementatiebenchmark. De CNIL beveelt aan dat:

• accepteren, weigeren en intrekken dezelfde apparaatoverstijgende reikwijdte hebben;
• gebruikers vóór hun keuze worden geïnformeerd dat de voorkeur van toepassing zal zijn op apparaten die zijn gekoppeld aan hun account;
• een korte herinnering wordt getoond wanneer de gebruiker inlogt op een nieuw apparaat;
• conflicten transparant worden afgehandeld, hetzij door de meest recente pre-loginkeuze of de accountvoorkeur prioriteit te geven.

Documenteer de gekozen conflictregel en test beide richtingen. Een technisch consistente voorkeursopslag kan toch een misleidende ervaring opleveren als gebruikers niet wordt verteld welke keuze prevaleert.

Wat er onder de motorkap verandert

Het technische pakket is gepland voor 23 juli, dus implementatieteams moeten het huidige materiaal gebruiken om zich voor te bereiden — niet om te doen alsof de definitieve vergelijking al is geverifieerd. De openbare-commentaarsamenvatting van IAB Tech Lab identificeert twee concrete technische aandachtsgebieden.

Ten eerste krijgt de GVL het standardTexts-object dat wordt gebruikt voor Feature-uitleg. Parsers, types, caches, API's en renderingcode moeten het nieuwe veld accepteren en bewaren. Een graceful fallback is nuttig voor operationele weerbaarheid, maar mag na de deadline niet stilzwijgend een vereiste openbaarmaking weglaten.

Ten tweede verwijdert de preview een omweg voor vendors die alleen Speciale Doeleinden aangeven. Omdat TCF v2.3 het disclosedVendors-segment verplicht heeft gesteld, kunnen die vendors via dat segment bepalen of ze zijn bekendgemaakt. De preview verwijdert daarom de verplichting om vendors met uitsluitend Speciale Doeleinden in het gedeelte Vendor Legitiem Belang van de TC-string te plaatsen.

Een voorzichtige implementatieregel

Bereid nu tests voor en koppel het productiegedrag aan de definitieve v2.4-tekst die op 23 juli wordt gepubliceerd. Vergelijk met name de definitieve TC-string-specificatie, het CMP API-materiaal, het GVL-schema, vertalingen en voorbeelden met de preview. Leg de versie vast die u heeft getest. "We volgden het artikel uit juni" is geen bruikbaar auditspoor wanneer een definitieve specificatie beschikbaar is.

Een zevenledige gereedheidslijst voor TCF v2.4

De deadline is gemakkelijker te beheren als elke vereiste een eigenaar en een observeerbare acceptatietest heeft. Begin met deze checklist en breid deze uit voor uw architectuur.

1. Inventariseer elk TCF-oppervlak. Maak een lijst van webdomeinen, ingesloten ervaringen, mobiele apps, CTV-apps, toestemmingsinstellingen, accountvoorkeurcentra, SDK's en gecachte GVL-consumenten. Markeer elk als web, app of CTV voor deadlineplanning.
2. Vergelijk de release van 23 juli. Vergelijk de definitieve specificatie, het GVL-schema, vertalingen, illustraties en beleidsverwijzingen met uw huidige v2.3-implementatie en de preview uit de openbare commentaarronde.
3. Update GVL-inlezen. Controleer of standardTexts, illustraties, de hernoemde Speciale Feature 2 en toekomstige onbekende velden parsing, opslag, API's en caching doorstaan.
4. Test de gebruikersinterface. Controleer of Feature-uitleg naast de juiste informatie verschijnt, er niet uitziet als bedieningselementen, leesbaar blijft bij zoomen en ondersteunende technologie, en werkt in alle ondersteunde talen. Bekijk de cookiebannerervaring als een volledig doorlopend proces in plaats van alleen de eerste laag.
5. Test signalering. Maak fixtures voor vendors met uitsluitend Speciale Doeleinden en verifieer de definitieve v2.4-coderings- en decoderingsregels voor de CMP, downstream-vendors en eventuele server-side toestemmingsverwerking.
6. Definieer apparaatoverstijgend gedrag. Documenteer reikwijdte, identiteitsvereisten, opslag, verspreiding, intrekking en de regel die wordt gebruikt wanneer apparaat- en accountkeuzes conflicteren. Test paden voor accepteren, weigeren, wijzigen, uitloggen, nieuw apparaat en accountverwijdering.
7. Uitrollen en observeren. Publiceer webwijzigingen vóór 23 oktober met monitoring op GVL-fouten, toestemmingsstring-fouten, ontbrekende openbaarmakingen en ongebruikelijke veranderingen in keuzepercentages. Houd app- en CTV-releases op een afzonderlijk beheerd plan voor 23 februari 2027.

Zelf hosten verwijdert deze verantwoordelijkheden niet. Als u OCI op uw eigen infrastructuur beheert, heeft u controle over het upgradevenster en kunt u de implementatie inspecteren, maar u bent ook verantwoordelijk voor de definitieve specificatiereview, implementatie en verificatie.

Wat uitgevers hun CMP-provider moeten vragen

Uitgevers hoeven niet zelf elke parserwijziging te implementeren, maar ze mogen "TCF-klaar" niet als volledig antwoord accepteren. Vraag om bewijs dat is gekoppeld aan uw daadwerkelijke omgevingen en datums.

Nuttige vragen zijn onder meer:

• Welke TCF Policy- en Technical Specification-versies worden momenteel in productie gebruikt?
• Wanneer is webondersteuning voor v2.4 algemeen beschikbaar, en welke actie is van de klant vereist?
• Hoe worden de nieuwe Feature-uitleg, illustraties en tekst van Speciale Feature 2 weergegeven en vertaald?
• Ondersteunt het product een apparaatoverstijgende reikwijdte, en hoe worden conflicterende keuzes precies opgelost?
• Welke web-, app- en CTV SDK-versies bevatten de wijzigingen?
• Welke geautomatiseerde en handmatige tests dekken het definitieve v2.4 TC-string-gedrag?
• Moeten gebruikers de framework-UI opnieuw zien, en wat is de bron voor die beslissing?

Vraag de provider om framework-compliance, Google-certificering en algemene privacywetondersteuning te scheiden. Ze overlappen, maar geen van beide is bewijs van de andere. Uw eigen verplichtingen als verwerkingsverantwoordelijke, uitgever en vendor hebben nog steeds een AVG-compliancebeoordeling nodig die past bij de verwerking die u uitvoert.

Wat TCF v2.4 niet betekent

TCF v2.4 is een update van een brancheframework, geen nieuwe wet en geen universele verplichting voor elke website. Het eigen beleid van IAB Europe omschrijft deelname als vrijwillig en stelt dat het framework geen vervanging is voor de verantwoordelijkheid van individuele deelnemers voor hun wettelijke verplichtingen.

Houd deze grenzen zichtbaar in interne en klantcommunicatie:

• het halen van de TCF-deadline maakt een toestemmingsstroom op zichzelf niet rechtmatig;
• Google CMP-certificering staat niet gelijk aan volledige TCF- of privacywetcompliance;
• een technisch geldige TC-string bewijst niet dat de gebruiker duidelijke informatie heeft ontvangen of een geldige keuze heeft gemaakt;
• apparaatoverstijgend gemak rechtvaardigt geen verborgen reikwijdte of eenzijdige verspreiding;
• een nieuw standaardlabel maakt een misleidende interface eromheen niet beter.

Raadpleeg juridisch adviseurs voor jurisdictiespecifieke conclusies. Gebruik de specificatie, het beleid en de regelgevende richtlijnen als afzonderlijke input voor productvereisten, in plaats van ze samen te voegen tot één vaag "compliance"-ticket.

Veelgestelde vragen

Wat betekent IAB TCF?

IAB TCF staat voor het IAB Europe Transparency and Consent Framework. Het standaardiseert hoe deelnemende uitgevers, CMPs en vendors gegevensverwerking bekendmaken, relevante keuzes vastleggen en toestemming-, bezwaar- en transparantiesignalen communiceren in het digitale advertentie-ecosysteem.

Wat is IAB TCF v2.3?

TCF v2.3 is de technische versie direct voor v2.4. Onder andere maakte het het disclosedVendors-segment verplicht. Dat is relevant voor v2.4 omdat de openbare-commentaardraft het verplichte segment gebruikt om de oudere legitiem-belang-omweg voor vendors met uitsluitend Speciale Doeleinden te verwijderen.

Wat is de TCF-lijst?

De term verwijst doorgaans naar de Global Vendor List, of GVL. IAB Europe onderhoudt deze voor geregistreerde TCF-vendors, en CMPs gebruiken de verklaringen, standaardteksten en gerelateerde gegevens om informatie te presenteren en frameworksignalen te produceren. De uitrol van v2.4 omvat een bijbehorende GVL-update gepland voor 23 juli 2026.

Moet elke CMP TCF v2.4 implementeren?

Nee. De deadlines betreffen CMPs en live installaties die deelnemen aan het IAB Europe TCF. Een niet-TCF-toestemmingstool kan nog steeds verplichtingen hebben op grond van privacywet of platformbeleid, maar die verplichtingen maken er niet automatisch een TCF-deelnemer van.

Wanneer is de TCF v2.4-deadline voor CMPs?

De bevestigde deadline is 23 oktober 2026 voor webomgevingen en 23 februari 2027 voor mobiele app- en CTV-omgevingen. De specificaties en bijbehorende GVL-update zijn gepland voor publicatie op 23 juli 2026.

Conclusie

TCF v2.4 is geen reden om elk toestemmingsproces opnieuw te ontwerpen. Het is een reden om de onderdelen te controleren waarop gebruikers en vendors vertrouwen: duidelijke Feature-uitleg, eerlijke reikwijdte, omkeerbare cross-device keuzes en nauwkeurige signalen. Begin met de bestanden van 23 juli, test web vóór 23 oktober, en houd mobiel en CTV op het plan voor februari 2027. Een gedocumenteerde, op bewijs gebaseerde uitrol zal een overhaaste banner-only update altijd overtreffen.