Bij een hack gaat de aandacht vrijwel altijd uit naar de aanvaller en naar de organisatie die het lek moet dichten. De vraag wie de schade uiteindelijk draagt, komt pas daarna. De Algemene verordening gegevensbescherming (‘AVG’) richt zich tot verwerkingsverantwoordelijken en verwerkers. Wie slimme apparaten of software maakt, valt daar alleen onder als hij zelf persoonsgegevens verwerkt, bijvoorbeeld in de cloudomgeving die bij het product hoort.
In de praktijk belandde de rekening daardoor bij de organisatie die het product gebruikte. Zij is verwerkingsverantwoordelijke en dus het adres voor klachten van betrokkenen en voor vragen van de Autoriteit Persoonsgegevens (‘AP’). Die organisatie moest vervolgens maar zien wat haar contract met de leverancier waard was.
Dat beeld is aan het verschuiven. De Cyber Resilience Act (‘CRA’) en de nieuwe Richtlijn Productaansprakelijkheid (hierna ook afgekort als PLD, dat staat voor Product Liability Directive) leggen de verantwoordelijkheid voor onveilige verbonden producten steeds nadrukkelijker bij de partijen die het product op de markt brengen. In dit blog lopen we die verschuiving langs aan de hand van één voorbeeld, en zetten we per rol op een rij wie waarvoor kan worden aangesproken.
Neem een slimme videodeurbel, gemaakt door een fabrikant buiten de EU, in Nederland verkocht via een webshop. Het product komt begin 2028 op de markt. In de firmware zit een al publiek bekende kwetsbaarheid in een verouderde opensourcebibliotheek. Een update blijft uit. In het najaar van 2028 wordt de kwetsbaarheid op grote schaal misbruikt. Aanvallers krijgen toegang tot camerabeelden en accountgegevens van duizenden gebruikers en wissen opgeslagen opnames. Een makelaarskantoor dat de deurbel bij de ingang gebruikt, ziet beelden van zijn bezoekers online verschijnen. De aanvallers zullen nooit betalen. De schade moet dus elders worden verhaald.
De CRA stelt cyberbeveiligingsvereisten aan producten met digitale elementen: hardware en software die verbinding maken met een apparaat of netwerk. De meldplichten gelden sinds 11 september 2026, de overige verplichtingen vanaf 11 december 2027.[1] De deurbel uit het voorbeeld komt daarna op de markt en valt dus onder het volledige regime.
De zwaarste verplichtingen liggen bij de fabrikant.[2] Hij mag het product alleen in de handel brengen als het voldoet aan de essentiële cyberbeveiligingsvereisten van bijlage I. Daarnaast moet hij kwetsbaarheden verhelpen met kosteloze beveiligingsupdates en zorgvuldigheid toepassen bij componenten van derden, inclusief opensourcecomponenten. De importeur mag een product van buiten de EU alleen in de handel brengen als de fabrikant zijn verplichtingen is nagekomen, en de distributeur controleert onder meer of de CE-markering en de vereiste informatie aanwezig zijn[3].
Die rolverdeling ligt niet vast. Wie een product onder zijn eigen naam of merk verkoopt, of het substantieel wijzigt, geldt onder de CRA als fabrikant[4].
Voor de webshop uit het voorbeeld is dat bepalend: staat zijn merknaam op de deurbel, dan rusten op hem de verplichtingen van de fabrikant; zo niet, dan is hij importeur of distributeur.
Voor schadevergoeding is de PLD van belang[5]. Die geldt voor producten die na 8 december 2026 op de markt komen. Software is daarbij een product, zowel wanneer die software op een apparaat staat als wanneer deze als dienst wordt geleverd.
Cyberbeveiliging telt mee bij de vraag of een product gebrekkig is. Voldoet een product niet aan de veiligheidseisen die juist dat soort schade moeten voorkomen, dan geldt het als gebrekkig. De fabrikant mag vervolgens bewijzen dat het wél in orde was[6]. De essentiële cyberbeveiligingsvereisten uit bijlage I bij de CRA zijn zulke eisen. Een aantoonbare CRA-schending maakt een claim dus een stuk eenvoudiger.
Wie wordt aangesproken? Eerst de fabrikant, en dus ook de partij die het product onder eigen merk verkoopt. Zit de fabrikant buiten de EU, dan kan de benadeelde bij de importeur of de gemachtigde (de vertegenwoordiger van de fabrikant in de EU) terecht. Is er niemand in de EU aan te spreken, dan komt de distributeur in beeld als hij niet kan zeggen van wie hij het product betrok.
Voor de privacypraktijk zit hier de belangrijkste beperking. Alleen natuurlijke personen, dus geen bedrijven, kunnen op grond van de PLD schadevergoeding vragen, en schade aan gegevens alleen voor zover die gegevens niet zakelijk worden gebruikt[7]. Beschadigde of vernietigde gegevens van particuliere gebruikers vallen daaronder, bijvoorbeeld opnames die zijn gewist of die door versleuteling onleesbaar zijn gemaakt. Uitgelekte camerabeelden niet: dat is een privacyschending, waarvoor de AVG het kader blijft. Het makelaarskantoor uit het voorbeeld staat hier met lege handen, want zijn schade is zakelijk.
Voor de uitgelekte beelden blijft de AVG het kader. Het makelaarskantoor is verwerkingsverantwoordelijke voor de beelden van zijn bezoekers en moet passende beveiligingsmaatregelen nemen. Dat de leverancier een gebrekkig product leverde, is daarbij geen vrijbrief: het kantoor moet zelf kunnen laten zien dat zijn maatregelen passend waren. In de praktijk betekent dat: koop producten die aan de CRA voldoen, houd bij wanneer de ondersteuningsperiode afloopt, installeer beveiligingsupdates en volg de beveiligingsadviezen van de fabrikant op. Wie dat nalaat, komt bij een klacht van betrokkenen of een onderzoek van de AP niet weg met een verwijzing naar zijn leverancier.
De vraag blijft dus: kan het makelaarskantoor de schade verhalen op de leverancier? Het gaat dan bijvoorbeeld om claims van betrokkenen, de kosten van het datalek en het onderzoek dat daarop volgt. De PLD biedt die route niet. Dan blijft het contract over: non-conformiteit, garanties en vrijwaringen. Je spreekt je leverancier aan, en die kan op zijn beurt naar de maker van het product.
Tegenover zakelijke klanten mag een leverancier zijn aansprakelijkheid wel beperken, zolang dat redelijk is. Tegenover particulieren kan dat niet. Hoeveel er te verhalen valt, wordt dus vooral bij de inkoop bepaald.
Voor fabrikanten en partijen die onder eigen merk verkopen:
Bepaal per product of je fabrikant, importeur of distributeur bent. Een eigen merk of een eigen aanpassing maakt je fabrikant.
Leg vast wat je doet: risicobeoordeling, SBOM (‘software bill of materials’, de lijst met componenten in je product), patchhistorie en meldingen. Die documentatie is je verdediging als er een claim komt.
Kies de ondersteuningsperiode bewust. Je aansprakelijkheid loopt tot tien jaar na het in de handel brengen door, ook als de ondersteuning eerder stopt.[8]
Voor importeurs en distributeurs:
Vraag leveranciers van buiten de EU om hun CRA-documentatie en leg vrijwaringen contractueel vast.
Houd per product bij van wie je het betrekt, zodat je altijd kunt aanwijzen wie aansprakelijk is.
Voor organisaties die verbonden producten gebruiken: welke producten je in huis hebt en hoe lang die worden ondersteund, zetten we eerder al op een rij. Met het oog op schade komen daar de volgende aandachtspunten bij:
Leg in je inkoopvoorwaarden vast dat de leverancier CRA-conform levert, hoe lang hij updates levert en hoe hij kwetsbaarheden bij je meldt.
Documenteer dat je updates en beveiligingsadviezen ook daadwerkelijk opvolgt. Zonder dat bewijs sta je zwak richting toezichthouders als de AP en de Rijksinspectie Digitale Infrastructuur (RDI), en richting je leverancier.
Controleer of de aansprakelijkheidsplafonds in je contracten passen bij de schade die een gehackt product kan veroorzaken.
De hacker betaalt niet. De rekening komt daardoor terecht bij de partijen die de kwetsbaarheid hadden kunnen voorkomen of verhelpen, en bij de organisatie die het product in gebruik had. De CRA en de PLD verschuiven het zwaartepunt naar de eerste groep. De verantwoordelijkheid voor passende beveiliging onder artikel 32 AVG blijft wel bij de verwerkingsverantwoordelijke zelf: in een contract leg je hooguit vast wie welke schade draagt.
Wil je weten welke rol jouw organisatie onder de CRA vervult, of hoe je je inkoopvoorwaarden en contracten hierop inricht? Wij denken graag met je mee.
[1]Artikel 14 en artikel 71 lid 2 Cyber Resilience Act (EU) 2024/2847
[2]Artikel 13 Cyber Resilience Act (EU) 2024/2847
[3]Artikel 19 en 20 Cyber Resilience Act (EU) 2024/2847
[4]Artikel 21 en 22 Cyber Resilience Act (EU) 2024/2847
[5]Productaansprakelijkheidsrichtlijn (EU) 2024/2853
[6]Artikel 10 lid 2 onder b Richtlijn Productaansprakelijkheid (EU) 2024/2853
[7]Artikel 5 en 6 lid 1 onder c Richtlijn Productaansprakelijkheid (EU) 2024/2853
[8]Artikel 17 Richtlijn Productaansprakelijkheid (EU) 2024/2853
Meld je nu aan voor één van de nieuwsbrieven van ICTRecht en blijf op de hoogte van onderwerpen zoals AI, contracteren, informatiebeveiliging, e-commerce, privacy, zorg & ICT en overheid.