181
}
b) Wird der Vertrag zumindest vorerst − durch den Insolvenzverwalter
fortgeführt oder aufgelöst?
c) Wird der Vertrag in der Folge durch einen Rechtsnachfolger oder das
sanierte Unternehmen selbst weitergeführt oder ist eine Neu- oder
Nachverhandlung erforderlich?
d) Können die Qualität der Dienstleistung und insbesondere die
Verfügbarkeit der Daten aufrechterhalten bleiben?
e) Wer ist nunmehr Ansprechpartner für technische Probleme?
f)
Werden Daten oder Software, wenn es tatsächlich zu einer Schließung
des Unternehmens kommt, überlassen?
Es empfiehlt sich, auf diese Punkte im Vertrag einzugehen, um im Ernstfall
schnell handeln zu können und aufwendige Auseinandersetzungen mit
einem Insolvenzverwalter zu vermeiden. Sollte die Insolvenz tatsächlich zu
einer Zerschlagung des Unternehmens des Anbieters führen, so stellt sich
die Frage, wie mit den Daten des Nutzers umzugehen ist.
3.18
Das Treuhandinstrument vorsorgende Überlegungen zu Exit-
Strategien
3.18.1
Einleitung Wie man sich bettet, so liegt man
Es liegt in der Natur von Cloud-Services, dass sich eine erhebliche
Anbieterabhängigkeit ergibt und es grundsätzlich nicht im Interesse des
Anbieters liegt, den Anbieterwechsel möglichst einfach zu gestalten
(
Kundenbindung). Insbesondere im Insolvenzfall hat ein Anbieter mitunter
andere Sorgen, als sich um spezifische Belange seiner Bestandskunden zu
kümmern, bzw. bedarf es eines technisch versierten Insolvenzverwalters,
um die Implikationen für die Betroffenen abschätzen zu können.
Die klassischen Mechanismen der Quellcodehinterlegung sind im Falle von
Software as a Service SaaS in der Regel nicht möglich oder nicht
zielführend, da mehrheitlich keine Individualsoftware im Spiel ist. An ihre
Stelle treten Überlegungen hinsichtlich Laufzeitumgebungen.
Für die Fälle Infrastructure oder Storage as a Service ist dies wesentlich
weniger problematisch, da vollständige Backups bzw. Snapshots in der Regel
vom Kunden selbst unter dessen alleiniger Kontrolle erzeugt werden
können.
