Digital Escrow als Resilienz-Baustein: Kritische Assets gegen den Ausfall des Anbieters sichern

Wie schnell ein Unternehmen die Kontrolle über seine kritischen digitalen Wirtschaftsgüter verlieren kann, haben zwei Fälle aus dem Jahr 2025 gezeigt. Die Fasana GmbH, ein über hundert Jahre altes Unternehmen der Papierindustrie, wurde im Mai 2025 Ziel eines Ransomware-Angriffs. Die Attacke legte sämtliche IT-Systeme lahm; nicht einmal ein Lieferschein ließ sich noch drucken, die Produktion stand still. Binnen zwei Wochen summierten sich die Umsatzausfälle auf rund zwei Millionen Euro. Am 1. Juni 2025 stellte das Management einen Insolvenzantrag.

Auslöser war weder ein Managementfehler noch eine Marktveränderung, sondern „nur“ ein externer Cybervorfall. Die zweiwöchige Downtime legte zugleich nahe, dass weder belastbare Business-Continuity-Pläne noch funktionierende Backups vorlagen. Geschäftsleiter, die solche Versäumnisse zu vertreten haben, riskieren eine persönliche Haftung wegen Organisationsverschuldens.

Der zweite Fall verlagert die Perspektive vom Ausfall der eigenen IT auf die Abhängigkeit von einem Drittanbieter. Builder.ai galt als künftiges Tech-Unicorn mit Milliardenbewertung und prominenten Investoren, darunter Microsoft. Das Versprechen einer weitgehend autonomen, durch künstliche Intelligenz (KI) gestützten App-Entwicklung erwies sich jedoch als überzogen; zu Fall brachten das Unternehmen letztlich aufgeblähte Umsatzzahlen. Zurück blieben Kunden, deren Geschäftsprozesse auf einer Software aufsetzten, deren Entwickler es plötzlich nicht mehr gab.

In der KI-Szene zeichnet sich derzeit ein strukturell ähnliches Risiko ab. Viele junge Anbieter nutzen im Kern große Sprachmodelle (LLMs) und entwickeln ihre eigentliche Lösung als Schicht darum herum („Wrapper-Lösungen“). Diese Schicht entsteht häufig per Vibe-Coding: KI-gestützt und schnell, aber auch fehleranfällig.

Wer sich als Kunde auf ein solches Unternehmen einlässt, will vor allem eines: die Sicherheit, im Fall der Fälle mit dem Werkzeug weiterarbeiten zu können. Für diese Situationen – den plötzlichen Totalausfall wie bei Fasana oder die Absicherung lizenzierter Software wie bei Builder.ai – gibt es einen etablierten Resilienz-Baustein: Digital Escrow.

Was ist Digital Escrow?

Unter Digital Escrow versteht man die treuhänderische Hinterlegung kritischer digitaler Assets bei einem neutralen Dritten, dem Escrow-Agenten. Dieser gibt die Assets nur bei Eintritt vertraglich definierter Bedingungen an den Begünstigten heraus. Rechtlich liegt dem ein Treuhandverhältnis zugrunde; im deutschen Sprachgebrauch heißt der Escrow-Vertrag daher auch Treuhandoder Hinterlegungsvertrag.

Je nach abzusicherndem Asset haben sich verschiedene Ausprägungen etabliert. Ein häufiger Anwendungsfall ist Software Escrow: Der Softwarehersteller hinterlegt den
Quellcode nebst Dokumentation, um seinen Lizenznehmern die Weiternutzung und Wartbarkeit der Software auch dann zu ermöglichen, wenn er selbst ausfällt.

Beim AI Escrow kommen KI-spezifische Assets hinzu, etwa feingetunte Modelle, Vektordatenbanken und Embeddings von Retrieval-Augmented-Generation-(RAG)-Systemen oder – wie bei den beschriebenen Wrapper-Lösungen – die gesamte Eigenentwicklung rund um das zugrunde liegende Modell einschließlich Prompt-Logik, Orchestrierung und Schnittstellen.

Beim Key Escrow hinterlegt der Hersteller kryptografische Schlüssel, damit verschlüsselte Daten im Ernstfall entschlüsselbar bleiben. Data Escrow sichert kritische Daten und ganze Datenbanken, Document Escrow sensible Dokumente wie Geschäftsgeheimnisse oder Konstruktionsdaten.

