Offenlegung und Beweislast: was Geschädigte erleichtert bekommen und was Hersteller vorhalten müssen

Problem in der Praxis

In Haftungsprozessen zu Software ist die Informationslage strukturell asymmetrisch: Die geschädigte Person sieht nur das Schadensereignis, der Hersteller besitzt Architektur, Telemetrie, Bugtracker und Entscheidungshistorie. Genau diese Asymmetrie adressiert die Richtlinie mit dem Zusammenspiel aus Offenlegungspflicht und Vermutungen. Der Hersteller kann sich nicht mehr darauf verlassen, dass die Gegenseite seine Interna nie zu sehen bekommt.

Im Unternehmen zeigt sich das Problem an drei typischen Befunden. Erstens sind Updateentscheidungen (was wird gepatcht, was nicht, und warum) nirgends zusammenhängend nachvollziehbar, sondern verteilt auf Tickets, Chats und Flurgespräche. Zweitens existieren Risikoabwägungen nur als gelebte Praxis, nicht als datierte, begründete Entscheidung. Drittens fehlt eine Regel, welche Unterlagen wie lange aufbewahrt werden; nach einem Toolwechsel oder einer Reorganisation ist die Historie weg.

Im Offenlegungsfall entsteht daraus doppelter Schaden: Wer einer gerichtlichen Anordnung nicht nachkommen kann, riskiert die Vermutung der Fehlerhaftigkeit. Und was zwar existiert, aber lückenhaft oder widersprüchlich geführt ist, taugt nicht zur Widerlegung der Vermutungen und kann im Zweifel gegen den Hersteller sprechen.

CISO-Einordnung

Offenlegung von Beweismitteln (Art. 9). Stützt die klagende Person die Plausibilität ihres Anspruchs mit Tatsachen und Beweismitteln ausreichend, kann das Gericht den Beklagten verpflichten, relevante Beweismittel in seiner Verfügungsgewalt offenzulegen (Abs. 1). Spiegelbildlich kann auch der Beklagte Offenlegung durch die klagende Seite verlangen (Abs. 2). Die Offenlegung ist auf das Erforderliche und Verhältnismäßige beschränkt (Abs. 3), und vertrauliche Informationen sowie Geschäftsgeheimnisse genießen Schutzmechanismen (Abs. 4 und 5); der Begriff des Geschäftsgeheimnisses ist über Art. 4 Nr. 17 an die Richtlinie (EU) 2016/943 angebunden. Eine vorherige unternehmensinterne Klassifizierung verlangt die Richtlinie dafür nicht; das Gericht wird auf hinreichend begründeten Antrag einer Partei oder von Amts wegen tätig (Abs. 5) und berücksichtigt dabei die berechtigten Interessen aller beteiligten Parteien (Abs. 4). Praktisch trägt ein solcher Antrag aber nur, wenn die Organisation kurzfristig benennen kann, welche Unterlagen schutzwürdig sind, und das begründen kann.

Beweislast und Vermutungen (Art. 10). Die Grundregel bleibt beim Kläger: Er beweist Fehlerhaftigkeit, Schaden und Ursachenzusammenhang (Abs. 1). Darauf setzen drei Vermutungen der Fehlerhaftigkeit (Abs. 2): erstens, wenn der Beklagte einer gerichtlichen Offenlegungspflicht nach Art. 9 Abs. 1 nicht nachkommt; zweitens, wenn der Kläger nachweist, dass das Produkt verbindlichen Produktsicherheitsanforderungen des Unions- oder nationalen Rechts nicht entspricht, die gerade vor dem Risiko des eingetretenen Schadens schützen sollen; drittens, wenn der Schaden durch eine offensichtliche Funktionsstörung bei vernünftigerweise vorhersehbarem Gebrauch verursacht wurde. Hinzu kommen die Kausalitätsvermutung, wenn die Fehlerhaftigkeit feststeht und der Schaden seiner Art nach typischerweise auf den Fehler zurückzuführen ist (Abs. 3), und eine Erleichterung, wenn der Kläger trotz der Offenlegung von Beweismitteln nach Art. 9 wegen technischer oder wissenschaftlicher Komplexität übermäßige Schwierigkeiten hat; dann genügt die Darlegung von Wahrscheinlichkeit (Abs. 4). Alle Vermutungen sind widerleglich (Abs. 5, Erwägungsgrund 48).

