Cybervize

Roadmap Produkthaftung für den CISO: was bis zum 9. Dezember 2026 vorzubereiten ist

Produkthaftung (PLD)CISOProduct Security LeadHead of EngineeringLegal und ComplianceGeschäftsführung

Kernaussage

Das neue EU-Produkthaftungsregime (Richtlinie (EU) 2024/2853) erfasst Produkte, die ab dem 9. Dezember 2026 in Verkehr gebracht oder in Betrieb genommen werden; maßgeblich ist Art. 2 Abs. 1 in der Fassung der Berichtigung (ABl. L, 2026/90364 vom 07.05.2026, Wortlaut "nach dem 8. Dezember 2026"). Dieser Anker hängt an der Richtlinie, nicht am deutschen Gesetzgebungsverfahren: Die Umsetzungsfrist der Mitgliedstaaten läuft am 09.12.2026 ab (Art. 22 Abs. 1), und der deutsche Entwurf sieht sein Inkrafttreten für genau diesen Tag vor; verkündet war er am 03.08.2026 nicht. Wer ab dem Stichtag ausliefert, muss mit dem neuen Regime planen: verschuldensunabhängige Haftung für Software als Produkt, Offenlegung interner Dokumentation, Beweisvermutungen, Fristen von 3, 10 und 25 Jahren, keine Haftungsobergrenzen und keine Bagatellschwelle.

Für das Management: Das ist kein Projekt der Rechtsabteilung. Beweisfähigkeit, haftungsfeste Update-Prozesse und Lieferkettenklarheit entstehen im Engineering und in der Security-Organisation, und sie brauchen Vorlauf. Die Zeit bis zum Stichtag ist die Gelegenheit, sie geordnet aufzubauen statt im ersten Schadensfall zu improvisieren.

Auf dieser Seite
  1. Problem in der Praxis
  2. CISO-Einordnung
  3. Umsetzungsperspektive
  4. Typische Fehler
  5. Risiken und Trade-offs
  6. Entscheidungspunkte
  7. Praktische Empfehlungen
  8. Relevante Normreferenzen

Problem in der Praxis

Drei Muster wiederholen sich. Erstens das Warten auf das deutsche Gesetz: Solange nichts verkündet sei, könne man nichts tun. Das verwechselt den Rechtsstand mit der Handlungsgrundlage; der Anwendungsstichtag steht auf Richtlinienebene fest, und die aufzubauenden Fähigkeiten (Inventar, Dokumentation, Prozesse) sind vom Wortlaut des deutschen Gesetzes weitgehend unabhängig. Zweitens die Delegation an Legal, während die künftigen Beweismittel im Engineering entstehen und dort niemand von ihrer Haftungsrelevanz weiß. Drittens ein zu enger Scope: "Wir stellen keine Geräte her." Aber Software ist Produkt, verbundene Dienste sind Komponenten, und wer als Importeur oder Bevollmächtigter agiert oder ein Produkt wesentlich verändert, rückt selbst in die Haftung ein.

Dazu kommt das Doppelregime: Für Produkte, die vor dem Stichtag in Verkehr gebracht oder in Betrieb genommen wurden, gilt das alte Recht weiter (Art. 21). Organisationen betreiben also über Jahre zwei Haftungsregime parallel und müssen je Produkt wissen, welches gilt. Maßgeblich ist der Zeitpunkt des Inverkehrbringens beziehungsweise der Inbetriebnahme, nicht der Schadenszeitpunkt.

CISO-Einordnung