Der Fall Fasana zeigt zugleich die Grenze des klassischen Backups. Eine Sicherung schützt nur, solange sie außerhalb der Reichweite des Angreifers liegt – wer die Produktivsysteme kompromittiert, erreicht häufig auch angebundene Backups und verschlüsselt oder löscht sie gleich mit. Die Hinterlegung bei einem neutralen Dritten liegt dagegen strukturell außerhalb des Angriffsvektors.

Wären die kritischen Auftrags-, Kunden- und Produktionsdaten dort hinterlegt gewesen, hätte Fasana sie unmittelbar zurückholen können, statt sie über Wochen erfolglos
zu rekonstruieren. Escrow verhindert den Angriff nicht. Es verkürzt jedoch den Stillstand.

Die rechtliche Architektur

Digital Escrow ist stets ein Tandem aus Legal und Tech. Der rechtliche Teil beginnt mit dem Escrow-Vertrag, typischerweise einer dreiseitigen Vereinbarung zwischen Hinterleger (Entwickler), Begünstigtem (Lizenznehmer) und Escrow-Agenten (Treuhänder). Der Escrow-Vertrag tritt dabei neben den zugrunde liegenden Lizenz- oder Projektvertrag und muss mit diesem inhaltlich abgestimmt sein, damit beide Regelwerke widerspruchsfrei ineinandergreifen.

In der Praxis hat sich für den Escrow-Vertrag die Ausgestaltung als echter Vertrag zugunsten Dritter im Sinne von § 328 Bürgerliches Gesetzbuch (BGB) bewährt: Der Begünstigte beziehungsweise der Lizenznehmer erwirbt daraus ein eigenes Forderungsrecht und kann die Herausgabe selbst verlangen, sobald die vertraglich definierten Herausgabebedingungen eintreten.

Insolvenzfestigkeit: Zwei Problemkreise im Fokus

Im Zentrum vieler Hinterlegungen steht der Schutz vor der Insolvenz des Softwareherstellers. Ohne Absicherung fällt der Quellcode mit der Verfahrenseröffnung in die Insolvenzmasse. Über ihn verfügt dann allein der Insolvenzverwalter, und der Lizenznehmer kommt nicht mehr unmittelbar an das Material heran. Wer den Escrow-Vertrag insolvenzfest gestalten will, muss deshalb einige Kniffe beachten und zunächst zwei Problemkreise auseinanderhalten, die unabhängig voneinander zu lösen sind.

Der erste Problemkreis ist die Massezugehörigkeit des Hinterlegungsguts: Der Quellcode darf gar nicht erst Teil der Insolvenzmasse werden. Genau das leistet die Hinterlegung. Mit der tatsächlichen technischen Übertragung auf den Escrow-Agenten verlässt der Code die Vermögenssphäre des Entwicklers schon vor der Insolvenzeröffnung und wird treuhänderisch verwahrt. Kommt es zur Insolvenz, gehört er damit nicht zur Masse.

Der zweite Problemkreis ist die insolvenzfeste Nutzungsbefugnis nach der Herausgabe: Der Begünstigte, also der Lizenznehmer, muss mit dem Code im Ernstfall auch rechtlich weiterarbeiten dürfen. Deshalb räumt der Hersteller ihm das Nutzungsrecht bereits bei Vertragsschluss ein – jedoch aufschiebend bedingt auf den Eintritt eines Herausgabefalls.

Die maßgebliche Verfügung erfolgt damit schon vor der Insolvenz, nur ihre Wirkung tritt später ein. Nach der Rechtsprechung des Bundesgerichtshofs (BGH) ist das Nutzungsrecht dem Zugriff des Insolvenzverwalters dadurch entzogen, selbst wenn die Bedingung erst nach Insolvenzeröffnung eintritt. Verkürzt formuliert: Der erste Problemkreis verschafft dem Begünstigten im Ernstfall das digitale Asset, der zweite die Erlaubnis, es zu nutzen.

Herausgabefälle: Die Insolvenz absichern, ohne sie zu benennen

Bleibt der letzte Kniff: die Herausgabefälle – auch Release-Trigger genannt – vertraglich scharf zu schalten. Gemeint sind die Ereignisse, bei deren Eintritt der Escrow-Agent das hinterlegte Asset an den Begünstigten herausgibt. Dabei entsteht eine auf den ersten Blick paradoxe Situation: Ausgerechnet der praktische Hauptfall, die Insolvenz, darf nicht als ausdrückliches Release-Kriterium im Vertrag stehen. Eine solche insolvenzabhängige Klausel beschränkt die Rechte des Insolvenzverwalters, benachteiligt die Gläubiger und ist rechtlich sofort angreifbar.