Für Security-Verantwortliche ist die zweite Vermutung die wichtigste Brücke: Über sie können Verstöße gegen verbindliche Cybersicherheitsanforderungen des Produktrechts (etwa aus dem Cyber Resilience Act, Grundzüge im cra-Track) die Fehlerhaftigkeitsvermutung auslösen. Die Richtlinie definiert dabei selbst keine Sicherheitsanforderungen; sie knüpft an anderweitig vorgeschriebene an (Art. 7 Abs. 2 Buchst. f; das Verhältnis zu CRA, Maschinenverordnung und AI Act vertieft pld-005, den Fehlerbegriff pld-002).

Die Fristen (Art. 16 und 17), sauber auseinandergehalten. Es laufen zwei verschiedene Uhren mit unterschiedlichen Startpunkten:

• Verjährung, 3 Jahre (Art. 16): läuft ab dem Zeitpunkt, zu dem die geschädigte Person von Schaden, Fehlerhaftigkeit und Identität des haftbaren Wirtschaftsakteurs Kenntnis hatte oder vernünftigerweise hätte haben müssen. Eine personenbezogene, kenntnisabhängige Frist; nationale Regeln zu Hemmung und Unterbrechung bleiben unberührt.
• Ausschlussfrist, 10 Jahre (Art. 17 Abs. 1): beginnt mit dem Inverkehrbringen oder der Inbetriebnahme des Produkts, bei einem wesentlich veränderten Produkt mit dessen erneuter Bereitstellung (Buchst. b). Eine produktbezogene Frist, die unabhängig von der Kenntnis der geschädigten Person läuft, aber mit einem Vorbehalt: Nach ihrem Ablauf scheidet eine Haftung nach der Richtlinie aus, es sei denn, die geschädigte Person hat vor Fristablauf ein Verfahren gegen einen Wirtschaftsakteur eingeleitet, der nach Art. 8 haftbar gemacht werden kann. Ein rechtzeitig eingeleitetes Verfahren erhält den Anspruch also über den Fristablauf hinaus.
• Verlängerte Ausschlussfrist, 25 Jahre (Art. 17 Abs. 2): gilt für den Sonderfall, dass sich eine Körperverletzung erst mit Latenz zeigt. Das ist keine dritte, eigenständige Uhr, sondern die verlängerte Laufzeit der produktbezogenen Ausschlussfrist für latente Gesundheitsschäden; der Vorbehalt des rechtzeitig eingeleiteten Verfahrens gilt für sie genauso.

Praktisch übersetzt: Die 3-Jahres-Frist bestimmt, wie lange nach einem konkreten Schadensereignis noch mit einer Klage zu rechnen ist; sie startet spät, nämlich erst mit der tatsächlichen oder zumutbaren Kenntnis von Schaden, Fehlerhaftigkeit und der Identität des haftbaren Wirtschaftsakteurs; die Kenntnis des Schadensereignisses allein setzt sie nicht in Gang (Art. 16 Abs. 1). Die 10- und 25-Jahres-Fristen bestimmen, wie lange ein Anspruch nach der Richtlinie noch bestehen kann; eine Pflicht, Produktdokumentation so lange aufzubewahren, ordnet die Richtlinie nicht an. Sie sind aber der sachgerechte Maßstab für die eigene Entscheidung, wie lange je Produkt Dokumentation vorgehalten und verteidigungsfähig gehalten wird. Und für ein wesentlich verändertes Produkt beginnt die Zehnjahresfrist mit dem Datum neu, an dem dieses Produkt nach seiner wesentlichen Änderung auf dem Markt bereitgestellt oder in Betrieb genommen wurde (Art. 17 Abs. 1 Buchst. b); wer dafür als Hersteller einzustehen hat, richtet sich nach Art. 8, wobei als Hersteller auch gilt, wer ein Produkt außerhalb der Kontrolle des Herstellers wesentlich verändert und es anschließend bereitstellt oder in Betrieb nimmt (Art. 8 Abs. 2). Beides gehört in jede Release-Entscheidung (vertieft in pld-003).

