DPP-Daten aktuell halten: So funktioniert das Update-Verfahren

Der Digitale Produktpass (DPP) ist kein statisches Dokument. Wer ihn einmal anlegt und dann vergisst, riskiert Compliance-Lücken – und das über einen langen Zeitraum: Die ESPR-Verordnung (EU) 2024/1781 schreibt vor, dass Registry-Einträge mindestens 10 Jahre nach dem letzten Inverkehrbringen eines Produkts verfügbar und aktuell bleiben müssen. Dieser Artikel erklärt, welche Datenebenen es gibt, wann welche aktualisiert werden müssen und wie Sie den Prozess technisch sauber abbilden.

Die drei Ebenen eines DPP – und wer sie pflegt

Ein vollständiger DPP besteht aus mindestens drei logisch getrennten Schichten, die unterschiedliche Update-Zyklen haben.

1. Registry-Eintrag (Identifier + Resolver)

Das zentrale DPP-Registry, dessen Implementing Regulation die Europäische Kommission am 29. April 2026 als Entwurf veröffentlichte, speichert laut Artikel 13 Abs. 1 der ESPR-Verordnung mindestens:

den Unique Identifier (UID) des Produkts – in der Praxis eine GS1 GTIN oder ein ISO/IEC 15459-konformer Code,
die eindeutige Kennung des Wirtschaftsakteurs sowie die eindeutige Kennung der Anlage,
den Resolver-Endpunkt, also die URL, unter der der eigentliche Passinhalt abgerufen werden kann,
den zugehörigen Warencode.

Diese Ebene ändert sich selten. Ein Update ist hier vor allem dann nötig, wenn sich der Resolver-Endpunkt ändert – etwa weil ein Unternehmen seinen DPP-Dienstleister wechselt oder eine Domain migriert. Da der QR-Code auf dem physischen Produkt auf diesen Eintrag zeigt, muss die Kontinuität des Resolvers lückenlos gewährleistet sein.

2. Resolver-Konfiguration (Link-Routing)

Der Resolver übersetzt einen eingehenden Scan in die passende Ziel-URL – abhängig von Kontext, Sprache oder Nutzerrolle. Wer GS1 Digital Link einsetzt, kann über strukturierte Link-Typen (z. B. gs1:sustainabilityInfo, gs1:epcis) gezielt auf verschiedene Datensätze routen.

Updates auf dieser Ebene sind nötig, wenn:

neue Pflichtfelder durch delegierte Rechtsakte hinzukommen (z. B. die ab 2026/2027 erwarteten Textile- und Batterie-Verordnungen),
Ziel-URLs sich ändern,
neue Sprachversionen oder Marktregionen hinzugefügt werden.

3. Produktdaten (der eigentliche Passinhalt)

Hier liegen die eigentlichen Inhalte: Materialzusammensetzung, Reparierbarkeitsindex, Carbon Footprint, Gefahrstoffangaben, Garantieinformationen. Diese Ebene hat den höchsten Update-Bedarf, weil sie von realen Ereignissen im Produktlebenszyklus abhängt.

Wann müssen DPP-Daten aktualisiert werden?

Die ESPR-Verordnung nennt keine festen Update-Intervalle. Stattdessen gilt das Prinzip der Datenaktualität: Informationen müssen den tatsächlichen Zustand des Produkts widerspiegeln. Daraus ergeben sich mehrere praxisrelevante Auslöser:

Regulatorische Änderungen

Sobald ein delegierter Rechtsakt neue Datenpflichten einführt, müssen bestehende Pässe nachgepflegt werden. Das ist keine theoretische Zukunftsfrage: Die ersten produktspezifischen Verordnungen für Textilien und Batterien sollen laut ESPR-Zeitplan in 2026 und 2027 wirksam werden.

Konkret bedeutet das für Batteriehersteller: Ab August 2026 müssen alle in der EU verkauften Batterien sichtbare QR-Codes und Kennzeichnungen zu Kapazität, Chemie und Gefahrstoffen tragen – als Vorstufe zum vollständigen Batteriepass, der 2027 Pflicht wird. Das EU Battery Regulation-Update ist damit einer der ersten realen Massentests für das DPP-Update-Verfahren.

Produktänderungen

Ändert sich die Materialzusammensetzung eines Produkts – auch bei gleichbleibender GTIN –, muss der DPP aktualisiert werden. Das gilt ebenso für:

neue Reparaturanleitungen oder Ersatzteilquellen,
geänderte Garantiebedingungen,
aktualisierte Sicherheitsdatenblätter.

Rückruf- oder Warnhinweise

Sicherheitsrelevante Informationen müssen zeitnah eingetragen werden. Der DPP ist hier kein Ersatz für das RAPEX-Schnellwarnsystem, aber ein komplementärer Kanal, der von Verbrauchern und Aufsichtsbehörden gleichermaßen genutzt werden kann.

Technisches Update-Verfahren: Schritt für Schritt

Schritt 1: Identifier und Versionierung klären