Die Release-Trigger müssen deshalb an insolvenzneutrale, objektiv feststellbare Ereignisse anknüpfen und den Insolvenzfall mittelbar praktisch abdecken, ohne ihn beim Namen zu nennen. Zwei Trigger haben sich in der Praxis bewährt.

Erstens die Aktualisierungspflicht: Der Entwickler hinterlegt in festgelegten Intervallen neue Code-Stände. Bleiben die Updates über mehrere Intervalle aus, deutet das auf wirtschaftliche Schwierigkeiten hin und lässt sich als Herausgabefall insolvenzfest abwickeln. Nebenbei verschafft die laufende Hinterlegung von Updates dem Begünstigten Transparenz über den Entwicklungsstand.

Zweitens der Brain Drain: Verlassen wesentliche Entwicklungsteams das Unternehmen, lässt sich die Software absehbar nicht mehr sachgerecht pflegen – auch das taugt als vertraglich definierter Herausgabefall. Daneben kommen weitere Trigger in Betracht, etwa die dauerhafte Einstellung von Wartung und Support.

DORA: Drei Anknüpfungspunkte für Digital Escrow

Ausdrücklich erwähnt wird Escrow im europäischen Digitalrecht bislang nicht – der Sache nach laufen die Anforderungen mehrerer Rechtsakte aber auf eine Hinterlegung hinaus. Besonders deutlich zeigt das der Digital Operational Resilience Act (Verordnung (EU) 2022/2554, DORA) mit drei Anknüpfungspunkten.

Zur Erinnerung: Die Verordnung ist seit dem 17. Januar 2025 anwendbar und nimmt den gesamten Finanzsektor in die Pflicht – Banken, Versicherer, Zahlungsdienstleister – sowie in der Folge auch deren Informations- und Kommunikationstechnik-(IKT)-Dienstleister. Ihr Ziel ist digitale operationale Resilienz: die Fähigkeit, jederzeit handlungsfähig zu bleiben – genau das, was auch Digital Escrow leistet.

Der erste Anknüpfungspunkt ist Art. 11 DORA, der die Überschrift „Reaktion und Wiederherstellung“ trägt. Abs. 2 lit. a verlangt, dass die Fortführung der kritischen oder wichtigen Funktionen des Finanzunternehmens sichergestellt ist. Fällt der Hersteller einer kritischen Software aus, ist diese Fortführung ohne Zugriff auf Quellcode, Dokumentation und Betriebsmaterialien kaum zu gewährleisten – hier lässt sich Escrow als Resilienz-Baustein ins Feld führen. Der zweite Anknüpfungspunkt ist Art. 7 lit. d DORA: IKT-Systeme müssen technologisch resilient sein.

Gerade Software-as-a-Service-(SaaS)-Anwendungen können jederzeit ausfallen, weil ihre Verfügbarkeit vollständig vom Anbieter abhängt; eine Hinterlegung fängt genau dieses Risiko auf. Am deutlichsten ist Art. 30 Abs. 2 lit. d DORA: Finanzunternehmen müssen vertraglich sicherstellen, dass sie im Insolvenzfall oder bei Vertragsbeendigung des IKT-Dienstleisters wieder an die eigenen Daten kommen. Die Daten gehören dem Finanzunternehmen, nicht dem Dienstleister; ihre fortdauernde Verfügbarkeit lässt sich durch eine Hinterlegung strukturiert absichern.

Real-Time Escrow: Vom Vertrauen zur Verifizierbarkeit

Bleibt der zweite Teil des Tandems: die Technik. Die klassische Hinterlegung war Handarbeit: In größeren Abständen wanderte ein Datenträger physisch in die Verwahrung – etwa der USB-Stick beim Notar. Für moderne Software taugt dieses Modell aus zwei Gründen nicht mehr. Bei kurzen Releasezyklen ist der hinterlegte Stand schnell veraltet; im Herausgabefall erhält der Begünstigte dann Material, das mit der produktiven Version wenig gemein hat.

