waar moet de hosting van mijn productpaspoort aan voldoen

De hosting moet gegevens blijvend beschikbaar en toegankelijk houden

De hosting van een digitaal productpaspoort moet ervoor zorgen dat de gegevens erin blijven bestaan, actueel te houden zijn, en op te vragen zijn door wie daar volgens de regels recht op heeft — consumenten, marktdeelnemers, en toezichthoudende autoriteiten. Artikel 10 van de ESPR (Verordening (EU) 2024/1781) legt vast dat het paspoort toegankelijk moet zijn via de datadrager op het product (doorgaans een QR-code), dat de gegevens die erin staan kloppen en bijgewerkt kunnen worden, en dat de opslag zo is ingericht dat het paspoort de voorgeschreven periode meegaat. Daarnaast schrijft artikel 13 voor dat een verwijzing naar elk paspoort terechtkomt in een centraal Europees register, en regelt artikel 14 dat de Commissie een webportaal inricht waarmee die geregistreerde gegevens raadpleegbaar zijn. Hosting is dus niet alleen "een pagina die opengaat als je scant" — het is een technische en organisatorische verantwoordelijkheid die doorloopt zolang het paspoort moet bestaan.

Voor wie dit geldt, en waarvoor niet

Deze eisen gelden voor degene die het digitale productpaspoort aanbiedt: in de praktijk de fabrikant, importeur of gemachtigde die verantwoordelijk is voor het in de handel brengen van het product, of een partij die deze taak namens hen uitvoert. Het gaat om de hosting van het paspoort zelf — de plek waar de productgegevens staan die via de datadrager opgeroepen worden. Het gaat niet over de datadrager als zodanig: hoe de QR-code op het product komt en welke technische vorm die aanneemt, is een andere vraag, uitgewerkt op de pagina over hoe de QR-code op het product komt. Het gaat ook niet over de vraag wélke gegevens in het paspoort moeten staan of in welk bestandsformaat die aangeleverd worden — dat wordt per productcategorie apart bepaald en staat beschreven op de pagina over het aanleveren van productpaspoortgegevens. Hosting is specifiek de infrastructuur: waar de data staat, hoe lang, en hoe die bereikbaar blijft.

De precieze eisen volgen per productcategorie, vanaf een datum die nog niet vaststaat

De ESPR zelf beschrijft de hoofdlijnen — toegankelijkheid, actualiteit, koppeling aan het register — maar de gedetailleerde technische en operationele eisen aan hosting worden per productcategorie vastgelegd in gedelegeerde handelingen. Voor elektronica en ICT-apparatuur is nog niet gepubliceerd wanneer die verplichting precies ingaat. Het ESPR-werkplan 2025-2030 noemt deze categorieën, en gedelegeerde handelingen worden daarin verwacht vanaf 2027, maar een vaste datum voor elektronica en ICT is er nog niet. Tot een gedelegeerde handeling voor een specifieke productgroep is gepubliceerd, geldt er voor die groep nog geen concrete hostingverplichting vanuit de ESPR. Zodra de handeling voor elektronica en ICT gepubliceerd wordt, komt de datum hier te staan.

Wat dit betekent voor de inrichting van de hosting

Wie nu al nadenkt over hosting van een productpaspoort, doet er goed aan te beginnen bij de duur: het paspoort moet beschikbaar blijven voor een periode die per productcategorie wordt vastgesteld, en die eis raakt direct aan de keuze van hostingpartij en -infrastructuur — dit wordt verder toegelicht op de pagina over hoe lang een productpaspoort beschikbaar moet blijven. Een tweede aandachtspunt is continuïteit: de hosting moet blijven functioneren ook als er iets verandert aan het bedrijf dat het paspoort aanbiedt, wat relevant wordt bij bedrijfsbeëindiging of overname — zie de pagina over wat er gebeurt met het paspoort als een bedrijf stopt. Een derde punt is de koppeling met het Europese register: de hostingomgeving moet zodanig zijn ingericht dat de verwijzing naar het paspoort correct en actueel in het register staat, wat wordt uitgelegd op de pagina over het register van digitale productpaspoorten. Wie de productdata al in een ERP- of voorraadsysteem beheert, kan bovendien vooruitkijken naar hoe die koppeling praktisch wordt ingericht. Ten slotte is het raadzaam om bij de keuze van een hostingpartij te letten op wat er gebeurt bij een storing, een overname van de hostingpartij zelf, of het aflopen van een contract — punten die niet met zoveel woorden in de ESPR staan, maar die in de praktijk bepalen of aan de achterliggende eis van blijvende toegankelijkheid wordt voldaan.