Das verifizierte Zeitgerüst, an dem die Roadmap hängt:

  • In Kraft seit 08.12.2024 (Art. 23; Veröffentlichung im Amtsblatt am 18.11.2024).
  • Umsetzungsfrist bis 09.12.2026 (Art. 22 Abs. 1).
  • Anwendung auf Produkte, die ab dem 09.12.2026 in Verkehr gebracht oder in Betrieb genommen werden. Die Fundstelle präzise: Art. 2 Abs. 1 lautet in der berichtigten Fassung "nach dem 8. Dezember 2026" (Berichtigung ABl. L, 2026/90364 vom 07.05.2026); die ursprüngliche Amtsblattfassung nannte den 9. Dezember. Eine konsolidierte Fassung mit eingearbeiteter Berichtigung gab es auf EUR-Lex am 03.08.2026 nicht; wer den Text abruft, muss die Berichtigung von Hand anwenden.
  • Altregime läuft weiter: Die Richtlinie 85/374/EWG wird zum 09.12.2026 aufgehoben, gilt für davor in Verkehr gebrachte oder in Betrieb genommene Produkte aber fort (Art. 21, Erwägungsgrund 63).
  • Deutscher Stand (03.08.2026): kein verkündetes Umsetzungsgesetz. Der Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (BT-Drs. 21/4297 vom 25.02.2026) war im Ausschussstadium; 1. Lesung am 04.03.2026, öffentliche Anhörung im Rechtsausschuss am 13.04.2026, spätere Verfahrensschritte waren an den abgerufenen amtlichen Quellen nicht feststellbar. Der Entwurf sieht ein neues Produkthaftungsgesetz mit Inkrafttreten am 09.12.2026 vor und eine Übergangsvorschrift, nach der für bis einschließlich 08.12.2026 in Verkehr gebrachte Produkte das bisherige Recht anwendbar bleibt. Bis zur Verkündung gilt das Produkthaftungsgesetz von 1989 unverändert fort; jede Aussage zum künftigen deutschen Recht ist Entwurfsstand und so zu kennzeichnen.
  • Wesentliche Änderung als Regimewechsler: Ein wesentlich verändertes Produkt gilt als neues Produkt; erfolgt die Änderung etwa durch Software-Update oder kontinuierliches Lernen, kann ein Altprodukt in das neue Regime hineinwachsen, und die Ausschlussfrist läuft ab der erneuten Bereitstellung neu (Erwägungsgrund 40, Art. 17 Abs. 1 Buchst. b; vertieft in pld-003).

Die Roadmap dahinter besteht aus sechs Arbeitspaketen, die aufeinander aufbauen und strikt haftungsbezogen bleiben; die Konformitätsarbeit nach CRA und Maschinenverordnung haben eigene Roadmaps (cra-008, mvo-008).

Umsetzungsperspektive

Arbeitspaket 1: Inventar und Betroffenheit (sofort). Produkt- und Softwareportfolio am neuen Produktbegriff spiegeln: Software ist Produkt, ebenso digitale Konstruktionsunterlagen; verbundene Dienste sind Komponenten; kommerziell bereitgestellte freie und quelloffene Software bleibt erfasst, FOSS außerhalb einer Geschäftstätigkeit nicht (Begriffe vertieft in pld-001). Je Produkt die eigene Rolle in der Haftungskaskade des Art. 8 klären: Hersteller, Hersteller einer Komponente, Importeur, Bevollmächtigter, Fulfilment-Dienstleister oder Lieferant mit Auffanghaftung. Grenzfälle (etwa die Abgrenzung zwischen Software als Produkt, verbundenem Dienst als Komponente und bloßem Dienst; reine Inhalte und reiner Quellcode sind nach Erwägungsgrund 13 kein Produkt) nicht per Bauchgefühl entscheiden, sondern als dokumentierte Einordnungsfragen mit Legal führen und ihre Behandlung im weiteren deutschen Gesetzgebungsverfahren beobachten (Produktbegriff vertieft in pld-001). Ergebnis: ein Produktregister mit Regime- und Rollenzuordnung.

Arbeitspaket 2: Chronologie des Inverkehrbringens. Weil das anwendbare Regime und die 10-Jahres-Ausschlussfrist am Inverkehrbringen beziehungsweise der Inbetriebnahme hängen, muss je Produkt belegbar sein, wann es in Verkehr gebracht wurde, und bei wesentlichen Änderungen, wann es erneut bereitgestellt wurde. Diese Marker gehören in Release- und Change-Governance, nicht in nachträgliche Rekonstruktion.

Arbeitspaket 3: Update- und Schwachstellenprozesse haftungsfest machen. Der Einwand, der Fehler sei erst nach dem Inverkehrbringen entstanden, trägt nicht, wenn die Ursache ein verbundener Dienst, Software einschließlich Updates oder das Fehlen sicherheitserhaltender Updates ist, sofern das der Kontrolle des Herstellers unterliegt (Art. 11 Abs. 2). Also klären, für welche Produkte die Organisation Updates bereitstellen kann (Kontrolle im Sinne des Art. 4 Nr. 5), und Entscheidungen über Bereitstellung oder Nichtbereitstellung sicherheitserhaltender Updates als dokumentierte Risikoentscheidungen führen (vertieft in pld-003; die Pflichtenseite der Update-Bereitstellung kommt aus dem Produktsicherheitsrecht, im Korpus der cra-Track).