SaaS-Entwicklung mit laufenden Deployments verlangt eine Hinterlegung, die dem Entwicklungstakt folgt. Und das Modell beruhte im Kern auf Vertrauen: Der Begünstigte musste sich darauf verlassen, dass der Verwahrer das Material vollständig, aktuell und unverändert vorhält. Ein zeitgemäßer Technologie-Stack adressiert beide Punkte.

Der erste Baustein ist die Automatisierung der Einlieferung. Über eine direkte Anbindung an Versionsverwaltungssysteme wie GitHub oder GitLab überträgt der Hersteller neue Code-Stände unmittelbar aus dem Repository in den digitalen Tresor; individuelle Update-Frequenzen lassen sich automatisiert einstellen. Die vertragliche Aktualisierungspflicht wird damit technisch abgebildet, ihr Ausbleiben wird objektiv messbar. Genau diese Messbarkeit macht das Update-Kriterium als insolvenzneutralen Herausgabefall praktikabel – Vertrag und Technik greifen ineinander.

Der zweite Baustein ist die inhaltsadressierte Speicherung, wie sie das InterPlanetary File System (IPFS) umsetzt. Beim herkömmlichen pfadbasierten Speichern könnte ein Asset in einem Ordner gelöscht oder ausgetauscht werden, ohne dass dies unmittelbar auffällt.

Bei der inhaltsadressierten Speicherung ist das Asset selbst der Referenzpunkt: Jedes Asset erhält einen Hash, einen digitalen Fingerabdruck seines Inhalts. Jede noch so kleine Änderung erzeugt einen anderen Hash und wird dadurch sofort erkennbar. Ein Token Gating stellt sicher, dass die Assets nur mit einem kryptografischen Zugangsschlüssel abrufbar sind. Das öffentliche Protokoll wird so zum privaten, zugangsbeschränkten Speicher.

Die redundante Ablage auf mehreren dezentralen, in der EU gehosteten Nodes stellt sicher, dass das Material auch beim Ausfall einzelner Server verfügbar bleibt. Der dritte Baustein ist die Verankerung des Hashs auf einer öffentlichen Blockchain (zum Beispiel Polygon).

Damit kann jeder Beteiligte – unabhängig vom Escrow-Agenten – jederzeit über einen Blockchain-Explorer nachvollziehen, wann welches Asset hinterlegt wurde und ob es seither verändert worden ist. Der Nachweis der Integrität hängt nicht mehr an der Zusicherung des Verwahrers, sondern ergibt sich aus einer für alle Parteien prüfbaren Datenbasis. Für den Begünstigten bedeutet das lückenlose Datentransparenz über den Hinterlegungsbestand, für den Hinterleger einen belastbaren Nachweis seiner Vertragserfüllung und für die Prüfungs- und Aufsichtspraxis einen revisionssicheren Audit Trail.

Fazit

Digital Escrow hat sich von der klassischen, manuellen Hinterlegung zu einem smarten Legal-Tech-Tool entwickelt. Als „2-in-1“-Lösung, die rechtlichen Insolvenzschutz und technische Kontinuität nahtlos verbindet, ist es heute ein tragendes Element digitaler Resilienz. Rechtlich steht und fällt die Wirksamkeit mit der insolvenzfesten Gestaltung: Aussonderung des Hinterlegungsguts durch technische Übertragung auf den Escrow-Agenten, aufschiebend bedingte Einräumung der Nutzungsrechte vor der Insolvenz und insolvenzneutral formulierte Herausgabefälle.

Regulatorisch liefert DORA mit Art. 11 Abs. 2 lit. a, Art. 7 lit. d und Art. 30 Abs. 2 lit. d konkrete Anknüpfungspunkte, die sich mit einer sauber aufgesetzten Hinterlegung strukturiert adressieren lassen. Technisch verschieben Blockchain-gestützte Architekturen mit inhaltsadressiertem, zugangsbeschränktem Speicher die Grundlage der Hinterlegung: von der Vertrauensfrage zur kryptografisch prüfbaren Gewissheit – und von der jährlichen Momentaufnahme zur Hinterlegung im Takt der Entwicklung.

Für alle, die kritische digitale Assets anbieten oder nutzen, ist die Hinterlegung längst keine bloße Formalie mehr, sondern ein praxiserprobter Kernbaustein der Business Continuity. Die Fälle Fasana und Builder.ai zeigen, was auf dem Spiel steht: der Verlust der Handlungsfähigkeit.