Nieuws & Blogs

Bouw je eigen AI-assistent of CLEA?

Mark Zijlstra — Thu, 12 Nov 2026 13:56:12 GMT

Bijna iedereen heeft wel eens een kast van IKEA in elkaar gezet. Inbussleutel, bouwtekening, een middag (wellicht wat frustratie) en aan het eind van de dag staat de kast in elkaar en op zijn plek. Hiervoor hoef je geen meubelmaker te zijn. Maar wil je een kast die precies in de schuine hoek onder je trap past of eentje die net een Andere maat heeft, dan heb je iets anders nodig. Dan moet je zorgen dat je de juiste gereedschappen hebt, de achterliggende techniek begrijpt en een paar mislukte pogingen doet om van te leren.

Dit is ook het verschil tussen de CLEA^®-opleiding en de ‘Bouw je eigen AI-assistent’-training. Twee trajecten, allebei hands-on en ze gaan allebei over zelf bouwen. Er zit echter een groot verschil tussen de insteek van deze opleidingen. En dat verschil is hetzelfde als bij een IKEA-kast en een maatkast.

Eén assistent die maandag werkt

Als privacy officer ben je misschien wel gewend dat er elke week een DPIA-aanvraag binnenkomt of een mogelijk datalek. Je gebruikt hiervoor een template dat zorgvuldig is opgesteld in combinatie met een vaste werkwijze en een stapel eerdere adviezen. Een generieke chatbot kent die specifieke documenten en processen allemaal niet. Daar is Bouw je eigen AI-assistent voor privacy & compliance voor gemaakt.

Vooraf doe je een korte e-learning van een à twee uur. Op de trainingsdag kies je je eigen use case (bijvoorbeeld een DPIA-assistent) en die ga je bouwen. Je voegt je eigen templates en werkwijze toe en leert hoe je moet testen en de output kunt verbeteren. Aan het einde van de dag loop je de deur uit met een werkende assistent. Binnen ICTRecht hebben we collega’s die elke dag bezig zijn met privacy en AI en als geen ander weten hoe je dergelijke processen verantwoord kunt laten ondersteunen. Het mooie is dat basiservaring met een tool als ChatGPT genoeg is, de rest leer je tijdens de dag zelf.

CLEA: de maatkast

De opleiding tot Certified Legal Engineer in AI (CLEA^®) begint op het punt waar ‘Bouw je eigen AI-assistent’ ophoudt. Wat als de assistent een document uit SharePoint moet ophalen? Of je wilt een ticketsysteem koppelen. Soms is een chatbot niet genoeg en moet je drie stappen achter elkaar kunnen automatiseren met een controlemoment ertussen. Dan ben je geen gespecialiseerde chatbot aan het maken maar een op maat gemaakte applicatie.

CLEA start eveneens met e-learnings en combineert dit met diverse online oefeningen. Daarna volgen drie praktijkdagen in Amsterdam. Je bouwt assistenten, skills en zet workflows op in n8n. Daarnaast ga je tools en kennis koppelen via MCP en leert de basis van GitHub, beveiliging en het uitrollen van een eigen app. Dat sluiten we af met het bouwen van een eigen applicatie met Claude Code of Codex.

De afsluiting is geen multiple choice toets. Je levert een bouwportfolio van acht onderdelen op, presenteert je werk en ontvangt daarna de beschermde titel CLEA^®. Programmeerervaring is ook hier niet nodig. Wel een juridische achtergrond en zin om drie dagen met je handen aan de knoppen te zitten. We gebruiken veel verschillende gereedschappen zodat je meerdere vaardigheden leert om praktijkproblemen op te lossen.

Kast of meubelmaker?

Heb je één terugkerende taak die je vandaag te veel tijd kost? Kies dan de dag. De meeste privacy professionals hoeven geen meubelmaker te worden. Zij willen dat de DPIA-intake van volgende week sneller gaat, met hun eigen template en hun eigen toon. Dat lukt in één dag.

Wil je AI-toepassingen bouwen die anderen in je organisatie gebruiken en die systemen aan elkaar knopen? Dan is CLEA de plek.

Twijfel je? Begin klein. Bouw je eigen AI-assistent is een prima eerste stap richting CLEA: je weet na één dag of bouwen je ligt en welk probleem je daarna wilt aanpakken.

Meer weten?

De eerstvolgende editie van Bouw je eigen AI-assistent is op 3 december 2026 in ons Academy Centre in Amsterdam, van 10.00 tot 16.15 uur. Je werkt in een kleine groep, dus schrijf je op tijd in. Liever met je hele team? De training is ook inhouse beschikbaar. Wil je meteen de volledige opleiding, bekijk dan de CLEA^®-opleiding of neem contact met ons op voor een kennismaking.

Europese norm voor AI-kwaliteitsbeheer prEN 18286: wat staat er eigenlijk in?

Micha Groeneveld — Tue, 10 Nov 2026 13:22:31 GMT

In eerdere blogs is besproken dat Europese normen gaan helpen om aan te tonen dat organisaties voldoen aan de verplichtingen uit de AI Act.

De eerste norm is inmiddels gepubliceerd: prEN 18286 - Quality management system for EU AI Act regulatory purposes.

Er is het nodige geschreven over deze norm, maar wat er nu feitelijk in staat is lang niet voor iedereen duidelijk. In dit blog lichten we een tip van de sluier op.

Het is belangrijk om te beseffen dat deze norm is geschreven voor aanbieders die hoog-risico AI ontwikkelen en op de markt brengen. Dergelijke aanbieders krijgen met deze norm een duidelijke, erkende route om de verplichtingen uit artikel 17 van de AI Act na te leven. Als zij hun kwaliteitsmanagementsysteem inrichten conform deze norm, profiteren zij van een wettelijk vermoeden dat wordt voldaan aan de eisen van artikel 17 van de AI-verordening.

Aanbieders kunnen artikel 17 nog steeds op andere manieren naleven, maar moeten dan zelf aantonen hoe zij dit doen

De norm heeft echter geen effect op de gebruiksverantwoordelijken. Partijen die hoog-risico AI bijvoorbeeld inzetten op gebieden zoals werving of kredietverlening, moeten zelf zorgen voor implementatie van de verplichtingen uit artikel 26 (gebruik in overeenstemming met de gebruiksaanwijzingen, menselijk toezicht, monitoring, het bijhouden van logboeken, het informeren van personeel en betrokkenen).

Totstandkoming

De norm is ontwikkeld door CEN-CENELEC JTC 21, het in 2021 door CEN en CENELEC opgerichte gezamenlijke Europese comité voor kunstmatige intelligentie. Dit comité ontwikkelt Europese AI-normen in opdracht van de Europese Commissie.

Bij besluit van 12 oktober 2026 (2026/2274) heeft de Commissie vastgesteld dat de norm voldoet aan de gestelde eisen en bruikbaar is als raamwerk voor het voldoen aan de eisen uit artikel 17 van de AI Act.

JTC 21 werkt ondertussen verder aan diverse andere normen voor hoog-risico AI, waaronder risicobeheer (artikel 9 AI Act), datagovernance en -kwaliteit (artikel 10), logging (artikel 12), transparantie (artikel 13), menselijk toezicht (artikel 14), nauwkeurigheid en robuustheid (artikel 15), cyberbeveiliging (artikel 15) en conformiteitsbeoordeling (artikel 43).

Inhoud van de norm

Artikel 17 van de AI Act verplicht aanbieders van hoogrisico-AI-systemen om een kwaliteitsbeheersysteem te implementeren. Dat systeem mag worden afgestemd op de omvang van de organisatie van de aanbieder (bijvoorbeeld een start-up, of een kleine midcaponderneming) en moet op systematische en ordelijke wijze worden gedocumenteerd in de vorm van schriftelijke beleidslijnen, procedures en instructies.

De norm geeft aan hoe dat systeem kan worden ingericht. Hoofdstukken (of volgens de Engelse versie: clausules) 1 tot en met 3 beschrijven met name voor wie de norm is bedoeld en hoe de begrippen in de norm moeten worden uitgelegd.

Hoofdstuk 4 beschrijft het kwaliteitsmanagementsysteem. De aanbieder moet identificeren welke wettelijke vereisten van toepassing zijn, welke AI-systemen onder het kwaliteitsmanagementsysteem vallen en moet een nalevingsstrategie formuleren en documenteren. Die strategie omvat ook de maatregelen die worden gebruikt om naleving aan te kunnen tonen, zoals gebruik van geharmoniseerde normen of andere standaarden. Hoofdstuk 4 geeft ook handreikingen over het vastleggen van deze informatie, het updaten en doorlopende controle.

Hoofdstuk 5 gaat over “Leiderschap”: het topmanagement stelt het kwaliteitsbeleid (en de kwaliteitsdoelstellingen) vast, zorgt voor de benodigde middelen en wijst rollen, verantwoordelijkheden en bevoegdheden toe.

Hoofdstuk 6 ziet op planning: bepalen welke doelen bijdragen aan het goed functioneren van het kwaliteitsmanagementsysteem (dus niet het risicobeheer van het AI-systeem zelf), risico’s identificeren en acties plannen om die risico’s te mitigeren en de effectiviteit van die acties evalueren.

Hoofdstuk 7 ziet op ondersteuning: bepaal welke middelen, competenties van medewerkers, communicatie (intern en externe partijen) en acties rondom bewustwording nodig zijn.

Hoofdstuk 8 gaat over “AI system realization”: er moeten processen en procedures worden opgesteld, gedocumenteerd, geïmplementeerd en onderhouden gedurende de gehele levenscyclus van het AI-systeem, gericht op naleving van wettelijke eisen en systeemvereisten. Daaronder valt ook het inrichten van een risicomanagement systeem, data management en product documentatie.

Hoofdstuk 9 regelt wat er moet gebeuren nadat het AI-systeem op de markt is gebracht of in gebruik is genomen: markttoelating, ondersteuningsdiensten, ketenbeheersing (toeleveranciers), wijzigingsbeheer, post-marktmonitoring, melding van ernstige incidenten en afhandeling van niet-naleving.

Hoofdstuk 10 is het laatste hoofdstuk. De norm vereist periodieke managementreviews, waarin de effectiviteit van het systeem wordt beoordeeld aan de hand van meetbare criteria. Ook de planning van wijzigingen aan het kwaliteitsmanagementsysteem zelf valt hieronder.

De norm bevat ook bijlagen met meer informatie over ondermeer de overlap met andere normen.

Toepassing in de praktijk

De AI Act schrijft voor dat het kwaliteitsbeheersysteem ten minste de volgende (kort samengevatte) aspecten moet bevatten:

Nalevingsstrategie, inclusief procedures voor conformiteitsbeoordeling en wijzigingsbeheer.
Methoden voor ontwerp, ontwerpcontrole en ontwerpverificatie.
Methoden voor ontwikkeling, kwaliteitscontrole en kwaliteitsborging.
Inspectie-, test- en validatieprocedures vóór, tijdens en na de ontwikkeling.
Toe te passen technische specificaties en normen, inclusief alternatieve middelen bij ontbrekende geharmoniseerde normen.
Databeheerprocessen, waaronder verwerving, opslag, analyse en alle overige dataoperaties.
Risicobeheersysteem conform artikel 9.
Monitoringsysteem na het in de handel brengen conform artikel 72.
Meldingsprocedures voor ernstige incidenten conform artikel 73.
Communicatie met bevoegde autoriteiten, aangemelde instanties en overige belanghebbenden.
Registratiesystemen voor relevante documentatie en informatie.
Beheer van hulpmiddelen en voorzieningszekerheid.
Verantwoordingskader met taakverdeling voor management en personeel.