Arbeitspaket 4: Beweisfähigkeit und Dokumentation. Dokumentation zu Schwachstellenbehandlung, Updateentscheidungen und Produktbeobachtung so führen, dass sie einer gerichtlichen Offenlegung nach Art. 9 standhält und die Vermutungen des Art. 10 widerlegen kann; Aufbewahrung am 10-Jahres-Horizont ausrichten, bei Produkten mit Körperschadenspotenzial am 25-Jahres-Horizont; Geschäftsgeheimnisse vorab klassifizieren (vertieft in pld-004).

Arbeitspaket 5: Lieferkette und Verträge. Komponenten- und Softwarezulieferer erfassen; Hersteller fehlerhafter Komponenten haften selbst (Art. 8 Abs. 1), mehrere Haftende haften gesamtschuldnerisch mit Rückgriff untereinander (Art. 12, Art. 14). Den Sonderfall kennen: Gegen Kleinst- und Kleinunternehmen der Softwarebranche kann der Rückgriff unter den Voraussetzungen des Art. 12 Abs. 2 vertraglich ausgeschlossen sein, was Zuliefererauswahl und Absicherung beeinflusst. Bei Herstellern außerhalb der EU die eigene Rolle als Importeur oder Bevollmächtigter erkennen. Die vertragliche Gestaltung selbst ist Anwaltsarbeit und nicht Teil dieses Artikels.

Arbeitspaket 6: Finanzvorsorge und Rechtsstandsbeobachtung. Die Haftung ist gegenüber Geschädigten nicht abdingbar, ohne finanzielle Obergrenze und ohne Bagatellschwelle (Art. 15, Erwägungsgrund 56); ersatzfähig ist auch die Vernichtung oder Beschädigung nicht beruflich genutzter Daten (Art. 6 Abs. 1 Buchst. c); anspruchsberechtigt sind natürliche Personen, auch über Verbandsklagen (Art. 5). Versicherungsdeckung und Rückstellungen mit Versicherer und Legal auf diese Parameter prüfen. Parallel den Rechtsstand beobachten: das deutsche Verfahren (DIP-Vorgang zum Entwurf, Bundesgesetzblatt) und EUR-Lex (künftige konsolidierte Fassung, etwaige weitere Berichtigungen); jede interne Unterlage mit Standsdatum führen.

Typische Fehler

  1. Auf die Verkündung des deutschen Gesetzes warten, obwohl Stichtag und Fähigkeitenaufbau davon unabhängig sind.
  2. Den Produktbegriff zu eng ziehen (nur Hardware) und Software, digitale Konstruktionsunterlagen und verbundene Dienste übersehen.
  3. Keine belegbare Chronologie des Inverkehrbringens, sodass später nicht nachweisbar ist, welches Regime und welcher Fristlauf für welches Produkt gilt.
  4. Wesentliche Änderungen releasen, ohne Regimewechsel und Fristneustart zu prüfen.
  5. Die Haftungs-Roadmap mit den Konformitätsprogrammen zu CRA und Maschinenverordnung verschmelzen, bis Haftungslücken unsichtbar werden; verzahnen ja, vermengen nein.
  6. Versicherungsschutz unverändert lassen, obwohl Obergrenzen und Bagatellschwelle entfallen und Datenverlust als Schadensart hinzukommt.
  7. Interne Aussagen wie "das neue deutsche Produkthaftungsgesetz gilt" ohne Standsdatum; bis zur Verkündung gilt das Produkthaftungsgesetz von 1989 fort.

Risiken und Trade-offs

Der erste Trade-off ist Entwurfsunsicherheit gegen Vorlauf. Der deutsche Entwurf kann sich im Verfahren noch ändern; wer Detailregelungen des Entwurfs in Prozesse gießt, plant auf Sand. Robust ist, was aus der Richtlinie selbst folgt, zumal sie als Vollharmonisierung wenig nationalen Spielraum lässt (Art. 3); Entwurfsdetails gehören als solche gekennzeichnet und beobachtet.