Waar dit op is gebaseerd: artikel 10, 13 en 14 van de ESPR

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) beschrijft de algemene vereisten voor het digitale productpaspoort, waaronder toegankelijkheid en actualiteit van de gegevens. Artikel 13 regelt het centrale register waarin een verwijzing naar elk paspoort wordt opgenomen, en artikel 14 regelt het webportaal waarmee de Commissie die registergegevens ontsluit. Samen vormen deze artikelen het kader waarbinnen hosting van een paspoort moet functioneren; de productcategorie-specifieke details volgen in latere gedelegeerde handelingen.

Wie nu al een productpaspoort voorbereidt, kan het beste beginnen met het uitzoeken van de eigen productcategorie en de status van de bijbehorende gedelegeerde handeling, en van daaruit de eisen aan bewaartermijn en registerkoppeling meenemen in de keuze van een hostingoplossing.

Waar dit op gebaseerd is

De verordening zelf staat op EUR-Lex. Wij verwijzen per bewering; u hoeft ons niet te geloven.

Wat u concreet moet doen

Wat er van u wordt verwacht

De ESPR schrijft niet voor bij welke hostingpartij een productpaspoort moet staan, maar wel aan welke eigenschappen de opslag en ontsluiting van de gegevens moeten voldoen. Artikel 10 van de ESPR (Verordening (EU) 2024/1781) benoemt de vereisten voor het digitale productpaspoort zelf; artikel 13 gaat over het register waarin paspoorten worden aangemeld; artikel 14 regelt het webportaal waarmee toezichthouders en andere partijen bij de gegevens kunnen. Voor een bedrijf van 10 tot 100 medewerkers komt dat neer op een aantal losse, concrete verplichtingen.

Het paspoort moet bereikbaar blijven via de datadrager op het product

Het paspoort wordt ontsloten via een datadrager — in de praktijk een QR-code — die op of bij het product wordt aangebracht. Artikel 10 van de ESPR stelt eisen aan die koppeling tussen drager en paspoort: de link moet blijven werken, ook als er jaren overheen gaan. Voor een middelgroot bedrijf betekent dit dat de keuze van een hostingpartij niet los staat van de keuze voor de datadrager: beide moeten op elkaar aansluiten en dat langdurig blijven doen. Hoe die koppeling in de praktijk wordt gelegd, staat beschreven bij hoe komt de QR-code voor het productpaspoort op mijn elektronica.

De gegevens moeten door de juiste partijen te raadplegen zijn, zonder dat iedereen alles ziet

Artikel 10 maakt onderscheid tussen gegevens die voor iedereen zichtbaar zijn — bijvoorbeeld voor een consument die de QR-code scant — en gegevens die alleen voor toezichthouders of andere marktdeelnemers bedoeld zijn. Een hostingomgeving moet dat onderscheid technisch kunnen waarmaken. Voor een bedrijf betekent dit dat de gekozen oplossing niet simpelweg "alles openbaar" of "alles achter een login" kan zijn: er moet een gelaagde toegang mogelijk zijn, afgestemd op wie welk deel van de informatie nodig heeft.

Het paspoort moet aangemeld worden in het Europese register

Artikel 13 van de ESPR verplicht tot registratie van het paspoort in een centraal Europees register, met daarin een basisset aan gegevens over het product en de vindplaats van het paspoort. De hosting van het paspoort zelf en de registratie in dat register zijn twee gescheiden dingen: het paspoort kan bij een eigen of externe hostingpartij staan, terwijl het register alleen de verwijzing en kerngegevens bevat. Wat daarin moet komen en hoe die aanmelding werkt, staat toegelicht bij wat is het register van digitale productpaspoorten en wat moet ik daarin zetten.

De gegevens moeten aansluiten op het webportaal voor toezicht