Jede Änderung am Passinhalt sollte versioniert werden. Empfehlenswert ist eine Kombination aus:

Produkt-UID (unveränderlich, z. B. GTIN + Seriennummer),
Passversion (semantische Versionsnummer oder Zeitstempel),
Änderungsgrund (regulatorisch, produktbezogen, korrektiv).

{
  "uid": "urn:epc:id:sgtin:4012345.067890.1234567",
  "passVersion": "2.1.0",
  "lastModified": "2026-05-19T10:00:00Z",
  "changeReason": "battery-regulation-aug2026"
}

Schritt 2: Nur die betroffene Datenschicht ändern

Ein häufiger Fehler ist es, bei regulatorischen Updates den gesamten Passdatensatz neu zu schreiben. Das erhöht das Fehlerrisiko und erschwert die Nachvollziehbarkeit. Besser: modulare Datenstruktur, bei der einzelne Datenfelder unabhängig aktualisiert werden können.

Wer über eine API arbeitet, sollte HTTP PATCH statt PUT verwenden:

PATCH /api/v1/dpp/{uid}/sections/battery
Content-Type: application/json

{
  "capacityWh": 42.5,
  "chemistry": "LFP",
  "hazardousSubstances": ["Li", "P"],
  "carbonFootprintKgCO2e": 18.3
}

Schritt 3: Resolver-Verfügbarkeit sicherstellen

Ein Update, das den Resolver vorübergehend offline nimmt, ist aus Compliance-Sicht kritisch. Die 10-Jahres-Verfügbarkeitspflicht der ESPR duldet keine Ausfallzeiten ohne Fallback. Empfohlen wird:

Blue-Green-Deployment für Resolver-Updates,
Monitoring des Resolver-Endpunkts mit Alerting bei HTTP-Fehlercodes ≥ 400,
regelmäßige Überprüfung, dass der im Registry eingetragene Endpunkt tatsächlich erreichbar ist.

Schritt 4: Bulk-Updates für große Produktportfolios

Wer hunderte oder tausende Produkte verwaltet, kommt an einem strukturierten Bulk-Import-Prozess nicht vorbei. Dabei gilt: Änderungen sollten als differenzielle Updates (Delta-Import) und nicht als Vollimporte verarbeitet werden, um Fehlerquellen zu minimieren und Audit-Trails zu erhalten.

Ein typisches CSV-Format für ein Delta-Update könnte so aussehen:

uid,field,newValue,effectiveDate,changeReason
urn:epc:...:001,capacityWh,42.5,2026-08-18,battery-reg-2026
urn:epc:...:002,chemistry,NMC,2026-08-18,battery-reg-2026

Besonderheiten bei Textilien und der Fair-Trade-Debatte

Für Textilhersteller bringt der ESPR-Zeitplan besondere Herausforderungen. Zivilgesellschaftliche Akteure wie die Fair-Trade-Bewegung haben in ihren Empfehlungen zum delegierten Rechtsakt für Textilien gefordert, dass die Datenarchitektur des DPP auch für KMU und Kleinbauern in Drittländern handhabbar sein muss. Das hat direkte Auswirkungen auf das Update-Verfahren: Wenn Lieferkettendaten von Akteuren stammen, die keinen direkten API-Zugang haben, braucht es robuste manuelle oder semi-automatisierte Eingabewege.

Hier zeigt sich, dass das Update-Verfahren nicht nur eine technische, sondern auch eine organisatorische Frage ist: Wer darf welche Daten ändern? Wer validiert Änderungen? Wie werden Lieferanten in den Prozess eingebunden?

GS1 Digital Link als Update-Enabler

Die GS1 General Assembly 2026 in Warschau konzentriert sich auf die globale Transition zu 2D-Barcodes und unterstreicht: GS1 Digital Link ist der bevorzugte Mechanismus, um Produktidentitäten mit aktuellen Inhalten zu verknüpfen. Der entscheidende Vorteil für das Update-Verfahren: Der QR-Code auf dem Produkt bleibt unverändert – nur der Inhalt hinter dem Resolver ändert sich. Das macht nachträgliche Aktualisierungen physisch bereits verkaufter Produkte überhaupt erst möglich.

Mit dem Sunrise-2027-Deadline für 2D-Barcodes im Einzelhandel nähert sich der Zeitpunkt, ab dem Marken GS1 Digital Link QR-Codes nicht mehr aufschieben können – sowohl für Retail-Compliance als auch für DPP-Anforderungen.

Fazit: Update-Fähigkeit ist kein Feature, sondern Pflicht

Die ESPR-Verordnung behandelt den DPP als lebendes Dokument. Wer heute eine Implementierung plant, muss Update-Prozesse von Anfang an mitdenken: versionierte Datenstrukturen, modulare APIs, stabile Resolver und klare Governance-Regeln für Datenänderungen. Die ersten Pflichttermine – Batterien ab August 2026, Textilien voraussichtlich 2027 – sind nah genug, um jetzt mit der technischen Vorbereitung zu beginnen.