Der zweite ist Aufwand gegen Reichweite. Nicht jedes Produkt rechtfertigt denselben Beweis- und Dokumentationsaufwand. Priorisieren lässt sich nach Schadenspotenzial (Körperschäden ziehen den 25-Jahres-Horizont nach sich), Verbreitung und Update-Abhängigkeit; die Priorisierung selbst gehört dokumentiert, damit sie nicht als Nachlässigkeit gelesen wird.

Der dritte ist die Doppelregime-Komplexität. Alt- und Neuprodukte laufen parallel, und eine wesentliche Änderung kann das Regime wechseln. Das spricht für einfache, automatisierte Marker in Release- und Bestandsprozessen statt juristischer Einzelfallprüfung bei jedem Release.

Entscheidungspunkte

  • Welche unserer Produkte, Softwarestände und Dienste fallen ab dem 09.12.2026 unter das neue Regime, und in welcher Rolle der Kaskade des Art. 8 handeln wir jeweils?
  • Können wir je Produkt belegen, wann es in Verkehr gebracht oder nach wesentlicher Änderung erneut bereitgestellt wurde?
  • Für welche Produkte behalten wir die Kontrolle im Sinne des Art. 4 Nr. 5, und sind Update-Entscheidungen dort als dokumentierte Risikoentscheidungen geführt?
  • Hält unsere Dokumentation einer Offenlegung nach Art. 9 stand, und deckt die Aufbewahrung die 10- und gegebenenfalls 25-Jahres-Frist ab?
  • Wie sichern wir Rückgriff und Risikoteilung in der Lieferkette, einschließlich des Sonderfalls kleiner Softwarezulieferer nach Art. 12 Abs. 2?
  • Reichen Versicherungsdeckung und Rückstellungen für eine Haftung ohne Obergrenze und ohne Bagatellschwelle?
  • Wer beobachtet das deutsche Gesetzgebungsverfahren und die EUR-Lex-Fassungslage und hält die Standsangaben aktuell?

Praktische Empfehlungen

  1. Starten Sie sofort mit dem Produktregister: Produktbegriff-Mapping, Rollenzuordnung nach Art. 8, Regimezuordnung alt oder neu je Produkt.
  2. Verankern Sie Inverkehrbringungs- und Änderungsmarker fest in Release- und Change-Prozessen, damit Regime und Fristlauf später belegbar sind.
  3. Machen Sie Update-Entscheidungen zu dokumentierten Risikoentscheidungen mit Datum, Verantwortlichem und Begründung, insbesondere Entscheidungen gegen ein Update.
  4. Bauen Sie Beweisfähigkeit als eigenes Arbeitspaket auf (vertieft in pld-004) und verzahnen Sie es mit der Konformitätsdokumentation, ohne die Programme zu vermengen (Abgrenzung in pld-005).
  5. Führen Sie Lieferketten-, Vertrags- und Versicherungsgespräche vor dem Stichtag, nicht nach dem ersten Schadensfall.
  6. Halten Sie den Rechtsstand mit Datum fest: deutsches Verfahren als Entwurfsstand kennzeichnen, EUR-Lex-Zitate bis zum Erscheinen einer konsolidierten Fassung stets mit der Berichtigung vom 07.05.2026 abgleichen.

Relevante Normreferenzen

  • Richtlinie (EU) 2024/2853 (neue Produkthaftungsrichtlinie), ABl. L, 2024/2853, 18.11.2024, berichtigt durch Berichtigung ABl. L, 2026/90364 vom 07.05.2026 (Art. 2 Abs. 1: "nach dem 8. Dezember 2026"): zeitlicher Anwendungsbereich (Art. 2 Abs. 1), Haftungskaskade (Art. 8), Nachmarkthaftung (Art. 4 Nr. 5, Art. 11 Abs. 2), Offenlegung und Vermutungen (Art. 9, 10), Gesamtschuld und Rückgriff (Art. 12, 14), Haftungsgrenzenverbot (Art. 15), Fristen (Art. 16, 17), Übergangsregel (Art. 21), Umsetzungsfrist (Art. 22). Eine konsolidierte Fassung mit eingearbeiteter Berichtigung lag am 03.08.2026 auf EUR-Lex nicht vor.
  • Richtlinie 85/374/EWG: bisheriges Produkthaftungsrecht; gilt für vor dem Stichtag in Verkehr gebrachte oder in Betrieb genommene Produkte weiter (Art. 21 der RL (EU) 2024/2853).
  • Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (BT-Drs. 21/4297 vom 25.02.2026): deutscher Umsetzungsentwurf; am 03.08.2026 nicht verkündet, letzter an den abgerufenen Quellen belegter Verfahrensschritt war die Anhörung im Rechtsausschuss am 13.04.2026. Aussagen daraus sind Entwurfsstand.
  • Produkthaftungsgesetz von 1989: geltendes deutsches Recht bis zur Verkündung eines Umsetzungsgesetzes.