Omdat de norm is ingericht als managementsysteemnorm (de zogenoemde "High Level Structure"), zijn deze eisen niet exact in deze volgorde terug te vinden in de norm.

De onder a) genoemde eisen inzake nalevingsstrategie en procedures voor conformiteitsbeoordeling staan bijvoorbeeld beschreven in 4.4 en wijzigingsbeheer wordt behandeld in 9.4 (de aanbieder beoordeelt of een wijziging een "substantiële wijziging" is, wat een nieuwe conformiteitsbeoordeling vereist).

De onder b) genoemde methoden voor ontwerp, ontwerpcontrole en ontwerpverificatie zijn terug te vinden in hoofdstuk 8.3.2: de aanbieder stelt AI-systeemeisen op (eisen uit regelgeving en aanvullende eisen die noodzakelijk zijn voor ontwerp en ontwikkeling), laat deze reviewen en vertaalt ze naar AI-systeemspecificaties. Zo moet duidelijk worden hoe ervoor is gezorgd dat het AI-systeem is ontworpen en geïmplementeerd conform de systeemeisen.

Andere onderwerpen zijn ook verspreid door de norm terug te vinden.

Conclusie

Het is dus geen kwestie van afvinken van de afzonderlijke specifieke verplichtingen, de norm vraagt om implementatie van een volledig managementsysteem. Onderstaand op hoofdlijnen de stappen die je daarvoor kunt nemen.

Stap 1: Bepaal de contouren van het kwaliteitsmanagementsysteem

Identificeer alle toepasselijke regelgevende vereisten (o.a. de AI Act), bepaal de reikwijdte van het kwaliteitsmanagementsysteem (welke AI-systemen vallen eronder) en formuleer een gedocumenteerde nalevingsstrategie (hoofdstuk 4).

Stap 2: Zorg voor betrokkenheid van het topmanagement

Het topmanagement stelt het kwaliteitsbeleid vast, draagt zorg voor voldoende middelen en wijst verantwoordelijkheden toe. Betrokkenheid van het topmanagement is een expliciete eis, geen formaliteit (hoofdstuk 5).

Stap 3: Zorg voor competente medewerkers en effectieve communicatie

Breng de benodigde competenties in kaart, zorg voor opleiding en stel communicatieprocedures vast voor zowel interne als externe partijen, waaronder bevoegde autoriteiten (hoofdstuk 7).

Stap 4: Implementeer en beheer het kwaliteitsmanagementsysteem

Formuleer meetbare kwaliteitsdoelstellingen en identificeer risico's voor het functioneren van het kwaliteitsmanagementsysteem zelf. Plan maatregelen om deze risico's te beheersen (hoofdstuk 6).

Richt de levenscyclusprocessen in, van bepalen van het beoogd gebruik, eisen aan ontwerp en ontwikkeling tot test en acceptatie (hoofdstuk 8), maar ook beheer na marktintroductie (hoofdstuk 9).

Stap 5: Richt het risicobeheersysteem in

Implementeer een risicobeheersysteem voor elk AI-systeem, gericht op bescherming van gezondheid, veiligheid en grondrechten gedurende de gehele levenscyclus (hoofdstuk 8.2) en implementeer procedures voor incidenten en niet-naleving (hoofdstukken 9.6 en 9.7).

Stap 6: Voer periodiek onderhoud uit

Betrek het topmanagement, voer managementreviews uit en documenteer de uitkomsten en aanbevelingen. Plan en voer wijzigingen door op een gecontroleerde wijze (hoofdstuk 10) en houd de documentatie actueel (waaronder de technische documentatie, het kwaliteitsbeleid, de procedures en de resultaten van reviews en audits, hoofdstuk 4.5 en 8.9).

Artikel 17 van de AI Act legt de nodige verplichtingen op, waarvan de uitvoering niet altijd even makkelijk is. Met deze norm in de hand hebben aanbieders in ieder geval een beter inzicht in wat van ze wordt gevraagd en hoe aan deze eisen kan worden voldaan.

Heb je vragen na het lezen van dit blog? Neem dan contact met ons op

Kopiëren, analyseren, doorgeven: waar stopt de TDM-exceptie?

Marco Caspers — Tue, 10 Nov 2026 08:27:59 GMT

In onze dagelijkse informatievoorziening is AI niet meer weg te denken. Of men nu wil of niet, iedereen gebruikt het direct of indirect: van de berichtgeving in je nieuws-app die met behulp van generatieve AI tot stand is gekomen, tot de slimme thermostaat die je huiskamer warm houdt op een zo efficiënt mogelijke manier.

Hoe AI leert en waarom dat auteursrechtelijk schuurt

De AI-modellen die hieraan ten grondslag liggen, komen niet uit de hemel vallen. Er is bestaande informatie nodig om modellen te trainen. Op basis van patronen die gevonden worden in die informatie, kan een model voorspellingen doen op nieuwe informatie. In het geval van taalmodellen, zoals ChatGPT, Claude, Gemini en Microsoft Copilot, wordt een woordenbrij voorspeld op basis van jouw prompt c.q. vraag; in het geval van bijvoorbeeld classificatiemodellen wordt een stuk tekst of afbeelding geclassificeerd op basis van vooraf bepaalde en getrainde classificaties. Denk bijvoorbeeld aan een filter dat op platforms als YouTube of Instagram automatisch herkent of een muziekfragment of afbeelding auteursrechtelijk beschermd materiaal bevat.

Voor het trainen van deze modellen worden computers, of eigenlijk hele krachtige servers, ingezet die alle informatie analyseren en (statistische) verbanden zoeken. En alles wat je met een computer doet gaat gepaard met een veelvoud kopieën van de brondata: denk aan opslag van data op hard disk of SSD, of tijdelijke opslag in RAM-geheugen of CPU cache. Dat laatste is met name relevant wanneer de modellen worden getraind op basis van auteursrechtelijke beschermde data, of ‘werken’ om in termen van de Auteurswet te spreken, zoals teksten, muziek of (bewegende) afbeeldingen. En omdat het maken van kopieën van een auteursrechtelijk beschermd werk onder het verbodsrecht van de maker of rechthebbende vallen, kan dit problematisch worden.

De TDM-exceptie: mogen computers ook lezen?

Dit probleem zag de Europese wetgever ook zo’n tien jaar geleden. Niemand had nog gehoord van generatieve AI, maar ‘big data’ en ‘tekst en data mining’ (TDM) waren een hot topic. TDM refereert daarbij met name aan de toen voorhanden technieken om in grote hoeveelheden ruwe data of tekst te zoeken naar patronen of relaties, of te analyseren op semantiek of sentiment. De toegankelijkheid tot grote hoeveelheden data en de ontwikkeling van geavanceerde machine learning-technologie maakte het genereren van nieuwe inzicht en kennis mogelijk. Eén van de struikelblokken was echter het auteursrecht: toegang tot de data betekende niet automatisch dat de data ook ‘gemijnd’ mocht worden.

Met o.a. het slogan ‘the right to read is the right to mine’ werd de roep om een auteursrechtelijke uitzondering voor TDM bij de wetgever steeds groter. Zodoende kwam de Europese wetgever met een richtlijn die, onder voorwaarden, verveelvoudigingen in het kader van tekst- en datamining uitzonderde van het verbodsrecht van auteursrechthebbende om het maken van verveelvoudigingen te verbieden. Heel platgeslagen betekent dit dat ook computers beschermde werken mogen lezen en daar inzichten, analyseren en patronen uit mogen halen, zoals mensen dat ook kunnen, zolang er maar rechtmatige toegang is tot de brondata. Net als voor mensen, geldt het dat het letterlijk oplepelen en hergebruiken en verspreiden van brondata niet zomaar mag. En nog een kleine kanttekening: TDM mag dat ook niet wanneer dat recht expliciet is voorbehouden, tenzij je onder de aparte uitzondering voor onderzoeksorganisaties of culturele instellingen valt.

Over de scope van de uitzondering is veel discussie geweest, zo ook in de rechtszaal. In andere EU-landen hebben we al verschillende uitspraken gezien van lagere en hogere rechters. Zo is ook in Nederland de TDM-uitzondering ingezet in een procedure tussen nieuwsuitgevers en HowardsHome.

Uitgevers vs. HowardsHome

HowardsHome bood sinds 2001 een digitale nieuwssignaleringsdienst aan zo’n zestig zakelijke klanten aan. Dagelijks verwerkten zij circa 30.000 berichten uit openbare RSS-feeds, elk met een hyperlink, de kop, een snippet van maximaal 150 tekens en waar beschikbaar een thumbnail. Zij had geen expliciete toestemming van uitgevers DPG, Mediahuis en NRC. Zij stelden dan ook dat HowardsHome daarmee inbreuk maakte op hun persuitgeversrecht, auteursrecht en databankenrecht. De zakelijke markt die HowardsHome bediende, exploiteren zij zelf via licenties van LexisNexis en ArtikelPro. De Rechtbank Amsterdam wees in 2024 alle vorderingen af. Opvallend was dat HowardsHome onder meer een geslaagd beroep deed op eerder genoemde TDM-exceptie.

Onlangs vernietigde het Gerechtshof Amsterdam dat vonnis en oordeelde dat HowardsHome inbreuk maakte op het auteursrecht en het persuitgeversrecht. Het hof wees het beroep op de TDM-exceptie af op twee gronden. De exceptie ziet alleen op verveelvoudigingen, dus het maken van (digitale) kopieën en niet op openbaarmakingen zoals publiceren op platforms of verspreiden via e-mails aan bijvoorbeeld klanten. Het selecteren en doorleveren van nieuwsberichten aan klanten is daarbij ook geen analysetechniek in de zin van art. 25a lid 3 Aw (de Nederlandse TDM-uitzondering).

Lezen, analyseren maar niet opnieuw oplepelen

De uitspraak bevestigt het eerder genoemde principe: je mag auteursrechtelijk beschermde teksten lezen en analyseren, maar letterlijk opnieuw oplepelen en verder verspreiden vereist toestemming van de rechthebbende (of een andere wettelijke uitzondering). De auteursrechtelijke uitzondering voor TDM maakt het stukje lezen en analyseren ook mogelijk voor computers onder bepaalde voorwaarden, maar houdt op waar het over verdere kopieën gaat en de verspreiding ervan. En juist dat laatste was onderwerp van discussie in de zaak tussen de uitgevers en Howardshome, en daarom is het niet vreemd dat een beroep op de TDM-exceptie faalde.

Ook het Hof van Justitie van de Europese Unie, de hoogste rechter voor de uitleg van EU-recht, buigt zich inmiddels over de reikwijdte van de TDM-exceptie. In een zaak tussen Like Company en Google (C-250/25) vroeg een Hongaarse rechter het Hof om uitleg van het EU-recht in een zaak over de chatbot Gemini. Like Company, een Hongaarse uitgever van nieuwswebsites, stelt dat Google haar artikelen zonder toestemming heeft gebruikt, zowel om Gemini te trainen als bij het opstellen van antwoorden in de chats, waarin de inhoud van die artikelen vervolgens terugkomt. Daarmee ligt onder meer de vraag voor of het trainen van een taalmodel onder de TDM-exceptie valt.