Keine Deckelung, keine Bagatellgrenze. Art. 15 verbietet, die Haftung gegenüber Geschädigten durch Vertrag oder nationales Recht auszuschließen oder zu beschränken; Erwägungsgrund 56 nennt ausdrücklich das Verbot finanzieller Obergrenzen. Eine Bagatellschwelle wie die Selbstbeteiligung der alten Richtlinie 85/374/EWG hat im neuen Text keine Entsprechung. Haftungsklauseln in AGB oder Lizenzbedingungen ändern an der Außenhaftung also nichts.

Zeitlicher Geltungsrahmen. Das neue Offenlegungs- und Beweisregime gilt für 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), die den Wortlaut auf "nach dem 8. Dezember 2026" berichtigt hat; die ursprüngliche Amtsblattfassung vom 18.11.2024 nannte hier noch den 9. Dezember. Eine konsolidierte Fassung, die die Berichtigung einarbeitet, lag auf EUR-Lex am 03.08.2026 nicht vor; wer den Text abruft, muss die Berichtigung selbst anwenden. Als Richtlinie wirkt die Produkthaftungsrichtlinie über nationales Umsetzungsrecht; ein deutsches Umsetzungsgesetz war am 03.08.2026 nicht verkündet (Anwendungsbereich und Zeitplan vertieft in pld-001, die Handlungsstrecke in pld-006).

Umsetzungsperspektive

Der Hebel des CISO liegt nicht im Prozessrecht, sondern in der Beweisfähigkeit der eigenen Organisation:

• Dokumentation als potenzielles Beweismittel führen: Sicherheitsrelevante Produktentscheidungen (Schwachstellenpriorisierung, Patch- und Update-Entscheidungen, Risikoakzeptanzen, Erkenntnisse der Produktbeobachtung) so festhalten, dass Datum, Entscheidungsträger, Begründung und damaliger Informationsstand erkennbar sind. Ziel ist ein Bestand, der eine Vermutung widerlegen kann, statt sie zu nähren.
• Offenlegungsfähigkeit herstellen: wissen, wo relevante Unterlagen liegen (Ticketsystem, Repositories, Buildsysteme, Telemetrie, Berichte), wer sie in welcher Zeit zusammenstellen kann und wie der Prozess mit Legal abläuft. Wer erst im Prozess zu suchen beginnt, produziert Lücken und riskiert die Vermutung nach Art. 10 Abs. 2.
• Geschäftsgeheimnisse vorab klassifizieren: Art. 9 Abs. 4 und 5 verlangt keine vorherige unternehmensinterne Klassifizierung; die Schutzmaßnahmen ergreift das Gericht auf hinreichend begründeten Antrag einer Partei oder von Amts wegen. Wer einen solchen Antrag begründen will, muss allerdings benennen können, was schutzwürdig ist und warum. Eine nachträgliche Pauschalbehauptung, alles sei geheim, trägt nicht.
• Aufbewahrung an den Fristen ausrichten: Die Richtlinie ordnet keine Aufbewahrungspflicht an; Art. 17 regelt allein, wie lange ein Schadensersatzanspruch noch besteht. Als eigene Vorgabe bietet es sich an, das Aufbewahrungskonzept je Produktlinie an der 10-Jahres-Ausschlussfrist auszurichten und dort, wo eine Körperverletzung mit Latenzzeit in Betracht kommt, am 25-Jahres-Horizont des Art. 17 Abs. 2; den Neustart der Frist bei wesentlicher Änderung einplanen.
• Konsistenz sichern: Interne Bewertungen, Kundenkommunikation, Security Advisories und Marketingaussagen dürfen einander nicht widersprechen. Widersprüche zwischen interner Einschätzung und Außendarstellung sind im Offenlegungsfall das größte vermeidbare Risiko.