Häufige Fragen

Warum ist der 9. Dezember 2026 der Anker der Roadmap?+

Weil die Richtlinie ab diesem Tag in Verkehr gebrachte oder in Betrieb genommene Produkte erfasst (Art. 2 Abs. 1 in der Fassung der Berichtigung vom 07.05.2026, Wortlaut "nach dem 8. Dezember 2026") und die Umsetzungsfrist der Mitgliedstaaten am 09.12.2026 abläuft (Art. 22 Abs. 1). Der deutsche Entwurf sieht sein Inkrafttreten für denselben Tag vor.

Sollten wir warten, bis das deutsche Umsetzungsgesetz verkündet ist?+

Nein. Der Stichtag steht auf Richtlinienebene fest, und die aufzubauenden Fähigkeiten (Inventar, Chronologie, Dokumentation, Update-Governance, Lieferkette, Versicherung) sind vom endgültigen Gesetzeswortlaut weitgehend unabhängig. Der Verfahrensstand (am 03.08.2026: Entwurf im Ausschussstadium, nicht verkündet) gehört beobachtet, nicht abgewartet.

Was ist der erste Schritt?+

Ein Produktregister: Produkt- und Softwareportfolio am neuen Produktbegriff spiegeln (Software, digitale Konstruktionsunterlagen, verbundene Dienste), Rolle je Produkt in der Haftungskaskade des Art. 8 klären, Regimezuordnung alt oder neu festhalten.

Was gilt für Produkte, die vor dem Stichtag auf dem Markt sind?+

Für sie gilt das bisherige Recht weiter (Art. 21). Eine wesentliche Änderung, etwa durch ein Software-Update, kann ein Altprodukt aber als neues Produkt in das neue Regime bringen und lässt die Ausschlussfrist neu laufen (Erwägungsgrund 40, Art. 17 Abs. 1 Buchst. b).

Warum betrifft die Produkthaftung die Versicherungsstrategie?+

Weil die Haftung gegenüber Geschädigten nicht abdingbar ist, keine finanzielle Obergrenze und keine Bagatellschwelle kennt (Art. 15, Erwägungsgrund 56) und mit der Vernichtung oder Beschädigung nicht beruflich genutzter Daten eine für Security-Vorfälle relevante Schadensart hinzukommt (Art. 6 Abs. 1 Buchst. c). Deckungssummen und Rückstellungen gehören darauf geprüft.

Ersetzt diese Roadmap die CRA- oder Maschinenverordnungs-Roadmap?+

Nein. Diese Roadmap bleibt strikt haftungsbezogen. Die Konformitätsarbeit für den Marktzugang haben eigene Roadmaps im cra-Track (cra-008) und mvo-Track (mvo-008); das Verhältnis der Rechtsschichten erklärt pld-005.

Vom Wissen zur Umsetzung

Sie wissen jetzt, was gefordert ist. Kleiner wird Ihr Risiko erst, wenn Sie sehen, wo Ihre Lücken sitzen. Die Cybervize-Plattform macht sie sichtbar, priorisiert die Maßnahmen dagegen und führt den laufenden Sicherheitsbetrieb mit Aufgaben und Vorfällen. Richtlinien und Nachweise entstehen dabei, die Compliance ist damit miterledigt.

Standort bestimmen

Fünf Stationen von der ersten Einordnung bis zum Audit, der Einstieg ist kostenlos.

Sie haben niemanden, der das führt? Die CISO-Funktion gibt es ab 3.600 €/Monat, die Plattform ist darin enthalten. vCISO ansehen

Verwandte Artikel

Teil der Cybervize-Wissensbasis, Stand 8. August 2026. Referenz: pld-006.