Het Hof heeft echter nog geen uitspraak gedaan: eerst brengt een Advocaat-Generaal, een onafhankelijke adviseur van het Hof, een gemotiveerd en niet-bindend advies uit, dat het Hof in de praktijk vaak (maar niet altijd) overneemt. Op 3 november 2026 deed Advocaat-Generaal Szpunar dat. In iets andere bewoordingen onderschreef hij het principe dat beschermde content wel gelezen en geanalyseerd mag worden, maar niet zonder toestemming letterlijk mag terugkomen in de stadia daarna. Hij achtte het daarbij ook relevant in hoeverre een model in staat was om makkelijk (delen van) content uit de training-data te reproduceren, zij het door intentionele werking of door nalatigheid in het ontwikkelproces. Hij is dan ook van mening dat van AI-ontwikkelaars verwacht mag worden dat zij passende waarborgen nemen om te voorkomen dat taalmodellen letterlijk beschermde content overnemen in hun output.

De finale uitspraak van het Hof hierin moet nog komen, maar de kaders van de TDM-uitzondering beginnen zich langzaam te kristalliseren. Het lijkt inmiddels wel duidelijk dat voor ontwikkelaars van AI, maar ook voor bedrijven en particulieren die AI gebruiken, je voorzichtig moet zijn met het overnemen en verder verspreiden of publiceren van AI-output.

Wil je meer weten over intellectueel eigendom en wat dit voor jou betekent?

BIO2 implementeren? Werk slimmer, niet harder

Mark Hoogewerf — Wed, 04 Nov 2026 11:27:06 GMT

De BIO2: extra werk of een kans om je ISMS te finetunen? Wie de overstap slim aanpakt, kiest voor het laatste.

Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet (Cbw). Voor overheidsorganisaties is de Baseline Informatiebeveiliging Overheid 2 (BIO2) daarmee het normenkader waarop je wordt aangesproken. Veel organisaties zitten nog midden in de overstap. Anderen moeten nog beginnen.

De BIO2 voelt al snel als extra werk. Maar de overstap is ook een mooi moment om kritisch naar je ISMS te kijken: wat werkt goed, wat kan scherper en wat kan weg? In dit blog lees je hoe je dat aanpakt. Hergebruik wat je hebt, integreer wat moet en beheer wat je hebt ingericht.

Je hoeft niet opnieuw te beginnen

Veel van wat je onder de vorige BIO hebt ingericht, blijft bruikbaar. Je beleid, je risicoanalyses en een groot deel van je maatregelen gooi je dus niet weg. Wat verandert er dan wel? De belangrijkste verschuivingen op een rij:

De BIO2 volgt de indeling van ISO 27002:2022. De 114 beheersmaatregelen uit de oude versie zijn teruggebracht tot 93, verdeeld over 4 thema's./p>
De vaste basisbeveiligingsniveaus (BBN's) verdwijnen. Je werkt voortaan risicogebaseerd.
ISO 27001 is het uitgangspunt voor je information security management system (ISMS). De BIO2 voegt daar specifieke overheidsmaatregelen aan toe.

Begin daarom met een gap-analyse. Welke maatregelen voldoen nog? Waar zit een gat? En welke documenten werk je bij? Daarna pak je gericht je documentatie, risicoanalyses en controls aan, met de grootste risico's eerst.

Dat uitzoekwerk kost tijd. Maar er zijn tools, zoals de AI Pro Pack, die daarbij kunnen helpen. Je legt de normvereisten naast je bestaande documentatie, ziet sneller waar de verschillen zitten en werkt teksten vlot bij. Het oordeel blijft bij jou, het zoekwerk wordt een stuk lichter./p>

Met een verschilanalyse heb je een goede start. Daarna lopen de meeste organisaties tegen twee vraagstukken aan. Hoe voorkom je dubbel werk met de andere normenkaders waaraan je al voldoet? En hoe houd je alles actueel als het project eenmaal is afgerond?

Eén control framework dekt meerdere normenkaders

De BIO2 staat niet op zichzelf. Hij bouwt voort op ISO 27001 en 27002, en de Cbw legt daar een zorgplicht en meldplicht bovenop. Verwerk je persoonsgegevens? Dan heb je ook met de AVG te maken. Veel van die eisen gaan over dezelfde onderwerpen: toegangsbeheer, incidenten, leveranciers en continuïteit.

Toch zien we in de praktijk vaak per normenkader een eigen systeem, een eigen eigenaar en een eigen administratie. Het securityteam werkt vanuit ISO 27001, de privacyofficer houdt de AVG bij en voor de Cbw komt er nog een lijst bij. Zo doe je hetzelfde werk twee of drie keer. En bij elke audit zoek je opnieuw naar hetzelfde bewijs.

Waarom zou je voor ieder normenkader afzonderlijke maatregelen, documentatie en controles beheren? Een wachtwoordbeleid blijft hetzelfde wachtwoordbeleid, of de BIO2, ISO 27001 of de Cbw er nu om vraagt. Dat geldt net zo goed voor je back-upprocedure, je incidentenproces en je afspraken met leveranciers.

Daarom werk je slimmer vanuit één uniform control framework. Je koppelt de vereisten uit alle normenkaders aan dezelfde set beheersmaatregelen. Zo ontstaat één geïntegreerde aanpak. Je richt een maatregel één keer in, legt het bewijs één keer vast en ziet direct aan welke eisen uit welk kader hij bijdraagt. Staat er een audit gepland? Dan pak je één dossier erbij, in plaats van drie.

Heeft een kader een specifieke eis die nergens anders terugkomt? Dan voeg je die als aanvullende maatregel toe. De basis blijft staan en je beheert meerdere verplichtingen vanuit dezelfde maatregelen en bewijsvoering. Komt er later een nieuw kader bij, zoals de AI-verordening? Dan breid je uit in plaats van opnieuw te beginnen.

Na de implementatie begint het onderhoud

Een ISMS is nooit af. Zo werkt de Plan-Do-Check-Act-cyclus nu eenmaal. Na de implementatie begint het eigenlijke werk: je ISMS actueel en aantoonbaar effectief houden. En juist dat blijkt in de praktijk lastig. Het project is afgerond, het team pakt ander werk op en de aandacht zakt langzaam weg.

Toch is dit het deel dat telt. Beleid dat je twee jaar niet hebt bekeken, sluit niet meer aan op je organisatie. Een maatregel op papier beschermt je pas als iemand toetst of hij ook werkt. En een verbeteractie zonder eigenaar blijft gewoon liggen. De Cbw maakt je bestuur bovendien verantwoordelijk voor het toezicht op cyberrisico's. Dan wil je kunnen laten zien dat je vandaag in control bent.

Goed onderhoud vraagt daarom om een vast ritme. Je plant reviews van je documentatie, toetst je maatregelen periodiek, legt verantwoordelijkheden vast en volgt verbeteracties op tot ze echt zijn afgerond. Zonder die structuur belandt het in losse Excel-bestanden, mailtjes en het hoofd van die ene collega. Tot de audit eraan komt.

Twee vraagstukken, één werkomgeving

Dubbel werk tussen normenkaders en het lastige onderhoud daarna: die twee vraagstukken zien we bij veel organisaties terug. Daarom hebben we de GRC Blueprint ontwikkeld.

De GRC Blueprint is één centrale werkomgeving in Atlassian. Daarin koppel je de eisen uit de BIO2, ISO 27001, de Cbw en andere kaders aan één control framework. Ook het onderhoud regel je daar: documentatie, risico's, beheersmaatregelen, verantwoordelijkheden, reviews en verbeteracties staan bij elkaar. Zo werkt iedereen vanuit dezelfde plek, op dezelfde manier.

Je start met templates en normkoppelingen die klaarstaan, afgestemd op de kaders die voor jou gelden. De basisinrichting staat binnen een dag. Daarna houden wij de normkoppelingen bij als wet- en regelgeving verandert. De eerste 3 maanden krijg je de AI Pro Pack er gratis bij.

Een bijkomend voordeel: de GRC Blueprint draait op Jira en Confluence. Die tooling is breder inzetbaar dan alleen voor compliance. Denk aan leveranciersmanagement, HR, softwareontwikkeling of strategische roadmaps. En in Confluence maak je interne kennis en documentatie voor iedereen toegankelijk. Zo investeer je niet alleen in aantoonbare compliance, maar in een werkomgeving die samenwerking en kennisdeling in je hele organisatie versterkt. Gebruikt jouw organisatie Jira en Confluence al? Dan bouw je voort op een omgeving die je collega's al kennen.

Hergebruik, integreer en beheer

De BIO2 is geen reden om een compleet nieuw ISMS op te tuigen. Hergebruik wat je al hebt. Koppel wat overlapt aan één framework. En beheer het geheel vanuit één plek. Dat scheelt werk, en bij de volgende audit leg je het bewijs zo op tafel.

Benieuwd waar jouw organisatie staat? Doe de BIO2-check of plan een vrijblijvend gesprek met een van onze compliance-experts via de pagina van de GRC Blueprint.

De EU KIDS ACT; is jouw dienst al veilig voor kinderen?

d.stam@ictrecht.nl (Dirk Stam) — Tue, 03 Nov 2026 10:10:04 GMT

Het internet is gevaarlijk voor minderjarigen: Cyberpesten, grooming, slaapproblemen, angst, depressie en eetstoornissen zijn een greep uit de gevolgen van online diensten. Slechts de helft van de kinderen tussen 9 en 16 jaar voelt zich online veilig. Het is allemaal de aanleiding geweest voor nieuwe regelgeving vanuit de EU; de EU Keeping Internet Digital Spaces Accountable and Trustworthy verordening (Hierna: ‘KIDS Act’). Deze Amerikaans klinkende verordening is bedoeld om minderjarigen te beschermen tegen de vele risico’s die het internet met zich meebrengt, zoals verslavende ontwerpen, contact met vreemden en ongepaste content.

Afgelopen september is de consultatieversie van de KIDS Act gepubliceerd. De reikwijdte van het voorstel is breed, de eisen zijn streng en de boetes kunnen oplopen tot maar liefst 6% van je wereldwijde jaaromzet.

Het gaat op dit moment nog ‘slechts’ om een consultatieversie. Deze sluit op 3 december. Nu is daarom het perfecte moment om jezelf alvast in te lezen in de KIDS Act zodat je niet wordt verrast door allerlei lastige verplichtingen als de definitieve versie wordt gepubliceerd. Ook is het nog mogelijk om te reageren op de tekst, waardoor je zelfs nog invloed kan uitoefenen op de definitieve inhoud. In dit blog worden daarom de belangrijkste bepalingen uitgelegd, zodat jij straks voorbereid bent.

Voor wie geldt de KIDS Act?

De KIDS Act bouwt voort op verplichtingen voor platforms uit de Digital Services Act, met name artikel 28. Dit artikel verplicht aanbieders van onlineplatforms al om een hoog niveau van privacy, veiligheid en bescherming voor minderjarigen te waarborgen. De KIDS Act werkt deze verplichting verder uit.

Binnen het toepassingsgebied van de KIDS Act kunnen zeven specifieke typen gereguleerde diensten onderscheiden worden:

Online sociale netwerk diensten
Video-platform diensten
App-stores
Online spellen
Besturingssystemen
AI-metgezellen
Algemene conversationele chatbots

De act maakt hierbij onderscheid tussen drie leeftijdscategorieën: minderjarigen jonger dan 13 jaar, minderjarigen tussen de 13 en 15 jaar, en minderjarigen van 15 tot 18 jaar.Voor jongere minderjarigen gelden strengere regels dan voor oudere.

Algemene uitganspunten

Voordat we inzoomen op de specifieke diensten, is het goed om te weten dat de KIDS Act een aantal algemene uitgangspunten hanteert. Zodra jouw dienst onder de act valt, krijg je te maken met drie uitgangspunten.

Allereerst moet op basis van de KIDS Act een gereguleerde dienst voorzien worden van een onafhankelijke EU-leeftijdsverificatie die de leeftijd van de gebruiker vaststelt voordat een account wordt aangemaakt. Deze leeftijdsverificatie moet nauwkeurig, betrouwbaar, veilig, robuust, niet-indringend en non-discriminatoir zijn en privacy- en gegevensbescherming bieden. Het enkel aanvinken van een vakje of invullen van de geboortedatum is niet meer voldoende. Leeftijdsverificatie moet voortaan gebaseerd zijn op identiteitsdocumenten of andere geverifieerde identificatiebronnen. Dit kan bijvoorbeeld met de aanstaande EU-wallet. Hoe dit precies werkt, verschilt per dienst. De Europese Commissie stelt een lijst op met erkende aanbieders van leeftijdsverificatie. Ook kan de Commissie richtlijnen opstellen om meer duidelijkheid te verschaffen waar leeftijdsverificatie aan moet voldoen.

Ten tweede moeten de aanbieders van de gereguleerde diensten hulpmiddelen voor voogden aanbieden. Hiermee kunnen voogden het gebruik van een dienst en de bijkomende functies beperken. Daarnaast moeten meldknoppen voor ongepaste inhoud of ongewenst contact zo worden ingericht dat ze voor minderjarigen daadwerkelijk begrijpelijk en toegankelijk zijn.

Als derde uitgangspunt moeten gereguleerde diensten zich houden aan de principes van ‘privacy by design’ en ‘safety by design’. Dit houdt in dat accounts van minderjarigen standaard ingesteld staan op de privacyvriendelijkste en veiligste instellingen. In deze versie van de KIDS Act betekent dit dat chatten met vreemden uitgeschakeld is, dat de geolocatie uitstaat en dat profielen op privé staan.

Dienstspecifieke regels

Aangezien een appstore iets heel anders doet dan een videospel of AI-chatbot, vult de KIDS Act de verplichtingen per type dienst specifiek aan. Hieronder een overzicht van de belangrijkste verplichtingen per dienst.

Onlinesocialenetwerkdiensten

De definitie van een onlinesocialenetwerkdienst kan worden samengevat als een platform dat eindgebruikers in staat stelt via meerdere apparaten in verbinding te treden en te communiceren met elkaar, inhoud te delen en inhoud te ontdekken. Hieronder vallen social media als Instagram, Snapchat en TikTok.

Voor onlinesocialenetwerkdiensten geldt onder de KIDS Act een minimum leeftijd. Minderjarigen jonger dan 13 jaar mogen van de act in de huidige vorm geen account meer aanmaken op social media.

Voor minderjarigen tussen de 13 en 15 jaar mogen op de meeste onlinesocialenetwerkdiensten alleen ouders en voogden een account aanmaken. Dit kan anders zijn als de social media geen risico’s vormt voor het kind. Onlinesocialenetwerkdiensten vormen volgens de KIDS Act geen risico’s voor minderjarigen indien het geen één van de volgende functies heeft:

Live streaming
Communicatie met derden
Aanbevelingssysteem gebaseerd op profilering
Vriend suggesties
Mogelijk maken van ononderbroken consumptie van inhoud
Interacties met de dienst stimuleren
Geautomatiseerde meldingen die ertoe aanzetten de dienst (opnieuw) te gebruiken

De aangemaakte accounts voor minderjarigen tussen de 13 en 15 jaar moeten daarnaast voorzien zijn van hulpmiddelen voor voogden. Dit zijn de volgende hulpmiddelen:

Beperken van de schermtijd
Nieuwe contacten moeten vooraf door de voogd goedgekeurd worden
Controleren van de privacyinstellingen zoals de geolocatie, camera, microfoon, contactsynchronisatie en pushmeldingen

‘Privacy by design’ en ‘safety by design’ betekent voor social media bijvoorbeeld een niet profilerende feed, geen oneindig scrollen of autoplay en het standaard uit staan van geolocatie, camera, microfoon, contactsynchronisatie en pushmeldingen. Deze functies mogen enkel aangezet worden door de voogd via de daarvoor bedoelde hulpmiddelen.

Voor minderjarigen tussen de 15 en 18 jaar is het wel mogelijk om zelf een account aan te maken, maar ook hier geldt dat privacy- en safety by design de uitgangspunten zijn. Het moet de keuze van de minderjarige zelf zijn om hier van af te wijken.

Videoplatformdiensten

Een videoplatformdienst is een dienst waarvan het hoofddoel bestaat uit het aanbieden van programma’s en/of door gebruikers gegenereerde video’s waarvoor het platform geen redactionele verantwoordelijkheid draagt aan het algemene publiek. Hieronder vallen diensten als YouTube, Twitch of Kik.

Ook voor videoplatformdiensten is het niet toegestaan een account aan te maken als je jonger bent dan 13 jaar. Minderjarigen in deze leeftijdsgroep kunnen wel gebruikmaken van videoplatformdiensten die speciaal voor minderjarigen zijn ontworpen, maar alleen via het account van een ouder of voogd. Deze mogelijkheid moet expliciet opgenomen zijn in de algemene voorwaarden inclusief vanaf welke leeftijd het platform toegankelijk is. Ook moet een beoordeling gemaakt en gepubliceerd worden waarin de risico’s voor minderjarigen zijn beoordeeld en hoe deze worden beperkt.

Minderjarigen jonger dan 13 jaar kunnen dan maximaal 1 uur per dag gebruik maken van de videoplatformdienst. Hierbij moeten wel alle personalisatiefuncties, aanbevelingssystemen en zoekfunctionaliteiten standaard uitgeschakeld zijn. Deze mogen alleen aangezet worden als uit de hiervoor genoemde beoordeling blijkt dat het in het belang van de minderjarige is en het geen enkele negatieve gevolgen voor de privacy, veiligheid en beveiliging van de minderjarige heeft.

Ook hier geldt; privacy- en safety by design zijn de uitgangspunten, dus onder andere geen oneindig scrollen, geen streakbeloningen en geen algoritmische aanbevelingssystemen.

Appstores

Een appstore is een onlinetussenhandelsdienst die gericht is op het verstrekken van softwareapplicaties als product of dienst. Denk hierbij aan de Google Play Store, de Apple Appstore of Steam.

Appstores krijgen onder de KIDS Act een poortwachtersrol. Ze moeten van de KIDS Act een leeftijdsclassificatiesysteem invoeren; apps worden ingedeeld in een systeem waaruit blijkt voor welke leeftijd ze geschikt zijn. Appstores moeten ervoor zorgen dat minderjarigen geen apps te zien krijgen die niet geschikt zijn voor ze. Dit geldt ook voor apps waar een wettelijke leeftijdslimiet voor geldt, zoals gok-, drank- of beleggingsapps.

Besturingssystemen

Een besturingssysteem is software die de basisfuncties van hardware of software regelt. Denk hierbij aan Microsoft, Android of iOS. Ook besturingssystemen krijgen een poortwachtersrol onder de KIDS Act. Besturingssystemen moeten standaard een veilige en privacyvriendelijke basisomgeving bieden voor accounts van minderjarigen. Daarnaast moeten ze op apparaatniveau interoperabiliteit faciliteren voor leeftijdsverificatie apps.

Online spellen

Onlinespellen worden in de KIDS Act onderverdeeld in twee subcategorieën: videospellen en videospelplatforms. De definitie van een videospel is onder de KIDS Act erg breed en samen te vatten als elke elektronische gesimuleerde omgeving voor spel- of amusementsdoeleinden. Hieronder vallen spellen als Call of Duty, Fortnite en Candy Crush. Bij videospelplatform kan je denken aan diensten als Roblox en Minecraft, waar mensen zelf een omgeving kunnen maken om spellen te spelen en anderen deze kunnen spelen.

Safety- en privacy by design houdt bij onlinespellen onder andere in dat chatten met vreemden standaard uit staat, er geen dagelijkse beloningen beschikbaar zijn, zodat overmatig gebruik niet gestimuleerd wordt, en dat minderjarigen niet naar een onveilige omgeving worden gelokt.

AI-chatbots en -metgezellen

Tot slot richt de KIDS Act zich op een categorie die vier jaar geleden nog nauwelijks bestond, maar inmiddels niet meer weg te denken is uit de leefwereld van veel minderjarigen (en volwassenen); AI-chatbots en -metgezellen. De risico's hiervan voor minderjarigen zijn nog grotendeels onbekend, maar de EU wacht niet af.

Een AI-chatbot kan omschreven worden als een AI-systeem voor algemene doeleinden met algemene conversationele functionaliteiten voor rechtstreekse interactie met gebruikers. Voorbeelden hiervan zijn ChatGPT, Claude en Grok. Een AI-metgezel is een chatbot die voorziet in duurzame, gepersonaliseerde interactie of gezelschap, waarbij een sociale, emotionele of interpersoonlijke relatie met een gebruiker wordt gesimuleerd of vergemakkelijkt. Denk hierbij aan Replika, Character.ai of Snapchats MyAI.

Voor minderjarigen jonger dan 13 jaar is toegang tot AI-systemen uitsluitend toegestaan onder direct beheer van de voogd. Daarnaast moeten minderjarigen vanaf 13 jaar beschermd worden tegen emotionele afhankelijkheid van de chatbot. Ook mogen geen gegevens uit eerdere gesprekken gebruikt worden en moet de chatbot standaard uitstaan indien deze is geïntegreerd in social media of een spel.

Aanbieders van een AI-chatbot of-metgezel moeten een risico-assessment uitvoeren waarin de impact van het AI-systeem op de mentale gezondheid en ontwikkeling van minderjarigen in kaart wordt gebracht. Deze moet uitgevoerd worden voordat de chatbot in de handel wordt gebracht.

Wat kan je nu doen?

Hoewel de inwerkingtreding van de KIDS Act nog ver weg klinkt, kan je wel al de eerste stappen nemen. Degene die dit soort verplichtingen enkel zien als een verplicht nummertje, lopen het risico te laat te zijn om te voldoen. Wie nu al actie onderneemt, voorkomt kostbare herontwerpen op het laatste moment en bouwt aan vertrouwen bij ouders en gebruikers.

Een goed begin is om in kaart te brengen welke functionaliteiten in jouw dienst onder de KIDS Act vallen. Bepaal vervolgens welke veranderingen doorgevoerd moeten worden om deze diensten compliant te krijgen. Pas daarna je softwareontwikkelproces aan, zodat alle toekomstige aanpassingen en nieuwe diensten vanaf het begin aan de verplichtingen voldoen. Controleer periodiek of je diensten nog steeds aan de eisen voldoen. Onderzoek daarnaast hoe jouw platform in de toekomst kan aansluiten op de erkende EU-systemen voor leeftijdsattestering. Implementatie hiervan kost namelijk veel tijd en moeite, dus als je wacht tot het laatste moment heb je kans dat de implementatie te laat is. Zorg tot slot voor bewustwording binnen de organisatie. Dit maakt dat je afwijkingen tijdig signaleert, sneller kunt handelen en daarmee de kans en impact van fouten verkleint.

Tot slot

De consultatieversie van de KIDS Act laat er geen twijfel over bestaan: de Europese Unie geeft er prioriteit aan om de digitale wereld van minderjarigen veiliger te maken. Voor aanbieders van digitale diensten betekent dit dat 'kindveiligheid' niet langer een vrijblijvende optie is, maar een kernonderdeel van de architectuur.

Heb je vragen over wat de KIDS Act specifiek betekent voor jouw app, platform of game? Of wil je ondersteuning bij het uitvoeren van een impact-assessment? Wij denken graag met je mee!

Het compliance-wiel: Kwadrant 2, Beleid & Procedures

Tim Langelaar — Thu, 29 Oct 2026 14:04:58 GMT

De spaken van het wiel

Van governance naar werkbare controls

In het vorige blog zetten we de as van het wiel vast: Visie & Governance. We stelden de ongemakkelijke vraag over wie welke risico's mag beslissen, werkten de vier bouwstenen uit en zagen hoe de AFM bevestigt dat een goed beschreven compliancefunctie nog geen effectieve is.

Nu is het tijd voor de spaken. Kwadrant 2: Beleid & Procedures. Dit is het kwadrant waar de wettelijke werkelijkheid van buiten wordt omgezet naar de operationele werkelijkheid van binnen. Zonder stevige spaken behoudt het wiel niet zijn vorm.

Hoe het misgaat

Je beleid telt veertig documenten waarvan niemand meer weet welk het actuele is. Je risicoregister staat in een spreadsheet die voor het laatst werd bijgewerkt toen die ene collega nog in dienst was. En je hebt voor de AVG een risicoanalyse gemaakt, voor NIS2 een andere, en voor ISO 27001 nog een derde, met deels tegenstrijdige uitkomsten en driedubbel onderhoud. En voor de ontwikkelingen rondom AI wordt er een geheel nieuwe schaduworganisatie opgezet.

Het gevolg: compliance wordt een last in plaats van een instrument. En als een klant, aanbesteder of toezichthouder vraagt om bewijs, niet om beschrijvingen, maar om bewijs, dan begint de zoektocht opnieuw.

De oplossing zit niet in meer beleid. Het zit in betere structuur.

Drie stappen naar werkbare controls

Stap 1: Weet wat er op je afkomt

De Digital Decade-wetgeving is geen losse stapel wetten. Het is een stelsel dat bewust op elkaar is afgestemd. Denk in drie lagen:

Algemeen van toepassing: AVG, Cyberbeveiligingswet/NIS2, AI Act, Data Act, CRA.

Sectorspecifiek: NEN 7510 (zorg), BIO (overheid), DORA (financiële sector), MDR (medische hulpmiddelen). Wie AI inzet als medisch hulpmiddel heeft te maken met zowel de AI Act als de MDR, twee overlappende kaders met elk hun eigen conformiteitseisen.

Keten-gedreven: CSRD, CSDDD, Cbw en DORA verplichten grote organisaties hun leveranciersketen door te lichten. Zit je in die keten? Dan worden jouw compliance-prestaties onderdeel van de verantwoordingsplicht van je klant.

Maak dit overzicht niet eenmalig. Bouw een regulatory radar in: een structureel proces waarbij nieuwe wetgeving en wijzigingen worden gesignaleerd en direct gemapt naar je bestaande raamwerk.

Stap 2: Van eis naar risico: de gemeenschappelijke taal

De sleutel zit in de tussenstap: risico's. Elke wettelijke eis beantwoordt impliciet de vraag: wat kan er misgaan als we dit niet doen? Door eerst naar risico's te vertalen, creëer je de gemeenschappelijke taal die een many-to-many structuur mogelijk maakt.

AVG art. 32, NIS2 art. 21 en ISO 27001 A.9 verwijzen alle drie naar hetzelfde onderliggende risico: ongeautoriseerde toegang tot gevoelige gegevens. Eenmalig identificeren, wegen en beheren, en je dekt alle drie de eisen tegelijk af.

Stap 3: Van risico naar maatregel: de many-to-many structuur

De vraag bij elke maatregel is: welke andere risico's dekt deze control ook af? En welke (combinatie van) maatregel(en) is het best passend?

Een goed ingericht RBAC-systeem dekt tegelijkertijd: AVG art. 32, NIS2/Cbw art. 21, ISO 27001 A.9, AI Act art. 9 én je eigen datalekrisico. Dit levert drie concrete voordelen op: impactanalyse bij een falende control, snelle gap-analyse bij nieuwe wetgeving en efficiënt uitbreiden zonder opnieuw te beginnen.

Beleidsinflatie: de stille killer

Goed beleid heeft een eigenaar, een versiedatum, een reviewcyclus en een directe koppeling aan de risico's en controls die het beschrijft. Goede procedures beschrijven niet alleen wát iemand moet doen, maar ook waarom en hoe het bewijs eruit ziet. Bouw bewijsvoering direct in, zodat bewijs ontstaat tijdens het werk, niet een paar weken voor de audit.

Soevereiniteit in dit kwadrant

Welk beleid stel je op voor dataopslag buiten de EU? Hoe documenteer je de Transfer Impact Assessment (TIA) als structureel onderdeel van je verwerkingsregister? De Data Act geeft nieuwe instrumenten: overstaprechten, toegangsrechten en verboden op data-lock-in. Wie dit beleid op orde heeft, maakt soevereiniteit aantoonbaar en bereidt zich voor op de Cloud and AI Development Act (CADA).

AI als versneller, en als risicobron

AI kan de regulatory radar automatiseren. Het kan snel complexe verbanden leggen, documenten analyseren en repetitieve taken consequent uitvoeren. Zo kan het ook beleid logisch aan elkaar koppelen, overlap signaleren en waar nodig versimpelen. Maar AI introduceert ook nieuwe risico's: garbage in, garbage out. Behandel AI-output als het concept van een junior, laat het altijd valideren en leg vast wie dat heeft gedaan. Bovendien is een AI-toepassing zelf een compliance-object: de AI Act (art. 9) vereist een risicobeheersysteem over de hele levenscyclus van hoog-risico AI-systemen.

Van 'we doen het' naar 'we kunnen het bewijzen'

Aantoonbaarheid is geen bijproduct meer. Het is de norm. Klanten die zelf aan CSRD, NIS2 of DORA moeten voldoen, zijn verplicht hun leveranciersketen door te lichten. Een klant vraagt niet meer of je beleid hebt, hij vraagt om bewijs.

Hier sluit ComplianceProof op aan: een onafhankelijke, juridisch onderbouwde verklaring over een specifieke compliance-vraag, of het nu gaat om AVG-naleving, AI-geletterdheid of de hoog-risico status van een AI-systeem. Geen allesomvattend certificeringstraject, maar gerichte zekerheid op precies het punt waar jouw klant of toezichthouder zekerheid over vraagt. Een organisatie die haar beleid en controls op orde heeft, doorloopt zo'n toets sneller en met minder frictie. Het bewijs is er al.

Wettelijke ankers in dit kwadrant

De AVG vereist een register van verwerkingsactiviteiten en aantoonbare passende maatregelen; de AI Act verplicht technische documentatie en een risicobeheersysteem voor hoog-risico toepassingen; de Cyberbeveiligingswet eist gedocumenteerde beveiligingsmaatregelen; DORA vereist een ICT-risicokader met aantoonbare controls.

Wat je deze week kunt doen

Tel de koppelingen. Zet je registers naast elkaar, verwerkingen, risico's, AI-systemen, leveranciers, en vraag per register: wie is eigenaar, wanneer is hij voor het laatste bijgewerkt, en is hij gekoppeld aan een ander register? Dat "nee" is je nulmeting.

Doe één mapping. Neem één nieuwe eis en map die op je bestaande risico's en controls. Meet hoe lang het duurt.

Stel de beleidsinventarisatie ter discussie. Hoeveel beleidsdocumenten heeft jouw organisatie? Wie is eigenaar van elk?

In het volgende blog

De spaken zitten in het wiel. In blog 4 stoppen we bij de naaf: People, Process & Technology, waarom verandermanagement dé onderschatte factor is in elk compliance-programma. En in blog 5 zoomen we in op het derde kwadrant: Cultuur, want de sterkste control is uiteindelijk een medewerker die op het juiste moment de juiste keuze maakt.

Wil je weten hoe goed jouw beleid en risicoregisters aan elkaar hangen? Wij helpen je graag met een praktische gap-analyse.

Mag je een klant mailen over zijn verlaten winkelwagen? Dit zijn de spelregels.

Anthony Tang — Thu, 29 Oct 2026 14:00:23 GMT

Dit artikel is gepubliceerd in samenwerking met Thuiswinkel.org

Iemand bezoekt je webshop, legt een product in de winkelwagen, vult zijn e-mailadres in en haakt vervolgens af. Geen aankoop, geen bericht, gewoon weg. Dit overkomt veel online webshops: afhankelijk van de branche wordt tussen de 65% en 80% van alle winkelwagens verlaten zonder dat er een bestelling wordt afgerond.[1]

De gedachte om die potentiële klant een vriendelijke herinnering te sturen is dan ook begrijpelijk, en verleidelijk. Maar let op: een verlaten-winkelwagen-mail sturen is niet zomaar toegestaan. Wie de regels niet kent, loopt een serieus juridisch risico.

Een verlaten-winkelwagen-mail is gewoon direct marketing

Een e-mail die iemand aanspoort om een aankoop alsnog af te ronden, valt juridisch gezien onder direct marketing. Dat geldt ongeacht hoe vriendelijk of behulpzaam de toon van de mail is. Bepalend is de commerciële bedoeling van de verzender, niet de vorm.

Voor direct marketing via e-mail geldt op grond van de Telecommunicatiewet (artikel 11.7) een helder principe: je hebt voorafgaande toestemming nodig van de ontvanger. Dat is de opt-in-vereiste. Heb je die toestemming niet? Dan mag je simpelweg niet mailen, tenzij je een beroep kunt doen op de klantrelatie-uitzondering.

De klantrelatie-uitzondering: minder ruim dan je denkt

De klantrelatie-uitzondering geldt uitsluitend als er daadwerkelijk een eerdere aankooptransactie heeft plaatsgevonden én de e-mail betrekking heeft op eigen gelijksoortige producten of diensten. Bij een verlaten winkelwagen is geen koopovereenkomst tot stand gekomen. Er bestaat dan geen klantrelatie waarop een beroep kan worden gedaan.

Zelfs als er al een klantrelatie bestaat, gelden aanvullende voorwaarden op grond van de Telecommunicatiewet:

De klant moet duidelijk en eenvoudig de mogelijkheid hebben gekregen om kosteloos bezwaar te maken tegen het ontvangen van dergelijke e-mails.

Die mogelijkheid moet worden geboden op het moment dat het e-mailadres wordt verzameld én in elke daaropvolgende e-mail.

Wordt niet aan deze voorwaarden voldaan, dan geldt ook hier de hoofdregel: zonder toestemming, geen mail.

Wat zegt de toezichthouder?

Dit is geen theoretisch risico. De privacytoezichthouder van de Duitse deelstaat Hessen ontving in 2024 meerdere klachten van consumenten die zonder toestemming een herinnering kregen over hun verlaten winkelwagen. In alle onderzochte gevallen volgde een officiële waarschuwing op grond van de AVG. Verdere sancties bleven achterwege omdat de betrokken webshops snel handelden: ze pasten hun systemen aan en verwijderden de onrechtmatig verzamelde persoonsgegevens.[2]

Voor Nederlandse webshops is dit een duidelijk signaal. In Nederland houdt de ACM toezicht op de spamregels uit de Telecommunicatiewet en de Autoriteit Persoonsgegevens op de naleving van de AVG. Beide kunnen handhavend optreden, inclusief het opleggen van boetes.

Hoe doe je het wél goed?

Goed nieuws: verlaten-winkelwagen-mails zijn prima in te zetten, zolang je de basis op orde hebt. Geldige toestemming moet vrij, specifiek, geïnformeerd en ondubbelzinnig zijn. In de praktijk vertaalt dat zich naar vier concrete stappen.

1. Voeg een apart opt-in-vakje toe

Vraag actief toestemming, bijvoorbeeld bij het aanmaken van een account of aan het begin van het bestelproces. Gebruik hiervoor een apart, niet vooraf aangevinkt vakje, los van de algemene voorwaarden of andere toestemmingen. Combineer dit vakje nooit met andere opt-ins, want dan voldoet de toestemming niet aan de eis van specificiteit.

Voorbeeld: "Ja, ik wil een herinnering ontvangen als ik mijn bestelling niet heb afgerond."

Twijfel je of je aan alle voorwaarden van de uitzondering voldoet? Vraag dan voor de zekerheid toch toestemming. Dat voorkomt discussie achteraf over de vraag of aan alle voorwaarden van de uitzondering is voldaan.

2. Vermeld het gebruik in je privacyverklaring

Leg in je privacyverklaring expliciet uit dat het e-mailadres ook wordt gebruikt voor verlaten-winkelwagen-mails, op welke juridische grondslag dit gebeurt en hoe lang de gegevens worden bewaard. Dit is een verplichting vanuit de AVG, maar het vergroot ook het vertrouwen van je klanten. Transparantie werkt.

3. Registreer de toestemming aantoonbaar

Zorg dat je kunt laten zien wie wanneer toestemming heeft gegeven, en waarvoor. Dit is nodig om te voldoen aan de verantwoordingsplicht onder de AVG. Bewaar deze registratie zorgvuldig, want bij een eventuele klacht of controle is dit je voornaamste bewijs.

4. Stuur alleen aan wie toestemming heeft gegeven

Richt je systemen zo in dat verlaten-winkelwagen-mails uitsluitend worden verstuurd aan contacten met een vastgelegde opt-in. Dit is een technische stap, maar een essentiële. Een toestemmingsvakje op je website heeft weinig waarde als je e-mailsysteem er geen rekening mee houdt. Geef ontvangers daarnaast in elke mail een eenvoudige en kosteloze afmeldmogelijkheid en verwerk afmeldingen direct: toestemming intrekken moet net zo makkelijk zijn als toestemming geven.

Dit geldt ook buiten de verlaten-winkelwagen-mails

De regels zijn niet beperkt tot winkelwagens. Dezelfde logica geldt voor elk onvoltooid formulier waarbij een e-mailadres is achtergelaten. Wil je iemand via e-mail bewegen om alsnog een actie af te ronden, dan gelden dezelfde spelregels. Denk bijvoorbeeld aan:

Begonnen maar niet verstuurde offerteaanvragen
Inschrijfformulieren voor evenementen die niet zijn voltooid
Donatieformulieren waarbij het proces halverwege is afgebroken
Productconfiguraties of proefaanvragen (o.a. proefabonnementen of proefpakketten)

In al deze gevallen geldt: geen voltooide handeling betekent geen klantrelatie, en geen klantrelatie betekent geen direct marketing mail zonder voorafgaande toestemming.

Kortom

Een verlaten-winkelwagen-mail is een effectief instrument, maar alleen als de basis op orde is. Het invullen van een e-mailadres is géén toestemming. Zorg voor een actieve opt-in, leg die toestemming aantoonbaar vast, beschrijf het in je privacyverklaring en richt je systemen er technisch op in. Wie dat doet, kan verlaten-winkelwagen-mail inzetten op een manier die zowel commercieel effectief als juridisch verantwoord is.

Wil je weten of jouw huidige aanpak voldoet? Wij helpen je verder met een praktische compliance-check, juridisch advies of kant-en-klare documentatie. Neem contact op.

[1] https://baymard.com/lists/cart-abandonment-rate

[2]https://datenschutzarchiv.org/detailansicht/Dokumente/2024/TB_Hessen_LfD_53_2024_de.pdf?page=154&cat=57

De UZI-pas verdwijnt: wat betekent Dezi voor zorgorganisaties?

Ilona Kuipers — Tue, 27 Oct 2026 15:58:46 GMT

De zorg digitaliseert in een snel tempo, maar de beveiliging van de digitale toegang tot patiëntgegevens blijft daarin achter. Van de 1,5 miljoen mensen die werkzaam zijn in de zorg, beschikken er slechts 90.000 over een goedgekeurd inlogmiddel [1]. Een verklaring hiervoor zou kunnen zijn dat de UZI-pas hoge drempels opwerpt: de pas vereist speciale hardware, is duur in aanschaf en is primair bedoeld voor BIG-geregistreerde zorgverleners. Vanwege het gebrek aan een beter alternatief werkt de rest met inlogmiddelen die niet voldoen aan het vereiste betrouwbaarheidsniveau.

Met de invoering van de Wet Digitale Identificatie en Authenticatie in de Zorg (DIAZ) probeert de wetgever dit toegangsprobleem structureel op te lossen. Het wetsvoorstel is op 6 oktober 2026 aangenomen door de Tweede Kamer en op 27 oktober door de Eerste Kamer [2]. In dit blog leggen we uit wat er nu precies verandert, voor wie en wanneer.

Het probleem van een fysieke pas in een digitale wereld

De standaard voor veilige digitale toegang in de zorg is nu de Unieke Zorgverlener Identificatie (UZI) pas: een fysieke pas met kaartlezer en PIN-code [3]. In theorie veilig. In de praktijk een systeem vol knelpunten.

Om te beginnen werkt de pas alleen in combinatie met een fysieke kaartlezer en is de pas niet geschikt voor gebruik op smartphones of tablets. Dat is onwerkbaar in een sector waar zorgverleners steeds vaker ambulant werken. Wijkverpleegkundigen, thuiszorgmedewerkers en ambulancepersoneel werken nu eenmaal niet aan een bureau met een vaste kaartlezer en kiezen in de praktijk voor andere inlogmethoden die vaak niet voldoen aan het vereiste beveiligingsniveau [4]. Daar komt bij dat de pas duur is: een UZI-pas kostte oorspronkelijk €255 voor drie jaar. Vanaf november 2026 wordt de prijs weliswaar verlaagd naar €127,50 per jaar, maar dat komt slechts doordat de geldigheidsduur om technische redenen is ingekort [5].

Voor kleinere organisaties blijft het een forse drempel. Zo fors dat passen in de praktijk onderling worden doorgegeven, wat de veiligheid juist ondermijnt. Bovendien is het bereik beperkt: de pas is primair bedoeld voor BIG-geregistreerde zorgverleners en mochten de UZI-middelen wettelijk gezien strikt genomen niet worden gebruikt voor toegang tot zorginformatiesystemen zoals het EPD-systeem. Tot slot staat de zorgidentiteit van een medewerker fysiek op de chip gebrand. Wisselt iemand van werkgever of functie? Dan is een geheel nieuwe pas nodig [6].

De oplossing: Dezi geeft de hele zorg één digitale identiteit

De Wet DIAZ introduceert een nieuw stelsel, namelijk Dezi (ofwel: ‘De ZorgIdentiteit’). Dezi bestaat uit twee onderdelen: een stelsel waarop zorgaanbieders hun zorgsystemen kunnen aansluiten en een register waar zorgmedewerkers en -organisaties zich inschrijven en hun digitale zorgidentiteit wordt beheerd. Kort gezegd: het register weet wie je bent en het stelsel regelt hoe je toegang krijgt. Samen vervangen zij op termijn het huidige UZI-stelsel [7].

Om dit juridisch mogelijk te maken worden de Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg (Wabvpz) en de Jeugdwet aangepast, waarbij de wijziging ook raakt aan de Wet Digitale Overheid (Wdo) en de Wet elektronische gegevensuitwisseling in de zorg (Wegiz) [8].

Concreet brengt Dezi de volgende veranderingen met zich mee:

Geen fysieke pas meer nodig. Inloggen kan straks via erkende digitale middelen, waaronder DigiD en de Europese Digitale Identiteit Wallet (de EDI-wallet). De EDI-wallet is een digitale portemonnee op de smartphone waarmee EU-burgers hun identiteit veilig kunnen bewijzen en documenten kunnen delen. De wallet vloeit voort uit de eIDAS-verordening, de Europese regelgeving die digitale identificatie en authenticatie harmoniseert binnen de EU. [9]
Meer keuzevrijheid. Zorgaanbieders en medewerkers kiezen zelf welk erkend inlogmiddel het beste past bij hun werkproces, zolang het voldoet aan betrouwbaarheidsniveau 'hoog' volgens de eIDAS-verordening. [10]
Breder bereik. Het Dezi-register is niet beperkt tot BIG-geregistreerden. Iedereen die in zijn of haar functie patiënt- of cliëntgegevens verwerkt, van verpleegkundige tot administratief medewerker, kan worden ingeschreven. [11]
Flexibeler bij veranderingen. De Dezi-registratie blijft bestaan bij een wisseling van werkgever of functie. Alleen de koppeling aan de zorgaanbieder wordt bijgewerkt, wat het ook eenvoudiger maakt voor flexmedewerkers en invalkrachten. [12]

Lagere kosten. De kosten worden naar verwachting significant lager dan bij de huidige UZI-middelen: schattingen lopen uiteen van €20 tot €70 per jaar per medewerker. Voor de jaren 2026 tot en met 2028 is daarnaast een stimuleringsregeling voorzien van in totaal 25 miljoen euro. [13]
Toekomstbestendig. Het stelsel sluit aan op de eIDAS-verordening en de European Health Data Space (EHDS), die zorgaanbieders verplichten te werken met interoperabele systemen. De Wet DIAZ vervult daarmee een randvoorwaarde voor de bredere digitalisering van de Europese gezondheidszorg.

Zo werkt Dezi in de praktijk

Om in te loggen via Dezi heeft een zorgmedewerker allereerst een zorgidentiteit nodig. Die zorgidentiteit bestaat minimaal uit een Dezi-nummer en de organisatie waarvoor de medewerker werkt. Om die te verkrijgen logt de medewerker in via het zorgmedewerkersportaal en doorloopt hij of zij in ongeveer vijf minuten drie stappen: het invoeren van contactgegevens op basis van de BRP, het opgeven van beroepsgegevens die waar mogelijk automatisch worden opgehaald uit het BIG-register en het controleren en indienen van de aanvraag. [14]

Zodra de zorgmedewerker is geregistreerd, kan worden ingelogd op aangesloten zorgsystemen. Bij elke inlog haalt het Dezi-register de zorgidentiteit op: een combinatie van een uniek nummer, de organisatie waarvoor gewerkt wordt en de bijbehorende bevoegdheden. De zorgaanbieder bepaalt vervolgens of de medewerker daadwerkelijk toegang krijgt. Inschrijving alleen is dus niet voldoende: de zorgaanbieder moet de toegang expliciet verlenen. [15]

De minister van VWS keurt de inlogmiddelen vooraf goed, een taak die in de praktijk wordt uitgevoerd door het Centraal Informatiepunt Beroepen Gezondheidszorg (CIBG). De erkende inlogmiddelen zijn de onder de Wet Digitale Overheid erkende publieke en private inlogmiddelen, zorgspecifieke inlogmiddelen, PKI-o-servercertificaten en onder de eIDAS-verordening genotificeerde middelen. Voldoet een middel niet meer aan de eisen, dan kan de goedkeuring worden geschorst of ingetrokken. [16]

Wanneer gaat dit gebeuren?

De overgang naar Dezi verloopt gefaseerd. De tijdlijn ziet er op dit moment als volgt uit [17]:

November 2026: Alleen nog mogelijk om éénjarige UZI-middelen aan te vragen.

November 2026: EU Digitale Identiteit Wallet beschikbaar.

Januari 2027: Dezi-stelsel technisch gereed.

November 2027: Uitgifte UZI-middelen stopt.

November 2028: Einde duale periode (UZI-middelen niet meer actief) en zorgaanbieder moet voor gebruik van SBV-Z gebruik maken van Dezi-stelsel.

2026 t/m 2028: Stimuleringsregeling nieuwe inlogmiddelen (25 miljoen euro).

2029: Uiterste datum uitfasering UZI-pas 30 september.

2030: Inlogmiddelen moeten kwantumproef zij.

1 januari 2031: Volledige verplichtstelling Dezi voor alle zorginformatie- en uitwisselingssystemen.

Nu voorbereiden loont

De UZI-pas verdwijnt dus op termijn en Dezi komt ervoor in de plaats. De overgangsperiode biedt ruimte, maar wie wacht tot het laatste moment loopt het risico achter de feiten aan te lopen. Platformleveranciers kunnen al vanaf 1 januari 2026 aansluiten op de testomgeving van het Dezi-stelsel om hun systemen te testen en de implementatie voor te bereiden. [18]

Voor zorgaanbieders betekent de Wet DIAZ: nu al nadenken over welke erkende inlogmiddelen passen bij de werkprocessen, of de systemen klaar zijn om aan te sluiten op het Dezi-koppelvlak en hoe je de registratie van medewerkers, tijdelijk personeel en zzp'ers borgt.

Wij volgen de ontwikkelingen op de voet. Heb je vragen over wat de Wet DIAZ betekent voor jouw organisatie of wil je weten hoe je je hier juridisch en praktisch op voorbereidt? Neem gerust contact met ons op.

[1] Kamerstukken II 2025/26, 36702, nr. 6, p. 71.

[2] 'DIAZ: belangrijke stap naar veilige toegang tot gezondheidsgegevens', uziregister.nl 6 oktober 2026.

[3] 'Gebruik van de UZI-pas', uziregister.nl.

[4] Kamerstukken II 2025/26, 36702, nr. 6, p. 5.

[5] 'Wijziging geldigheid UZI-middelen naar één jaar', uziregister.nl 20 oktober 2026.

[6] Kamerstukken II 2025/26, 36702, nr. 6, p. 5, 11-12 en 53.

[7] ‘Over Dezi', dezi.nl.

[8] Kamerstukken II 2024/25, 36702, nr. 3, p. 19.

[9] Kamerstukken II 2025/26, 36702, nr. 9, p. 9.

[10] 'Voor zorgmedewerkers', dezi.nl; Kamerstukken II 2025/26, 36702, nr. 6, p. 3.

[11]Kamerstukken II 2025/26, 36702, nr. 9, p. 13.

[12] Kamerstukken II 2025/26, 36702, nr. 6, p. 5.

[13] Kamerstukken II 2025/26, 36702, nr. 9, p. 18.

[14] 'Voor zorgmedewerkers', dezi.nl.

[15] Kamerstukken II 2024/25, 36702, nr. 3, p. 21; 'Voor zorgmedewerkers', dezi.nl.

[16] 'Voor zorgmedewerkers', dezi.nl; Kamerstukken II 2025/26, 36702, nr. 6, p. 3.

[17] ‘Tijdslijn’, dezi.nl; Kamerstukken II 2025/2026, 36702, nr. 6.

[18] 'Dezi testomgeving beschikbaar voor platformleveranciers', dezi.nl 5 januari 2026.

Klaar voor de nieuwe UAVG?

Laura van den Berg — Thu, 22 Oct 2026 08:28:39 GMT

Op 1 september 2026 is de Verzamelwet gegevensbescherming (Verzamelwet) in werking getreden. Deze wet wijzigt verschillende wetten met betrekking tot gegevensbescherming, waaronder de Uitvoeringswet Algemene verordening gegevensbescherming (UAVG). Het doel van de Verzamelwet is het actualiseren en moderniseren van het Nederlandse gegevensbeschermingsrecht. Klinkt droog? Op het eerste gezicht misschien wel, maar een aantal wijzigingen heeft directe gevolgen voor organisaties. De belangrijkste veranderingen zien op het verwerken van persoonsgegevens van minderjarigen, publicatie van sanctiebesluiten en een wijziging van de definitie van strafrechtelijke gegevens.

Benieuwd wat er concreet verandert en wat dit mogelijk voor jouw organisatie betekent? In dit blog zetten we de belangrijkste veranderingen op een rij.

Strafrechtelijke gegevens (artikel 1 UAVG)

Voor strafrechtelijke gegevens gelden strengere regels dan voor gewone persoonsgegevens. De verwerking ervan is in principe verboden, tenzij een specifieke wettelijke uitzondering van toepassing is én er een grondslag voor de verwerking bestaat op grond van artikel 6 AVG.

De Verzamelwet past de definitie van strafrechtelijke gegevens in artikel 1 UAVG aan. Voorheen vielen ook gegevens over een door de rechter opgelegd verbod naar aanleiding van onrechtmatig of hinderlijk gedrag onder strafrechtelijke gegevens. De Verzamelwet schrapt dit onderdeel, waardoor dergelijke gegevens niet langer automatisch als strafrechtelijke gegevens worden aangemerkt.

Jongeren krijgen meer eigen zeggenschap (artikel 5 UAVG)

Jong geleerd is oud gedaan, moet de wetgever gedacht hebben. Een van de meest opvallende wijzigingen gaat namelijk over de leeftijd waarop jongeren over hun persoonsgegevens mogen beslissen. Voorheen lag de grens voor het zelfstandig uitoefenen van AVG-rechten op 16 jaar. Op bepaalde vlakken is die grens nu verlaagd naar 12 jaar.

Dit betekent dat:

jongeren vanaf 12 jaar zelfstandig een verzoek op grond van hoofdstuk III van de Algemene verordening gegevensbescherming kunnen indienen;
jongeren vanaf 12 jaar zelfstandig toestemming voor een verwerking kunnen intrekken. Voor het geven van toestemming blijft de grens van 16 jaar gelden;
en ouders of wettelijke vertegenwoordigers de rechten van jongeren tussen de 12 en 16 jaar ook namens hen kunnen blijven uitoefenen.

De wijziging gaat uit van het idee dat jongeren zelf zeggenschap over hun persoonsgegevens horen te hebben, zonder tussenkomst van hun ouders.

Werk je met persoonsgegevens van minderjarigen? Controleer dan even of je procedures, formulieren en privacybeleid al aansluiten op deze nieuwe leeftijdsgrens.

Verplichte publicaties van AP-sancties (artikel 21b UAVG)

De Autoriteit Persoonsgegevens (AP) speelt voortaan verplicht open kaart: sanctiebesluiten moeten openbaar worden gemaakt. Helemaal nieuw is dat niet, want de AP deed dit voorheen al op grond van eigen beleid. Toch heeft het een voordeel, aangezien het standaard publiceren van de sancties ervoor zorgt dat het voor organisaties duidelijker en transparanter wordt hoe de AP de wet interpreteert en toepast.

Er gelden wel twee regels. Ten eerste mag de sanctie pas worden gepubliceerd tien werkdagen nadat de organisatie de beschikking heeft ontvangen. Daarnaast kan de organisatie bezwaar maken tegen zowel de sanctie als de publicatie daarvan.

Nieuw is ook dat de AP voortaan belanghebbenden raadpleegt voordat zij nieuwe beleidsregels vaststelt. Dit geeft organisaties een stem in hoe de AP de AVG uitlegt en handhaaft.

Strengere eisen voor het gebruik van biometrische gegevens (artikel 29 UAVG)

Personeel laten inklokken met een vingerafdruk? Handig misschien, maar mag dat nog wel? De regels voor het gebruik van biometrische gegevens zijn namelijk aangescherpt. De UAVG bevatte al een uitzondering waardoor organisaties biometrische gegevens onder bepaalde omstandigheden mochten gebruiken voor authenticatie of beveiliging. De Verzamelwet scherpt die uitzondering aan.

Verwerking van biometrische gegevens moet niet alleen noodzakelijk zijn voor authenticatie of beveiliging. Er moet ook sprake zijn van een zwaarwegend algemeen belang van rechtmatige toegang tot gebouwen, diensten, producten, informatiesystemen en werkprocessen. Organisaties zullen daarom moeten beoordelen of hun huidige toepassingen nog onder deze uitzondering vallen.

Duidelijke regels bij overdracht van medische dossiers (artikelen 30a en 30b UAVG)

Heb je te maken met de overdracht van patiëntendossiers? De wet regelt nu expliciet dat dit mag zónder toestemming van de patiënt, mits je de patiënt informeert over de overdracht en zijn rechten. Is dat op individueel niveau een onevenredige inspanning of niet toegestaan vanwege het beroepsgeheim? Dan moet de overdracht in ieder geval tijdig en in algemene bewoordingen bekend worden gemaakt.

Ook partijen die zelf geen zorgaanbieder zijn, krijgen een wettelijke basis voor overdracht. Denk aan een curator die na een faillissement in het bezit komt van dossiers van een gestaakte zorgpraktijk. Met de juiste waarborgen dragen zij die dossiers over aan een zorgaanbieder of zorginstelling die ze verder beheert.

Wat betekent dit voor jouw organisatie?

Geen paniek: je hoeft je privacywerkwijze niet van A tot Z om te gooien. Wel is het verstandig dat organisaties alert zijn op de gevolgen van de wijzigingen en dat zij waar nodig hun werkwijze aanpassen.

Heb je vragen over wat de Verzamelwet concreet voor jouw organisatie betekent? Neem gerust contact met ons op, wij denken graag met je mee.

Als de bank de rekening betaalt, wie lost dan het echte probleem op?

Tim Langelaar — Thu, 22 Oct 2026 08:16:41 GMT

Dit blog maakt deel uit van onze reeks over duurzame compliance, over het bouwen van raamwerken die niet alleen op papier kloppen, maar ook in de praktijk werken. In dit blog passen we die denkwijze toe op een actueel maatschappelijk vraagstuk: de toenemende druk op banken om phishingschade te vergoeden, ook als de klant zelf grove fouten heeft gemaakt. Niet om de uitkomst van rechtszaken ter discussie te stellen, maar om de gedragseffecten te doordenken en te zoeken naar de echte 'root cause'.

De omvang van het probleem: de cijfers liegen er niet om

Betalingsfraude in Nederland is in 2025 met 30 procent gestegen naar circa 658.000 gevallen. De totale schade bedroeg 198 miljoen euro, een stijging van 22 procent ten opzichte van 2024. Van alle dagelijkse betalingstransacties in Nederland, zo'n 27 miljoen per dag, waren er gemiddeld 1.800 frauduleus. Dat staat gelijk aan ruim 540.000 euro aan fraudeschade per dag^[1].

Overboekingsfraude steeg het hardst: 55 procent meer gevallen, goed voor 148 miljoen euro schade. Tegelijkertijd ontving de Fraudehelpdesk in 2025 meer dan 100.000 meldingen, een stijging van 60 procent, met bijna 69 miljoen euro schade als gevolg^[2].

Dat zijn geen abstracte statistieken. Achter elk geval zit een consument die geld kwijt is, vaak via social engineering die zelfs een kritische en digitaal vaardige persoon kan treffen. Tegelijkertijd roept de omvang van de schade een fundamentele vraag op: zijn de maatregelen die we nemen proportioneel aan de oorzaak, of behandelen we het symptoom?

Een uitspraak die vragen oproept

In die context bevestigde de kortgedingrechter in Antwerpen begin juni 2025: banken moeten slachtoffers van phishing in beginsel meteen, en voorlopig, terugbetalen, ook als de klant grof nalatig is geweest. Pas achteraf mag de bank proberen te bewijzen dat er sprake was van eigen schuld.

In Nederland zagen we eerder eenzelfde lijn bij het Kifid: in oktober 2024 veroordeelde het financieel klachteninstituut Knab tot vergoeding van bijna 49.000 euro aan een klant die zelf remote access-software had geïnstalleerd, zijn paspoort had getoond en zes transacties had laten doorlopen.

En op EU-niveau: op 5 maart 2026 bracht Advocaat-Generaal Rantos bij het Hof van Justitie van de EU zijn conclusie uit in zaak C-70/25^[3]. De conclusie: een bank kan onmiddellijke terugbetaling van een niet-toegestane transactie niet weigeren op de enkele grond dat de klant grof nalatig zou zijn geweest. Eerst terugbetalen, dan eventueel de schuld via de rechter verhalen. Op 15 oktober 2026 heeft het HvJEU het arrest gewezen en het advies van de AG gevolgd^[4].

De juridische lijn is duidelijk. Maar is dit de goede oplossing voor het echte probleem?

Het wettelijk kader: waar komt de aansprakelijkheid van de bank vandaan?

PSD1 (2007), De eerste Europese Betaaldienstenrichtlijn (2007/64/EG) legde vast dat banken in beginsel aansprakelijk zijn voor niet-toegestane betalingstransacties. De achterliggende gedachte, breed erkend in rechtspraak en literatuur, is dat consumenten zwak staan tegenover professionele betaaldienstverleners. Banken beschikken over de technische infrastructuur, de detectiemogelijkheden en de authenticatiemiddelen. Wie het beste in staat is fraude te voorkomen, draagt ook de aansprakelijkheid als dat niet lukt. PSD1 kende nog een eigen bijdrage van maximaal €150 voor de consument bij verlies of diefstal van een betaalinstrument, ook zonder grove nalatigheid.

PSD2 (2018), Artikel 73 van Richtlijn 2015/2366/EU verscherpte dit: betaaldienstverleners moeten niet-toegestane transacties onmiddellijk vergoeden, uiterlijk aan het einde van de eerstvolgende werkdag na kennisgeving door de klant. Twee uitzonderingen: de bank kan terugbetaling weigeren als zij bewijst dat de klant zelf frauduleus heeft gehandeld, of als zij objectief gerechtvaardigde gronden heeft voor het vermoeden van fraude door de klant, mits dat schriftelijk wordt gemeld aan de bevoegde autoriteit. De bewijslast voor authenticatie en autorisatie ligt daarmee expliciet bij de bank^[5], niet bij de consument. Tegelijkertijd introduceerde PSD2 strengere eisen aan sterke klantauthenticatie (SCA): betere beveiliging aan de voorkant zou fraude verminderen. PSD2 heeft de eigen bijdrage verlaagd naar €50.

De praktijk bleek weerbarstiger. Banken weken breed af van de terugbetalingsverplichting door grove nalatigheid als weigeringsgrond vooraan in het proces te plaatsen, terwijl de bewijslast wettelijk bij hén lag. Zowel de Belgische ombudsman Ombudsfin (2025) als onderzoek van de Federatie van Duitse Consumentenorganisaties als uitspraken van Kifid bevestigen dit patroon. Dat is precies wat de recente uitspraken, en het HvJEU-arrest van 15 oktober 2026, rechtstreeks aankaarten: consumenten moesten zichzelf verdedigen in plaats van dat de bank moest bewijzen.

PSD3 en de PSR, wat verandert er? In april 2026 is een politiek akkoord bereikt op de teksten van PSD3 en de nieuwe Payment Services Regulation (PSR); formele vaststelling wordt verwacht in 2026. Inwerkingtreding wordt verwacht eind 2027. De belangrijkste veranderingen:

Directe werking. De PSR wordt een verordening met directe werking in alle EU-lidstaten, waardoor nationale verschillen in interpretatie van begrippen als "grove nalatigheid" kleiner worden.
Ruimere vergoedingsplicht. PSD3/PSR breidt de vergoedingsplicht expliciet uit naar authorized push payment (APP) fraude, situaties waarbij een consument zelf een betaling autoriseert op basis van misleiding. Een significante uitbreiding ten opzichte van PSD2.
Verplichte IBAN-naamscontrole. Bij elke overboeking moet worden gecontroleerd of naam en IBAN overeenkomen. Dit bestond al bij de Instant Payments Regulation (IPR) en wordt nu uitgebreid naar reguliere overboekingen.
Gereguleerde fraudedatadeling. De PSR biedt betaaldienstverleners expliciet de ruimte om in een gestructureerd kader fraudedata met elkaar te delen, binnen AVG-kaders.

PSD3/PSR brengt daarmee een gemengd beeld: uitbreiding van bescherming bij APP-fraude, maar tegelijkertijd introduceert artikel 56 PSR een nieuwe mogelijkheid voor banken om onmiddellijke terugbetaling bij niet-toegestane transacties uit te stellen bij 'objectief gerechtvaardigde' verdenking van grove nalatigheid. Of dit de consumentenbescherming per saldo versterkt of verzwakt, zal afhangen van hoe rechters en toezichthouders die nieuwe uitzonderingsgrond in de praktijk uitleggen, juist nu het HvJEU in Tukowiecka heeft vastgesteld dat de wetgever in 2015 die uitzondering bewust niet heeft opgenomen. Bovendien is fraudedatadeling een facultatieve mogelijkheid, geen verplichting, en brengt het reële risico's mee op het gebied van privacy en onterechte verdenkingen op basis van algoritmische bias.

Gedrag volgt prikkels, aan beide kanten van de lijn

Als je in systemen denkt, weet je: prikkels bepalen gedrag. Niet intenties, niet bewustzijn alleen, maar vooral prikkels. In dat licht is het verdedigbaar dat het HvJEU een zwaardere prikkel bij banken neerlegt: wie de infrastructuur beheert en profiteert van digitaal betalingsverkeer, moet ook de preventie en de restschade internaliseren. Zonder die prikkel dreigt een perverse stimulans om verantwoordelijkheid en zware gevolgen naar consumenten te verschuiven in plaats van te investeren in onderliggende oorzaakmaatregelen.

Aan de kant van de consument. Als een bank verplicht wordt te vergoeden, ook bij aantoonbaar onvoorzichtig handelen, verandert de risicoafweging voor de consument. Niet bewust, niet malicieus, maar wel reëel. Gedragseconomen noemen dit moral hazard: minder voorzichtigheid omdat de gevolgen van risicogedrag door een ander worden gedragen. De consument die weet dat de bank toch vergoedt, heeft een kleinere prikkel om phishingberichten kritisch te beoordelen of te weigeren remote access te verlenen. Dit is geen verwijt, het is een voorspelbaar gevolg van de structuur van de prikkel.

Aan de kant van de criminelen. Phishing is georganiseerde criminaliteit met een businessmodel. Als banken systematisch vergoeden, stijgt het netto-rendement van phishing: meer schade die "werkt", minder maatschappelijke weerstand en indirect meer kapitaal dat terugvloeit naar het criminele ecosysteem.

De kosten worden gesocialiseerd. Als banken structureel phishingschade vergoeden, worden de kosten niet gedragen door fraudeurs of de onvoorzichtige consument, maar door alle klanten samen. Met 198 miljoen euro aan betalingsfraude in 2025 en een verwachte verdere stijging door de uitbreiding van de vergoedingsplicht onder PSD3, is dit geen marginale post. De fraudeur profiteert, de onvoorzichtige klant wordt schadeloos gesteld en de rekening wordt verdeeld over miljoenen klanten die zelf niets fout hebben gedaan.

De echte rootcause ligt elders, en daar knelt het

Phishing werkt om drie redenen. Criminelen kunnen veelal ongestoord opereren doordat ze grensoverschrijdend te werk gaan en moeilijk traceerbaar zijn. Zo'n 70 procent van alle online fraude begint op sociale media, een cijfer dat de NVB in april 2026 gebruikte in haar publieke oproep aan sociale mediaplatforms om meer maatregelen te nemen^[6]. Consumenten worden onvoldoende beschermd op het moment dat de aanval plaatsvindt. En relevante data kan niet gedeeld worden tussen de partijen die samen fraude zouden kunnen detecteren en voorkomen.

Dat laatste punt is cruciaal. Banken, telecomaanbieders en andere partijen beschikken elk over stukjes van de puzzel. Een telecomaanbieder ziet dat een nummer wordt gebruikt voor spoofing. Een bank ziet een ongebruikelijk transactiepatroon. Een andere bank ziet dat een ontvangstrekening al eerder bij fraude betrokken was. Sámen zouden ze een aanval in real-time kunnen detecteren en afbreken. Tegelijk geldt dat het samenbrengen van meerdere hooibergen het aantal spelden niet vergroot: meer data is niet automatisch betere detectie; gerichte, proportionele en kwaliteitsgedreven uitwisseling is bepalend.

Maar dat delen van data stuit op principiële privacybezwaren. Zwarte lijsten van frauduleuze rekeningnummers mogen niet breed worden gedeeld vanwege AVG-beperkingen. Gecoördineerde real-time informatie-uitwisseling tussen telecom en financiële sector is jarenlang bepleit vanuit consortia van betrokken partijen, maar stokt bij standpunten van toezichthouders als de Autoriteit Persoonsgegevens en politieke afwegingen over datadeling.

Dit is geen verwijt aan de AP of de politiek. Het zijn reële spanningsvelden tussen twee legitieme waarden: privacybescherming en fraudepreventie. Maar het is wél een pijnpunt dat benoemd moet worden. PSD3/PSR biedt hier een eerste concrete opening via gestructureerde fraudedatadeling, of dat voldoende is om het knelpunt met telecom en toezichthouders te doorbreken, valt nog te bezien.

Conclusie: vergoed de schade, maar los het probleem op

De uitspraken die banken verplichten phishingschade te vergoeden, komen voort uit een begrijpelijk rechtvaardigheidsgevoel, en uit een weloverwogen juridische keuze: door aansprakelijkheid bij de sterkste partij neer te leggen, corrigeert het recht een asymmetrie. Banken zijn het best gepositioneerd om systemen, processen en klantinteracties veilig te ontwerpen en kunnen schaalbaar investeren in preventie en herstel. Consumenten staan zwak, fraude is geavanceerd en de bank heeft meer middelen om risico's te dragen.

Maar rechtvaardig voelen en effectief zijn, zijn twee verschillende dingen.

Maak de afweging tussen privacybescherming en fraudepreventie expliciet, en gebruik de opening die PSD3 biedt. Ontwerp maatregelen die gedrag beïnvloeden in de goede richting: alertheid omhoog, risico voor fraudeurs omhoog, schade omlaag. En als de vergoedingsverplichting bedoeld is als tijdelijke prikkel voor banken om zwaarder in preventie te investeren, maak dat dan expliciet beleid, koppel het aan aantoonbare preventie-inspanningen en bouw een evaluatiemoment in.

De cijfers spreken voor zich: 198 miljoen euro schade in 2025, 30 procent meer dan het jaar daarvoor, ondanks jarenlange bewustwordingscampagnes en bestaande vergoedingskaders. Zolang de echte oorzaken onbehandeld blijven, betalen we collectief de rekening van een probleem dat we niet oplossen.

Dit blog gaat over een complex maatschappelijk vraagstuk waarover juridisch, politiek en ethisch zeer uiteenlopende opvattingen bestaan. Het doel is niet om een politiek standpunt in te nemen, maar om het gedragscomponent te doordenken en de onderliggende oorzaak te benoemen.

Heb je vragen, een andere invalshoek of wil je sparren over hoe jouw organisatie omgaat met de afweging tussen privacybescherming en fraudepreventie? Neem contact met ons op. We denken graag met je mee.

^[1]DNB, juni 2026

^[2]Fraudehelpdesk, februari 2026

^[3]Tukowiecka/PKO BP

^[4] ECLI:EU:C:2026:852

^[5]artikel 72 PSD2

^[6]NVB/banken.nl, mei 2026