Typische Fehler

1. Dokumentation wird für Auditoren geschrieben, nicht als potenzielles Beweismittel geführt: Entscheidungen ohne Datum, Verantwortlichen und Begründung.
2. Update- und Priorisierungsentscheidungen bleiben in Chats und Einzeltickets verstreut und sind Jahre später nicht mehr rekonstruierbar.
3. Aufbewahrungsfristen orientieren sich an Steuer- oder Vertragsrecht statt an der 10- beziehungsweise 25-Jahres-Ausschlussfrist.
4. Die Fristen werden verwechselt, etwa die kenntnisabhängige 3-Jahres-Verjährung als absolute Obergrenze der Haftungsdauer verstanden.
5. Der Neustart der Ausschlussfrist durch eine wesentliche Änderung wird bei großen Releases übersehen.
6. Haftungsausschlüsse in AGB oder Lizenzbedingungen werden als wirksamer Schutz gegenüber Geschädigten eingeplant, obwohl Art. 15 genau das verbietet.
7. Es ist nicht vorbereitet, welche Unterlagen als Geschäftsgeheimnis schutzwürdig sind und warum, sodass im Offenlegungsfall kein hinreichend begründeter Antrag nach Art. 9 Abs. 5 gestellt werden kann; eine vorherige unternehmensinterne Klassifizierung verlangt die Richtlinie dabei nicht.

Risiken und Trade-offs

Der erste Trade-off betrifft die Dokumentationstiefe. Mehr Dokumentation liefert besseres Material zur Widerlegung von Vermutungen, ist aber zugleich potenziell offenzulegendes Material. Entscheidend ist deshalb nicht Menge, sondern Qualität und Konsistenz: Ehrliche, datierte, begründete Entscheidungen schützen; geschönte, lückenhafte oder einander widersprechende Unterlagen schaden. Wie Entscheidungen festgehalten werden, gehört mit Legal abgestimmt, nicht allein im Engineering entschieden.

Der zweite Trade-off liegt in der Priorisierung. Die Vermutung bei Verstößen gegen verbindliche Sicherheitsanforderungen macht Konformitätslücken doppelt teuer: Sie sind Marktzugangsrisiko und zugleich die günstigste Angriffsfläche für Kläger. Das spricht dafür, Lücken gegenüber verbindlichen Anforderungen vor freiwilligen Härtungsmaßnahmen zu schließen, auch wenn Letztere technisch reizvoller sein mögen.

Drittens die Fristen: Die Ausschlussfrist läuft ab Inverkehrbringen, Inbetriebnahme oder der Bereitstellung nach einer wesentlichen Änderung (Art. 17 Abs. 1); die Dauer des Supports verlängert sie nicht. Faktisch verlängern lange Supportzeiträume aber den Zeitraum, in dem in der Kontrollzone des Herstellers Fehlerhaftigkeit entstehen kann (pld-003), und eine wesentliche Änderung setzt die Zehnjahresfrist für das veränderte Produkt neu in Gang; beides verlängert, wie lange Beweisfähigkeit vorzuhalten ist. Das kostet dauerhaft Geld und will je Produktlinie bewusst entschieden sein, statt implizit über Toolwechsel und Datenlöschung zu verfallen.

Entscheidungspunkte

