Waarom "eenmalig registreren" niet genoeg is
Veel bedrijven behandelen het Digitaal Productpaspoort (DPP) als een eenmalige nalevingsoefening: gegevens verzamelen, een registervermelding aanmaken, klaar. De ESPR-verordening (EU) 2024/1781 vertelt een ander verhaal. Ze vereist dat registervermeldingen beschikbaar en actueel blijven gedurende ten minste 10 jaar nadat een product voor het laatst op de markt is gebracht. Als u vandaag een model uit productie neemt, moet u de vermelding ervan tot ten minste 2036 in stand houden — inclusief geldige resolver-endpoints en correcte unieke identificatiecodes.
Dit artikel legt uit wat het bijwerken van een registervermelding daadwerkelijk inhoudt, welke velden worden geraakt en hoe u het proces aan de technische kant kunt beveiligen.
Wat het register opslaat — en wat niet
Op 29 april 2026 publiceerde de Europese Commissie de ontwerp-uitvoeringsverordening voor het centrale DPP-register. Het document maakt duidelijk hoe slank het centrale register is opgezet: het slaat slechts drie gegevenselementen per vermelding op:
| Veld | Beschrijving | Bijwerkverplichting |
|---|---|---|
| Unieke identificatiecode (UID) | Unieke identificatiecode voor het product/model | Onveranderlijk zodra toegewezen |
| Resolver-endpoint | URL waar het volledige DPP kan worden opgehaald | Bij te werken; vereist bij migratie |
| Goederencode | Code voor de productcategorie (bijv. GS- of GN-code) | Corrigeerbaar bij een foutieve vermelding |
De eigenlijke productgegevens — materiaalsamenstelling, repareerbaarheidsindex, CO2-voetafdruk — worden niet in het centrale register opgeslagen. Ze worden door de fabrikant of een gemachtigde databeheerder op het resolver-endpoint geleverd. Het register is gewoon het adresboek. Deze scheiding is architectonisch van belang: een update van de centrale vermelding is alleen nodig wanneer de UID, de resolver of de goederencode verandert. Het onderhoud van gegevens op inhoudsniveau gebeurt uitsluitend aan de kant van de gegevensaanbieder.
De productspecifieke gegevensvereisten — wat er precies in het DPP moet verschijnen — blijven het domein van sectorspecifieke regelgeving, zoals de gedelegeerde verordeningen onder ESPR of, voor batterijen, de Batterijverordening (EU) 2023/1542.
Wanneer een register-update verplicht is
Het resolver-endpoint is gewijzigd
Dit is het meest voorkomende scenario in de praktijk. Bedrijven wisselen van cloudprovider, migreren naar nieuwe DPP-platforms of consolideren domeinen. Zodra het vorige resolver-endpoint onbereikbaar wordt, kan geen enkele scanner — of dat nu een douaneautoriteit, een markttoezichthouder of een eindconsument is — het DPP nog ophalen. De verordening schrijft niet expliciet een reactietermijn voor, maar de 10-jarige beschikbaarheidsverplichting creëert in de praktijk nul tolerantie voor permanent gebroken links.
Aanbeveling: Gebruik een stabiele, bedrijfseigen subdomein-resolver (bijv. dpp.uwbedrijf.com) als indirectielaag. Zo hoeft u bij het wisselen van platform alleen intern te herconfigureren — zonder de registervermelding aan te raken. Dit volgt het principe van GS1 Digital Link, waarbij de QR-code verwijst naar een stabiele resolver die op zijn beurt doorverwijst naar wisselende backendsystemen.
Er is een onjuiste goederencode ingevoerd
Goederencodes (GN- of GS-codes) bepalen welke gedelegeerde verordeningen op een product van toepassing zijn. Een onjuiste code kan ertoe leiden dat het product in de verkeerde categorie wordt ingedeeld, of dat het verkeerd wordt geclassificeerd tijdens geautomatiseerde grenscontroles — die de EU vanaf 2028 wil invoeren in het kader van de voorgestelde Circular Economy Act. Correcties zijn onder de ontwerp-uitvoeringsverordening toegestaan, maar vereisen een gedocumenteerde rechtvaardiging.
Bedrijfsovername of licentieoverdracht
Wanneer een product van economische eigenaar verandert, moet u beoordelen of de resolver-verantwoordelijkheid mee wordt overgedragen. Het registeraccount is gekoppeld aan de oorspronkelijke registrant; een overdracht vereist een formele procedure via de bevoegde nationale autoriteit.
Technisch proces: een vermelding bijwerken
De uitvoeringsverordening voorziet in een API-gebaseerde interface naar het register. Het exacte endpoint wordt pas gepubliceerd zodra de verordening in werking treedt, maar de verwachte workflow kan uit het ontwerp worden afgeleid:
# Authentication via OAuth 2.0 Client Credentials
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X POST https://registry.dpp.ec.europa.eu/oauth/token \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_SECRET" \
-d "scope=registry:write"
# PATCH request to update the resolver endpoint
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X PATCH https://registry.dpp.ec.europa.eu/v1/entries/{uid} \
-H "Authorization: Bearer {ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/{uid}",
"updateReason": "platform_migration"
}'
Het veld updateReason wordt in het ontwerp aangemerkt als verplicht voor alle wijzigingen anders dan de initiële vermelding. Toegestane waarden zijn onder meer platform_migration, domain_change, commodity_code_correction en ownership_transfer. De auditgeschiedenis van alle updates wordt door het register gedurende de volledige periode van 10 jaar bewaard.
Bulk-updates voor grote productportfolio's
Bedrijven met duizenden SKU's kunnen individuele verzoeken niet handmatig beheren. De ontwerpverordening voorziet in een batch-endpoint:
{
"batchUpdate": [
{
"uid": "urn:epc:id:sgtin:0614141.107346.2017",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2017",
"updateReason": "platform_migration"
},
{
"uid": "urn:epc:id:sgtin:0614141.107346.2018",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2018",
"updateReason": "platform_migration"
}
]
}
Het opzetten en onderhouden van deze bulkprocessen vraagt om gestructureerd databeheer, zoals vereist door een bulk-importworkflow voor DPP-vermeldingen.
Internationale standaardisatie als stabiliteitsanker
Een updateproces is slechts zo robuust als de standaarden waarop het is gebouwd. Hier komt de oprichting van ISO/IEC JTC 5 om de hoek kijken: het nieuwe Joint Technical Committee, waarvan het secretariaat wordt gevoerd door het Duitse Instituut voor Normalisatie (DIN), heeft de taak om internationale standaarden te ontwikkelen voor de wereldwijde interoperabiliteit van DPP-systemen.
In praktische termen voor updateprocessen: zodra ISO/IEC JTC 5 standaarden voor gegevensformaten, API-schema's en identificatiecodestructuren aanneemt, worden deze naar verwachting verwerkt in toekomstige herzieningen van de ESPR-uitvoeringsverordeningen. Bedrijven die nu al vertrouwen op GS1-conforme identificatiecodes (GTIN, SGTIN) en GS1 Digital Link-resolvers, staan er goed voor: deze standaarden worden beschouwd als de referentie-implementatie voor JTC 5.
De WTO-notificatie van de EU-registerverordening (G/TBT/N/EU/1211) op 21 mei 2026 geeft eveneens aan dat het systeem wordt geclassificeerd als een technisch handelsvoorschrift — met gevolgen voor fabrikanten uit derde landen die producten naar de EU exporteren. Ook zij moeten registervermeldingen onderhouden en actueel houden.
Gegevensonderhoud als doorlopend proces: organisatorische implicaties
De 10-jarige verplichting is niet uitsluitend een IT-taak. Ze vereist organisatorische maatregelen:
- Verantwoordelijkheid documenteren: Wie binnen uw organisatie is verantwoordelijk voor de registervermeldingen? Deze rol moet ingevuld blijven, ook bij personeelsverloop en bedrijfsherstructureringen.
- Resolver-monitoring opzetten: Geautomatiseerde beschikbaarheidscontroles (HTTP-statuscontroles) voor alle actieve resolver-endpoints zijn geen nice-to-have — ze vormen een operationeel minimum.
- Een wijzigingslogboek bijhouden: De auditgeschiedenis in het register is toegankelijk voor autoriteiten. Vul deze aan met een intern wijzigingslogboek met rechtvaardigingen en goedkeuringen.
- Contracten met platformaanbieders herzien: Als u een externe DPP-dienstverlener gebruikt, moet het contract expliciet de 10-jarige beschikbaarheidsvereiste dekken — inclusief bepalingen voor insolventie of bedrijfsbeëindiging van de aanbieder.
Op 27 mei 2026 hield de Europese Commissie een webinar over de implementatie van het Battery DPP dat expliciet inging op de uitdagingen rond gegevensonderhoud waarmee kmo's worden geconfronteerd. De boodschap was duidelijk: langdurige gegevensbeschikbaarheid is geen technisch detail — het is een kernverplichting.
Conclusie
Een DPP-registervermelding is geen statisch document. De uitvoeringsverordening van april 2026 stelt een wettelijk kader vast dat fabrikanten verplicht om hun gegevens gedurende een decennium actief en aantoonbaar te onderhouden. Het goede nieuws: het centrale register is bewust slank gehouden. Als u resolver-endpoints ontwerpt op stabiliteit, GS1-conforme identificatiecodes gebruikt en wijzigingsprocessen in uw organisatie verankert, blijft de technische overhead voor updates beheersbaar — en bent u goed voorbereid op de aankomende ISO/IEC JTC 5-standaarden.