Artikel 14 van de ESPR introduceert een webportaal waarmee markttoezichtautoriteiten en douane gegevens uit digitale productpaspoorten kunnen raadplegen. Voor de hostingpartij betekent dit dat de opslag van paspoortgegevens niet geïsoleerd kan zijn: er moet een technische aansluiting mogelijk zijn op dit portaal, in een vorm die door de Commissie wordt bepaald. Een bedrijf dat zelf hostet of een hostingpartij inschakelt, doet er goed aan om te vragen of die partij bekend is met deze aansluitplicht en hoe die wordt ingevuld.

De gegevens moeten in een herkenbaar en overdraagbaar formaat staan

Hosting is niet alleen een kwestie van "waar staat het", maar ook "in welke vorm". Artikel 10 stelt eisen aan interoperabiliteit: de gegevens moeten machinaal leesbaar en overdraagbaar zijn, zodat ze niet vast blijven zitten in één systeem van één leverancier. Voor een bedrijf van beperkte omvang is dit vaak het punt waar de keuze voor een hostingpartij het zwaarst weegt: een gesloten systeem dat moeilijk te exporteren is, botst met deze eis. Het bestandsformaat waarin gegevens aangeleverd worden, is uitgewerkt bij in welk formaat moet ik de productpaspoortgegevens aanleveren.

Waar het misgaat in de praktijk

Een veelvoorkomende situatie is dat een bedrijf een hostingpartij kiest zonder te vragen of die partij een technische aansluiting op het webportaal van artikel 14 kan waarborgen. Op het moment dat een toezichthouder gegevens wil raadplegen, blijkt de koppeling er niet te zijn.

Een andere situatie ontstaat wanneer het onderscheid tussen openbare en niet-openbare gegevens niet goed is ingericht: alle informatie staat achter dezelfde toegang, of juist alles staat volledig open, terwijl bepaalde gegevens alleen voor marktdeelnemers of toezicht bedoeld zijn.

Ook komt het voor dat een bedrijf de hosting van het paspoort verwart met registratie in het Europese register: men denkt dat het paspoort "geregistreerd" is omdat het online staat, terwijl de aanmelding bij het register een aparte stap is die niet automatisch gebeurt.

Een vierde situatie is een hostingpartij die na een tijdje de dienst staakt of overgenomen wordt, waarbij de gegevens niet in een overdraagbaar formaat beschikbaar zijn. Het bedrijf zit dan vast aan een systeem dat niet meer bereikbaar is, terwijl de QR-code op het product al in omloop is.

Een vijfde, veelgemaakte fout is dat de koppeling tussen de datadrager op het product en de hostinglocatie technisch los van elkaar wordt georganiseerd — bijvoorbeeld doordat een verpakkingsleverancier de QR-code aanmaakt zonder afstemming met de partij die de gegevens hostet. Bij een wijziging van hostingpartij werkt de code dan niet meer.

Wat u kunt vastleggen

Een overzicht van welke gegevens in het paspoort openbaar zijn en welke alleen voor toezicht of marktdeelnemers bedoeld zijn, zodat de hostingpartij dit onderscheid technisch kan inrichten.
Een schriftelijke afspraak met de hostingpartij over de aansluiting op het webportaal van artikel 14, inclusief wie verantwoordelijk is als die aansluiting wijzigt.
Een vastgelegde procedure voor de aanmelding in het Europese register, gescheiden van de hostingafspraken — zie ook de toelichting bij wat is het register van digitale productpaspoorten en wat moet ik daarin zetten.
Een exportmogelijkheid of contractuele garantie dat gegevens in een overdraagbaar formaat opgevraagd kunnen worden bij beëindiging van de hostingovereenkomst.
Documentatie van de koppeling tussen datadrager en hostinglocatie, inclusief wat er gebeurt bij wijziging van hostingpartij of systeem — relevant is ook hoe dit samenhangt met kan ik het productpaspoort koppelen aan mijn ERP- of voorraadsysteem.
Een afspraak over de duur van de hostingverplichting, af te stemmen met wat bekend is over hoe lang moet een productpaspoort beschikbaar blijven.

Dit is geen juridisch advies. Deze pagina geeft algemene informatie over de regelgeving waar dit platform over gaat. Wij kennen uw situatie niet. Bij twijfel over uw eigen geval raadpleegt u een jurist of de bevoegde toezichthouder.

Geschreven met AI op basis van de bronnen hierboven, gecontroleerd door een mens op 2026-09-05. Klopt er iets niet? Laat het weten — correcties krijgen voorrang.