• Welche Unterlagen könnten wir heute vorlegen, wenn ein Gericht die Offenlegung zu einem konkreten Produkt anordnet, und in welcher Zeit?
• Wer entscheidet über Updatepriorisierung und Risikoakzeptanz, und wo wird das mit Datum und Begründung festgehalten?
• Wie lange bewahren wir Entwicklungs-, Schwachstellen- und Update-Dokumentation je Produktlinie auf, und deckt das die 10- und gegebenenfalls 25-Jahres-Frist ab?
• Ist definiert, was bei uns Geschäftsgeheimnis ist, und können wir das im Streitfall begründen?
• Wissen die Produktteams, dass für ein wesentlich verändertes Produkt die Zehnjahresfrist ab dessen Bereitstellung oder Inbetriebnahme nach der Änderung neu läuft (Art. 17 Abs. 1 Buchst. b) und wer dann als Hersteller gilt (Art. 8 Abs. 2), und fließt das in Release-Entscheidungen ein?
• Sind Versicherungsdeckung und Rückstellungen darauf eingestellt, dass es keine Haftungsobergrenze und keine Bagatellschwelle gibt?

Praktische Empfehlungen

1. Führen Sie sicherheitsrelevante Produktentscheidungen in einer dauerhaften, durchsuchbaren Form zusammen (Entscheidung, Datum, Verantwortliche, Begründung, damaliger Informationsstand), statt sie in Chats und Tickets zu belassen.
2. Legen Sie je Produktlinie ein Aufbewahrungskonzept fest, das die 10-Jahres-Ausschlussfrist, den 25-Jahres-Sonderfall und den Fristneustart bei wesentlicher Änderung abbildet.
3. Vereinbaren Sie mit Legal einen abgestimmten Ablauf für gerichtliche Offenlegungsanordnungen: Fundorte relevanter Unterlagen, Zuständigkeiten, Kennzeichnung von Geschäftsgeheimnissen.
4. Prüfen Sie die Einhaltung verbindlicher Sicherheitsanforderungen zuerst: Ihre Verletzung löst die Fehlerhaftigkeitsvermutung aus und ist damit die teuerste Lücke.
5. Streichen Sie die Erwartung, AGB-Haftungsklauseln würden gegenüber Geschädigten wirken, aus Kalkulation und Risikoregister; planen Sie Deckung ohne gesetzliche Obergrenze.
6. Behandeln Sie die beiden Uhren getrennt: die Kenntnisfrist von 3 Jahren für die Frage, wie lange nach Vorfällen Klagen drohen, und die produktbezogene Ausschlussfrist von 10 Jahren, die sich bei latenzbedingt verhinderter Verfahrenseinleitung auf 25 Jahre verlängert (Art. 17 Abs. 2), als Maßstab für Dokumentations- und Supporthorizonte.
7. Verproben Sie die Beweisfähigkeit einmal jährlich an einem realen Produkt: Lässt sich für eine konkrete Schwachstelle die Kette aus Kenntnis, Bewertung, Entscheidung, Update und Kommunikation lückenlos belegen?

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"): Offenlegung (Art. 9), Beweislast und Vermutungen (Art. 10), Verbot von Haftungsausschluss und -beschränkung (Art. 15), Verjährung (Art. 16), Ausschlussfristen (Art. 17). EU-Recht, frei zitierbar mit Quellenangabe; eine konsolidierte Fassung mit eingearbeiteter Berichtigung lag am 03.08.2026 auf EUR-Lex nicht vor.
• Richtlinie (EU) 2016/943 (Geschäftsgeheimnis-Richtlinie): Bezugspunkt der Geschäftsgeheimnis-Definition (Art. 4 Nr. 17 der Produkthaftungsrichtlinie) und der Schutzmechanismen im Offenlegungsverfahren.
• Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (BT-Drs. 21/4297 vom 25.02.2026): deutscher Umsetzungsentwurf; am 03.08.2026 nicht verkündet. Aussagen zum künftigen deutschen Recht sind Entwurfsstand.
• Cyber Resilience Act (Verordnung (EU) 2024/2847): Beispiel verbindlicher Cybersicherheitsanforderungen, deren Verletzung die Vermutung nach Art. 10 Abs. 2 auslösen kann; von der Produkthaftungsrichtlinie nicht namentlich genannt (Grundzüge im cra-Track).